vgexport / vgimport

[Stafford Hyacinth]

Am I suppose to be able to do this?

System A:
vgexport -p -v -m vg02.map /dev/vg02

System B:
Create new lun
pvcreate /dev/dsk/c26t0d0
mkdir /dev/vg02
mknod /dev/vg02/group c 64 0x020000
vgimport -v -m vg02.map /dev/vg02 /dev/dsk/c26t0d0

It fails w/the following:
Physical Volume "/dev/dsk/c26t0d0" is not part of a Volume Group

I am simply trying to recreate the lvs on a different server.

[Sivakumar TS · Accepted solution]

Dear Stafford,

vgimport actually reads the LVM info from the PV and imports the lvols to the particular VG ( in our case vg02 )

If the /dev/dsk/c26t0d0 dosent have the LVM info then vgimport will fail !

hth,

Siva.

[Chan 007]

Hi,

1. When sharing use
vgexport -p -s -v -m, which created a changeid for in the map file.

2. No need to create a PVcreate on the second system. As u have created for the LUN alreeady.

Hope this helps...007

[Stafford Hyacinth]

Ok, that confirms my suspicion. I can't use vgexport/vgimport to recreate lvs on a different server w/new pvs. Thanks all.

[George Neill]

Assuming you want to move the original vg and all associated lv under it to a new server you are good except for one point. Do NOT do the pvcreate on the second server. The pvcreated on the second server will overwrite the vg information created on the original system. As was mentioned above doing a "vgexport -v -s -m..." and then "vgimport -v -s -m..." is very good and keeps you from having to track exactly which disk from the original system is which disk on the second system.

Good luck...

[Rory R Hammond]

A. 1. Umount all filesystems
2. vgchange -a n /dev/vg02
3. vgexport -v -m vg02.map /dev/vg02
remove disk. insert in new system.

B. do a ioscan -fnC disk to make sure you
see the disk and the device address
mkdir /dev/vg02
mknod /dev/vg02/group c 64 0x020000
vgimport -v -m vg02.map /dev/dsk/c26t0d0
vgchange -a y /dev/vg02

If this is a SAN. You need to make sure the "LUN" is seen by the new system. Your error message suggests to me that you did not have the correct device address. Or the PVCREATE might have wipe out your lv data.


Rory

[Stafford Hyacinth]

This is on a SAN but I am not removing or moving the luns.

A:
Server A will maitain all luns

B:
On server B I am creating new luns so I have to pvcreate.

Basically on server A I have many vgs I want to recreate on server B. I didn't want to go through the laborious task of vgcreate and lvcreate 100s of logical volumes but it appears I don't have a choice.

[Geoff Wild]

Stafford - that is correct - you can NOT create a new lun and vgimport...

If you want both systems to have the same "look and feel" - then you will have to recreate the vg's/lv's/file systems from scratch...

vgexport/vgimport is for when you share disks between servers - like in a ServiceGuard environment - or say you want your backup server to mount the file systems locally...

That means both system need to "see" the exact same disks -not new ones.

Rgds...Geoff

[Doug O'Leary]

Hey;

You're right; you don't have a choice. However, this task is something that's easily scriptable.

1. On your source system, create a lvs table:

for vg in ${list -o vgs}
do
for lv in $(vgdisplay -v ${vg} | grep -i 'lv name' | awk '{print $NF}')
do
size=$(lvdisplay ${lv} | grep -i '^lv size' | awk '{print $NF}')
printf "%-30s %5s\n" ${lv} ${size}
done
done > lvs

2. scp that lvs table over to the target system.

3. Create your volume groups as normal and sized to match the soruce

4. Create the LVs

cat lvs | while read lv size
do
vg=${lv%/*}; vg=${vg##*/}
lvcreate -L ${size} -n ${lv##*/} ${vg}
[[ ${size} -gt 2048 ]] && args="-o largefiles" || args=""
newfs -F vxfs ${args} ${lv%/*}/r${lv##*/}
done

With a little bit of work, left as an exercise for the reader, you can have it create the vgs for you, automatically mount the filesystems appropriately, and update the /etc/fstab as appropriatee...

As you can tell, I've done this a time or two...

HTH;

Doug

[Stafford Hyacinth]

Thanks Doug, that really came in handy.