Free LUNs and "clean" vgexport

[Tiziano Contorno _]

Goodmorning.

If I well remember when I do a vgexport, the PVs retain the VG info. If I want to clean the info on the PVs I had to vgereduce the VG to a one only PV, then vgremove. Is this right?

If I have to see if a PV is free in a 2 node cluster I do this:

0) ioscan -funCdisk to have the pv list, on both nodes
1) strings /etc/lvmtab | grep pv_path to check if it is "active", on both nodes. Write down these "busy".
2) Cross check that each VG in /dev/ is active (on nodeA or nodeB). If theres is a VG not active on both I activate it and write as busy the PV it is formed by.
3) Now I have a list of pseudo free LUN, I do a pvcreate (no -f) to verify.
4) Some pvcreate can still fail because the PV might have been in a VG exported.

Is there a way to see in a faster way if a PV is free? Is there a way to see if a pvcreate fails only because it belonged to a VG exported?

Thank you for your help!

[James R. Ferguson · Accepted solution]

Hi:

You can read the PVID and VGID a couple of ways. One is:

#/usr/bin/sh
DEV=${1}
if [ "`xd -An -j 8192 -N8 -tc ${DEV} | xargs`" = "L V M R E C 0 1" ]
then
INFO=`xd -An -j8200 -N16 -tx ${DEV}`
PVID=`echo ${INFO} | awk '{print $1 $2}'`
VGID=`echo ${INFO} | awk '{print $3 $4}'`
#
echo "${DEV} : PVID = ${PVID} : VGID = ${VGID}"
fi

Pass the disk device in question to decipher the PVID and VGID.

The first half of either ID is the server's `uname -i` machine ID in hexadecimal:

# printf "%#x\n" `uname -i`

Inversely, convert the first half to decimal to compare it directly to `uname -i`:

# printf "%#d\n" 0x77a845cc

Regards!

...JRF...

[Tiziano Contorno _]

OMG James, thank you! Is there a way now to get the VG name from the VGID? :D
I'd like to check it against the global VG name list to see if the PV is actually "busy".

Again regarding my first question, is it true that exporting a VG leaves VGID on the PVs and the only way to clean a PVs is vgreducing their VG first?

[Pete Randall]

Yes, it's true that exporting the VG leaves the LVM information intact on the physical volume - that's how vgimport is able to incorporate the volumes.

[James R. Ferguson]

Hi (again) Vanadio:

You asked if there was "...a way now to get the VG name from the VGID?".

No, other than to 'vgimport' the device thereby associating it with the specific name of the device directory to which the import is done. In fact, to rename '/dev/vgXX' to '/dev/vgYY' you simply do:

# vgexport vgXX
# mkdir /dev/vgYY
# mknod /dev/vgYY/group c 64 0xNN0000 [where NN=a unique number]
# vgimport vgYY ...

This updates the '/etc/lvmtab' and forms the association between the name of the '/dev' directory and ths VGID signiture.

Lastly, yes, it is true it true that exporting a VG leaves VGID on the physical disk whereas as 'vgreduce' will destroy the VGID.

In fact, an easy way to 'vgimport' volumes is to utilize the VGID signiture.. You 'vgexport' from one server using the '-s' option to collect the VGID into a mapfile. Then you 'vgimport' using the '-s' option and the named mapfile. The physical disk are scanned for matching VGID's and the '/etc/lvmtab' built accordingly. This circumvents the need to specify the physical paths during the import process. The drawback, is that you will undoubtedly want to use 'vgreduce' and 'vgextend' to rearrange the primary and alternate links for the best performance afterwards.

Have a good look at the manpages for 'vgimport' and 'vgexport' for the options of using '-s' and '-f' to collect and reassemble path information.

Regards!

...JRF...

[Tiziano Contorno _]

So for "cleaning" all the discs (alternate way to vgexport then pvcreate -f):

0) vgexport -pv -f
to get reference list of PVs

1) lvremove all LVs

2) vgreduce all but one PV

3) vgremove

4) pvremove all PVs in

Correct?

Does vgremove removes also /dev/ tree as vgexport?

Thank you again for your help.

[Nguyen Anh Tien]

You are correct:
4 steps are right too.
/dev/ were deleted by vgexport
NOTE: if you use vgexport to clear vg. You will still recover them by vgimport
Eg: vg03 contains /dev/dsk/c2t2d0 and /dev/dsk/c2t2d1
After exporting you can recovery by
#mkdir /dev/vg03
#mknod /dev/vg03/group c 64 0x030000
#vgimport /dev/vg03 /dev/dsk/c2t2d0 /dev/dsk/c2t2d1
Let Try and see
HTH
tienna

[Tiziano Contorno _]

Thank you!