Migrating from one HP Server to another connected to an EMC

[Joanne Keegan]

Hi,

When upgrading/migrating from one HP server to another that is attached to an EMC Symmetrix, there will be controller number changes for the disks when mounted on the new server. How can I cater for this with the vgimport, without losing any data? Do I specify the disks with the new controller number, or will the "-s" option cater for this.

I do award points, and will appreciate any advice.

Thanks,

Jo

[Steven E. Protter]

Yes Joanne, you are on the right track.

You will want a good tape backup before you start, but you should be able to use vgexport on the volume groups on the EMC and then vgimport to bring those volume groups into the new machine.

A few things to think about.

If its a boot volume, you might have problems because there are likely hardware and driver differences.

If you used nonstandard volume group names, those won't import the same way.

If a filesystem in vg01 on the EMC was called oracle, it will be imported with standard volume group names as if created without the -n option in vgcreate.

/dev/vg01/oracle will become /dev/vg01/lvol8 when imported.

There may be a way around it with 11i, but I've done it with HP suport on an 11.00 box.

I had to mount the logical volumes after the import one at a time, figure out what was on them and make adjustments to my /etc/fstab file.

This is a start, I'll hunt down some itrc posts and get back to you after handling some issues with my kiddies.

SEP

[Michael Tully · Accepted solution]

Hi Jo,

I've done this many times. The key is in how you do the vgexport. The -s places a VGID in the mapfile.

Try this e.g.
old server for each volume group
# cd /tmp
# vgexport -m myvg.mapfile -v -p -s /dev/myvg (you must use -p or you'll lose everything)
ftp the files to new server
unplug the cables/new cables/ rezone etc

on new server for each volume group e.g.
# mkdir /dev/myvg
# mknod /dev/myvg/group c 64 0x020000 (or whatever number is next)
# vgimport -m myvg.mapfile -v -p -s /dev/myvg
if it all works
# vgimport -m myvg.mapfile -v -s /dev/myvg (remove the -p preview option)
# vgchange -a y /dev/myvg
Make your directories etc mount, copy your /etc/fstab

Regards
Michael
"When I have trouble spelling, it's called fat finger syndrome"

[Animesh Chakraborty]

Hi Jo,
-s option will be enough.

vgexport -m /tmp/vg01.map -v -s /dev/vg01
On new server :
mkdir /dev/vg01
mknod /dev/vg01/group c 64 0x020000
vgimport -m /tmp/map/vg01.map -v -s /dev/vg01

vgchange -a y vg01
vgcfgbackup vg01

Thanks
Animesh

[Sunil Sharma_1]

Hi,

You got it...
yes -s option is more than sufficient....
SS

[#6]

vgremove is not recommended because you need to remove all LVs and PVs from the VG before you could use vgremove. This is not necessary with vgexport. Additionally vgexport leaves the LVM structures on the disks untouched which could be an advantage if you like to re-import the VG later.

[Bruce Troutman]

I've done something similar on a k-class. These were the steps I did.

Deactivate the volume group
#vgchange -a n /dev/vg03

Remove LVM settings from /etc/lvmtab (-m will create a mapfile)
#vgexport ???v -s ???m /tmp/vg03_map /dev/vg03

Modify the fstab file so when the system reboots it will come up cleaner
#cp /etc/fstab /etc/fstab.old
Modify the fstab so it just contains vg00(root volume group info), comment out the rest

Architecture change (EMC)
Add the Brocade switches???

Reboot system

Unix Commands (HP)
The device files will need to change
#ioscan -fn

Recreate the directory
#mkdir /dev/vg03

See which numbers have been used already for the group files
#ll /dev/vg*/group

???n??? has to be a unique number (see previous command)
#mknod /dev/vg03/group c 64 0x0n0000

Restore the LVM settings (-m references the mapfile)
#vgimport ???v -s ???m /tmp/vg03_map /dev/vg03

Reactivate the Volume Group
#vgchange -a y /dev/vg03

Backup the new LVM settings
#vgcfgbackup /dev/vg03 (do twice)

copy back the /etc/fstab
#cp /etc/fstab.old /etc/fstab
mount -a

Good luck!