Moving LV, file systems, raw devices

[Doug_3]

Hello, upon installing a new external disk array, the paths/links were modified and the 12H array lost it's original mapping to the lvols. Here is what was recommended at the time of the h/w install:

vgexport -s -m /tmp/vg01.map /dev/vg01
mkdir /dev/vg01
mknod /dev/vg01/group c 64 0x01000
vgimport -m /tmp/vg01.map -s /dev/vg01
vgchange -a y /dev/vg01

Is this accurate and what about the raw devices that informix is using?

tia
Doug

[A. Clay Stephenson]

That will work. The '-s' option causes vgexport to record the Volume Group ID (VGID) in the map file. The '-s' option of vgimport then asks searches for the attached physicals disks with matching VGID. Because your are using LVM raw LVOL's, when you finish Informix will still see /dev/vg01/rlvol1, /dev/vg01/rlvol2, ... even though the underlying physical disk paths might have changed.

The downside of importing 12H LUN's this way is that all of the SCSI path's will be through the primary controller with the alternates on the secondary controller. If you have optimized your SCSI paths to split the load across both external SCSI paths then you have lost that. The array will still perform but just not as well as it might have if you balanced the load. You can always vgexport/vgimport (without the -s option) again using the pv_paths after you determine what the new ones are.

[Animesh Chakraborty]

Ho Doug,
Your steps are correct.
Don't worry the raw devices will be created using the map file.

[I_M]

use pvmove?

[Animesh Chakraborty]

pvmove - move allocated physical extents from one LVM physical volume
to other physical volumes

In this case source physical volume no longer valid.
So can not use pvmove