Disk ID's changing how can I ensure volume groups are imported correctly

[Adam Noble]

We are making some changes to an external EMC disk array and have witnessed that the disk id's will change once this is complete. We backed out the change as obviously the volume groups failed to import however we need to carry out the work.

I am assuming that I can do a vgexport -s -p -m /tmp/vg02.map -f /tmp/vg02disks /dev/vg02

As far as I am aware this runs in preview mode and will enable me to create a list of disks currently in vg02 aswell as the mapfile. It will not actually export the volumes.

Therefore I assume when the server re-boots I can simply eddit the /tmp/vg02disks file to relate to the new ID's and then do a:-

vgimport -f /tmp/vg02disks /dev/vg02.

Infact do I need a mapfile created??????

Is this the correct way of doing this?

[Sridhar Bhaskarla · Accepted solution]

Hi Adam,

Yes. You will have to have the map file otherwise the logical volumes imported will have default names like lvol1, lvol2 etc., Easy way to try is to just specify -s option.

#mkdir /dev/vg02
#mknod /dev/vg02/group c 64 0x020000
#vgimport -v -s -m /tmp/vg02.map vg02

If you numerous disks, then the above will take a long time in which case you can modify vg02disks file and import them. Also remove the line that starts with VGID in your vg02.map file before you use it with -f option (call it say vg02.new.map) .

#vgimport -v -m /tmp/vg02.new.map -f /tmp/vg02disks vg02

-Sri

[Brendan Newport_2]

In addition to the solution already detailed, I found a workaround with vgscan.


I had a similar problem following a firmware upgrade on an EMC array, which left all of the physical paths altered.

I used this process, (it includes a few routines which are probably unnecessary);

vg01 & vg02 were EMC-sourced mounts.
backed-up all the *.conf and *.mapfiles, i.e.
vg01.conf backed-up as vg01.conf.bak
vg01.mapfile backed-up as vg01.mapfile.bak
vg02Emcm1.conf backed-up as vg02Emcm1.conf.bak
vg02Emcm1.mapfile backed-up as

I then performed a vgscan on all device paths, using the â pâ (preview)
# vgscan -a -p -v | tee -a /tmp/before_scan.txt

before_scan.txt;

/dev/vg00
/dev/dsk/c0t6d0
/dev/dsk/c3t6d0
/dev/vg01
/dev/dsk/c5t0d0

/dev/vg02EMcm1
/dev/dsk/c5t0d1
/dev/dsk/c5t0d2
/dev/dsk/c5t0d3
/dev/dsk/c5t0d4


/dev/vg03EMcm1
/dev/dsk/c5t0d5

/dev/vg02EMcm1
/dev/dsk/c5t0d1
/dev/dsk/c5t0d2
/dev/dsk/c5t0d3
/dev/dsk/c5t0d4


/dev/vg03EMcm1
/dev/dsk/c5t0d5
/dev/dsk/c5t0d6

I checked the output against the previous physical mappings of the disks in volume groups vg01, vg02Emcm1 and vg03Emcm1 using the command;

strings /etc/lvmtab

I then performed the vgscan this time â for realâ , using the command;

# vgscan -a -v

Note the â -pâ flagâ s absence, so this command â shouldâ actually scan and change the file /etc/lvmtab file.

Well, actually, it didnâ t. /etc/lvmtab still displayed the old configuration;

So I backed-up the current /etc/lvmtab file
and then removed it.

Then ran the vgscan again, to re-create the /etc/lvmtab file from new;

# vgscan -a â v

This worked fine, and the newly-created /etc/lvmtab file now had the correct device file names;

# strings lvmtab
/dev/vg00
/dev/dsk/c0t6d0
/dev/dsk/c3t6d0
/dev/vg01
/dev/dsk/c5t0d0
/dev/vg02EMcm1
/dev/dsk/c5t0d1
/dev/dsk/c5t0d2
/dev/dsk/c5t0d3
/dev/dsk/c5t0d4
/dev/vg03EMcm1
/dev/dsk/c5t0d5
/dev/dsk/c5t0d6

All that remained was to activate the EMC-hosted volume groups, using the vgchange command;


# vgchange â a y /dev/vg01

# vgchange â a y /dev/vg02Emcm1
# vgchan

[Adam Noble]

Thanks although using vgscan I have always felt has an element of risk

[Alzhy]

Adam,

You will not have this problem if you're using VxVM as your volume manager (which HP has recently blessed as the preferred VM for GP-UX..).

But on the case at hand - I have been able to go about this problem by simply doing a vgexport of the VG's with the VGID option (or shared option) so the VGID is part of the output.

/usr/sbin/vgexport -s -p -m /somedir/vgXYZ.map /dev/vgXYZ

Then when you do storage migrations, firmware upgrades, HBA relocations, etc.. etc.. you simply unmount the filesystems, vgchange to inactive and vgexport the VG.

When you boot your system you simply:

/vgimport -m mapfile -s -v vg_name

And to ensure that the disks (or PVs or LUNs..) for a particular VG are all there before you do your vgimport - get the VGID of all the disks in your system and search out.

echo 0x2010?2X|adb /dev/dsk/cXtYdZ|expand|tr -d " "|sed "s/2010://"

HTH.