rebuilding system and saving LVM info

[Kim Kendall]

Need a sanity check -

I have to rebuild a server from scratch (my thanks go out to the clown that built it originally)

I have several filesystems mounted up from an EMC CLARiiON. I'd like to be able to get them all back on the newly rebuilt system with the least amount of problems.

So, before I take the box down, I will be doing a vgexport. The man page says that when I do, I lose the VG's from the system.

If I use a -s, I don't lost the VG's. This isn't a HA environment and was wondering if I could still do a -s without effecting the current VG info or should I just use the -p and make the files without effecting any change?

Was hoping to get all this staged ahead of time so I wouldn't have to do it just before the rebuild.

All the devices should be the same since we aren't changing anything else.

# vgexport -m /tmp/vgemc1.map -p \
-f /tmp/emc1_pv /dev/vgemc1

Then after the rebuild....

# mkdir /dev/vgemc1
# mknod /dev/vgemc1/group c 64 0x020000

(ps - does the VG No. have to be the same, ie: 0x020000 ???)

Move the map and pv files onto the system, do an ioscan and insf -e to make sure the device files are in place.... then

# vgimport -m /tmp/vgemc1.map -f /tmp/emc1_pv /dev/vgemc1
# vgchange -a y

Have I missed anything?

[Pete Randall · Accepted solution]

Kim,

Use the -s and the -p together (also the -m). You don't lose anything and have everything stage and ready to go.

Pete

[Pete Randall]

Sorry - "staged".

and no, the VG no. as you call it doesn't have to be the same but it does have to be unique.

Pete

[S.K. Chan]

It would not make any difference because you're rebuilding the root VG and the new root VG would not know about "vgemc1" until you vgimport it back. Vgexporting with "-s" creates a map file that contain the VGID in the first line of the mapfile. Later in the vgimport process you must also use "-s" if not it'll create an LV with the name VGID which can be messy. I usually skip the -s option. On your other qs ..
- No the minor number do not have to be the same.
I'm a bit concern (maybe this is a non-issue) about the device path in the file "emc1_pv", make sure you double check to ensure the device files remains the same after the system is rebuilt. Other than that it looks good.

[James R. Ferguson]

Hi Kim:

The use of the '-f' option with 'vgexport' and 'vgimport' is quite useful when you want to order, for purposes of balancing, alternate (pv) links across controllers.

The '-s' option can also be used to create a mapfile with the VGID (Volume Group ID) in it. The presence of the VGID then allows 'vgimport' to automatically select the appropriate physical volumes. While often associated with "sharable" (as in MC/ServiceGuard implementations), the '-s' option can be freely used.

No, the minor number of the device file does not have to match the number of the volume group. However, making them the same is convenient in the long run and makes maintenance intuitive. Remember that the minor number is in hexadecimal, so volume group ten (10) would have a minor number '0x0a0000'. Remember too, the the kernel parameter 'maxvgs' defaults to ten (10) allowing a unique number in the range 0-9. While this can be increase up to 256, about 4-8KB of lockable memory is consumed for each increement.

Regards!

...JRF...

[Kim Kendall]

Thx... I was wondering if the group number from the original system had to match the target system... (0x020000, 0x030000, etc)

[Pete Randall]

Nope.

[James R. Ferguson]

Hi (again) KIm:

I should also note that a mapfile isn't necessary if your logical volume names are standard. That is, the name is in the form 'lvolN' where N is the decimal equivalent of the two least significant bytes of the minor number of the new logical volume.

Regards!

...JRF...

[Ted Ellis_2]

I have to recommend that you ALWAYS use a map file... do not trust any standards. The map file is easy and clean to make. Just make sure you save it somewhere before you blow away the old system :-)

[Rich Wright]

I think that it is safer to use the '-s' option.

If for any reason a path to a disk changes, the "-s" option will still vgimport the volume group since it scans all disks looking for the VGID match.

Rich

[steven Burgess_2]

Hi

vgexport

http://support4.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000062910856

vgimport

http://support4.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000062910859


vgscan - unable to match physical volume to a volume group

http://support4.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000063235845

Cur PV and Act PV do not agree in vgdisplay

http://support4.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000063204484

Hope these help

Steve