controller change on upgrade to 11.11

[Brook Miller]

We recently upgraded a D360 from 10.20 to 11.11
and used the cold install method, we then tried to import the non-vg00 volume groups and received quorom errors, we found out that the controller id's changed on the upgrade ( ie c1t12d0 now was c2t12d0). We are planning another upgrade of a 370 machine, and wonder if we will run into the same problem, and if it can be avoided.

[Pete Randall]

Brook,

There's an option of vgexport/vgimport that addresses this (the -s option) but I'm pretty sure that it's unavailable in 10.20. Your only recourse is to prepare yourself by documenting your volume groups as they are and matching that to what they become.

Pete

[A. Clay Stephenson]

This is very typical in cases where hardware was moved/installed/replaced/removed after the original OS installation. In that case, what was c2 might now be c1 eventhough the hardware path is trhe same. If no hardware changes were made after the OS was origvinally installed then the new OS will 'discover' the cards in exactly the same order as did the original OS. You can override the assigned instance number via the ioscan -M driver -H hwpath -I instance_number command. Man ioscan for details.

[James R. Ferguson]

Hi Brook:

The is very common. The order in which hardware devices are sensed accounts for their ordering. If you have moved or added devices since the original I/O configuration, a subsequent cold-install may find them at different locations.

An easy way to do the 'vgimport' is to (have) created a mapfile which captured the the VGID of the physical volumes. This is done with the '-s' option during 'vgexport'. Applying this option during 'vgimport' will cause the process to read the VGID from all LVM disks, thus collecting the matched volumes into a volume group as defined in '/etc/lvmtab'.

Regards!

...JRF...

[Patrick Wallek · Accepted solution]

Pete, the '-s' option to vgexport is available in 10.20. I've used it. If it doesn't work initially, you may need a patch, but it does work.

The way to do it is:

# vgexport -m mapfilename -p -v -s vg??

This will create a mapfile with the VG-ID as the first line and all the LVs listed below that.

One these are created, copy them to tape or to your PC. When you system is upgraded, copy them back to the system and do:

# mkdir /dev/vg??

# mknod /dev/vg??/group c 64

Do this for all VGs

# vgimport -m mapfilename -s -v vg??

This way you don't have to know the exact devices that each VG is using. With the VG-ID in the mapfile, vgimport will search through all your devices for each disk that contains that particular VG-ID and import it for you.

[Pete Randall]

Thanks, Patrick, I stand corrected. I was searching for a definitive answer but, as yet, hadn't found anything.

Pete

[A. Clay Stephenson]

There is a downside to using the the -s option of the vgimport command. If you are using multi-pathed disk arrays, the -s command will assign all the primary SCSI path's to the same controller. The alterantes will still be detected but if you have carefully split your LUN's across multiple SCSI paths to maximize I/O then that optimization is lost. If you are simply connecting to JBOD's then this does not apply. You can use the -s vgimport to get the new device paths and then use vgextend to restore your optimization.