transferring SAN-based filesystem to a new server

[Ben Dehner]

I have an N4000 server with 9 filesystems on an EMC CX600 SAN. We are replacing this server with a new RP4xxx server, and I want to move the filesystems to the new server.

One way I can move the filesystems is to do a vgexport on the original system, and a vgimport on the new system. However, it seems to me that I have to do a lot of legwork because the underlying PV paths will most likely be different between the two systems, and I have to make sure the PVs stay within the same volume groups. Or I can I just do a vgscan to do the dirty work and figure out which PVs go into which VGs?

Also, I'd like to leave the volume group information alone on the original system, just unmount the file system and inactivate the VG. This would allow me to manually fall back in case of system failure. However, what concerns me is that if the old system is rebooted, it will automatically try to activate the VG anyway, which I'm afraid may cause corruption. I can stop it from mounting the filesystems by editing /etc/fstab, but I don't know how to stop it from activating the volume groups, or what problems this may cause.

Thanks

[Sundar_7 · Accepted solution]

I will have to check if it is possible to clone the RP4XXX from the recovery archive of N4000. If you can, that would be the preffered method

You can do a vgexport with -s option. This way the map file will also contain the VGID. So you dont have to mention the PV names in the RP4XXX even if the PV paths are different

From N4000

# vgexport -p -v -s -m VG01.map /dev/vg01
# rcp VG01.map myrp4xxx:/root/

Repeat the above process for all the VGs

# vgchange -a n /dev/vg01

in RP4XXX (after the disks are made visible to the RP4XXX)

# mkdir /dev/vg01
# mknod /dev/vg01/group c 64 0x010000
# vgimport -v -s -m /root/VG01.map /dev/vg01

Now to disable N4000 from activating the VG at boot up

# vi /etc/lvmrc
AUTO_VG_ACTIVATE=0
custom_vg_activation ()
{
/sbin/vgchange -a y -s /dev/vg00
}
#

[Patrick Wallek]

For vgexport / vgimport, there really isn't that much work that needs to be done.

# vgexport -m /tmp/vg??.map -p -v -s /dev/vg??

That will create the map file and the -s will put the VGID at the beginning of the map file. This is important in the vgimport step.

Now take the map file and transfer it to your new machine.

Make sure it can see the SAN disks and that ioscan shows that all of the /dev/dsk/* device files have been created.

Now create the VG files:

# mkdir /dev/vg??
# mknod /dev/vg??/group c 64 0x0?0000
Where the ? is the unique minor number for the VG. If you want to see what has been used: 'll /dev/vg*/group' and look at the 0x0?0000 strings.

Now import your VG.

# vgimport -m /tmp/vg??.map -v -s /dev/vg??
The '-s' on the vgimport tells the system to look for ALL disks, no matter what their path with that VGID and import them into this VG.

I have done this several time and never had any trouble at all.

On your old system, you could keep a copy of the vg??.map file, umount all the filesystems, deactivate the VG and export it, and if you need to, just recreate the /dev/vg?? directory, the /dev/vg??/group file and reimport the VG.

It wouldn't take you long at all. That way you don't have to worry about the VG being activated inadvertently on the old machine.

[Rita C Workman]

You should be able to do your vgexport on the old system. You might use the -s option:
vgexport -pvs -m /etc/lvmconf/vgname.mapfilexx /dev/vgname

Make sure everything is unmounted and on the old server run:
vgchange -a n /dev/vgname
If your old system is not running MC/SG you can simply go in and rem out the lines in your /etc/fstab..should be okay on old now.

Then rcp this mapfile file over to your new server and do your import..
mkdir /dev/vgname
mknod /dev/vgname/group c 64 0x_ _0000
vgimport -vs -m /etc/lvmconf/vgname.mapfilexx /dev/vgname

vgchange -a y /dev/vgname
- or if you want to exclusivity then -:
vgchange -a e /dev/vgname

Again if your not in MC/SG environment where you would control this via pkg scripts, then just put the entries into your /etc/fstab and your ready on your new server.

HTH,
Rita

[Zinky]

This is how I would proceed:

Make sure the existing N4000 is running at least the DEC2003 or JUN2004 HWE & Gold Packs (I assume you are running 11i already right?).. Then just do an Ignite Backup of your N4000... Set up the new rp4xxx server, hook up the FC connections.. make sure the new HBA's on this new server is registered on the SAN, and simply Ignite restore back...

If you're using a new install of HP-UX on your rp44xx system, then I suggest you do the vgexport/import method.. create a map file containing the VGID for each non-root VG .. ie. vgexport -p -v -s -m vgxx.map /dev/vgxx

[Ben Dehner]

Wow, you people are fast.

Apparently, vgexport -s solves the move issues, because vgimport will find the vgid stamped on the PV's and take care of everything else.

By modifying /etc/lvrmc, I can control what gets activated at boot. I'll probably so something overly sophisticated like see if there is a file system mounted in /etc/fstab before activating a VG.

Thanks all!

[Sundar_7]

If you are planning to add some fancy stuff to /etc/lvmrc, think twice :-)

It has the potential to render your system unbootable.

[Zeev Schultz]

I won't add much regarding vgimport/vgexport/ignite since all has been explained already.Regarding keeping PV paths the same (if needed) use ioinit tricks explained in the doc' attached.

As rp4xx is a pretty new server around I would however take care that:
1)PDC firmware is last
2)patching level (inc. HW enable patches) are really new (2004 suggested)
3)checking FC HBAs support + FC patches (fabric support,new HBAs etc).

rgs

[Ben Dehner]

Using vgexport worked fine. Turn out there was no need to worry about the PV path binding. Thanks all.