Volume Manager Solaris 7 -> Solaris 9 upgrade glitch (followup)

From: Steve Howie (showie@uoguelph.ca)
Date: Sun Aug 22 2004 - 22:42:16 EDT


Howdy

Followup to my own posting regarding the Volume Manager Solaris 9 error
when tryin the metainit a concatenation of LUNs from an HP XP512:

I found a Sun document addressing this very problem # ID48730, and was
wondering if anyone had tried the workaround it describes? The idea is
tell the sd driver that the disks with the specified product IDs do not
have a unique serial number (used to construct the devid), so it can
create a unique device id to write back to the disk itself. The entry in
sd.conf is of the following layout:

sd-config-list=
   "HP OPEN-9*10 -SUN","workaround";
workaround=1,0x8,0,0,0,0,0;
 

If so, I need to know if I need 4 separate sd-config-list entries in
/kernel/drv/sd.conf to describe these non-Sun disks? We have 4 separate
product types as far as I can see - all of which have NO serial number
according to netstat -k.
 
(2) Vendor id: HP Product ID: OPEN-9*10 -SUN
(3) Vendor id: HP Product ID: OPEN-9*5 -SUN
(1) Vendor id: HP Product ID: OPEN-9*6 -SUN
(1) Vendor id: HP Product ID: OPEN-9*2 -SUN

Alteratively, can the entries all be combined into one sd-config-list?

Many thanks

Scotty

[.... Original posting chunk ....]

Steve Howie wrote:

[....]

> After Solaris 9 was installed, the metadevices were manually recreated
> with no problems at all. Except for 1 of the metadevices. This
> involves 7 LUNS from an HP XP512 Storage area network, all
> concatenated to give a 280Gb. file system. However, after acquiring
> and mapping the luns as OS devices, concatenating them failed -
> metainit stated that the second extent overlapped the metadevice.
> Which is, of course, nonsense.
>
> This is an old error apparently, found back in SDS 4.2.1 days, and
> appears to be going strong with Solaris 9 Volume manager. Apparently
> it has something to do with the disk vendor ID's in non-SUN disks. The
> LUNS on the HP show up as "HP-OPEN" disks: c4t0d14 thru c4t0d20 are
> the LUNS from the XP 512 in the following 'format' output which I'm
> trying to concatenate:
>
> 23. c3t13d0 <SUN18G cyl 7506 alt 2 hd 19 sec 248>
> /pci@4,4000/scsi@2,1/sd@d,0
> 24. c4t0d14 <HP-OPEN-9*10-SUN-0118 cyl 50078 alt 2 hd 30 sec 96>
> c4t0d14
> /pci@4,2000/JNI,FCE@1/sd@0,e
> 25. c4t0d15 <HP-OPEN-9*10-SUN-0118 cyl 50078 alt 2 hd 30 sec 96>
> c4t0d15
> /pci@4,2000/JNI,FCE@1/sd@0,f
> 26. c4t0d16 <HP-OPEN-9*5-SUN-0118 cyl 50078 alt 2 hd 15 sec 96>
> c4t0d16
> /pci@4,2000/JNI,FCE@1/sd@0,10
> 27. c4t0d17 <HP-OPEN-9*5-SUN-0118 cyl 50078 alt 2 hd 15 sec 96>
> c4t0d17
> /pci@4,2000/JNI,FCE@1/sd@0,11
> 28. c4t0d18 <HP-OPEN-9*5-SUN-0118 cyl 50078 alt 2 hd 15 sec 96>
> c4t0d18
> /pci@4,2000/JNI,FCE@1/sd@0,12
> 29. c4t0d19 <HP-OPEN-9*6-SUN-0118 cyl 60094 alt 2 hd 15 sec 96>
> c4t0d19
> /pci@4,2000/JNI,FCE@1/sd@0,13
> 30. c4t0d20 <HP-OPEN-9*2-SUN-0118 cyl 20030 alt 2 hd 15 sec 96>
> c4t0d20
> /pci@4,2000/JNI,FCE@1/sd@0,14
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers



This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:29:20 EDT