VG Export

[mhm]

Dears,

We need to migrate from one server to another one to upgrade the hardware capacity. We need the same luns (same mount points) from the SAN to be migrated to the new server, the SAN team replicate the old luns to new ones using something called (Block Copying) to ensure that the configuration is totally the same). Both of server are HP-UX 11.23, latest patches set, IPF.

I think the right procedure is:
- umountthe lv's
- vgchange –a n vg_name
- vgexport -p -s -v -m mapfile vgname (from the old server)
- mkdir /dev/(same vg name)
- mknod
- vgimport –s –v –m /etc/lvmconf/(vgname).map vg01
- vgchange –a y vg_name
- mkdir lv_mounts
- mount

Are those steps enough, should I vgextend the Volume Group with the new Luns?

Should the name of the Volume Groups be the same on both configurations?

BR

[Vishu]

Hi,

Yes, your procedure is good to go. Assigning LUNs to your new server may give you the same device files you were having in your old server. But you are using vgimport with -s option, it will take care of this thing as it will search for the VGID on those LUNs.

If you want exactly the same configuration on both the servers, then yes go for same VG names.

[R.K. #]

Hi Mhm,

Yes, the steps are correct.

vgextend is required only if you are using extra new luns.

Assigning name of VGs depends totally on you requirement. You can rename it or let it be same as before.

Also check below thread for same issue:
http://forums13.itrc.hp.com/service/forums/questionanswer.do?threadId=1398827

[Matti_Kurkela · Accepted solution]

Your vgexport will produce a map file named "mapfile", while your vgimport expects a map file named /etc/lvmconf/.map.

The name of the map file is not important: you're free to rename it as you wish. But you must copy the map file from the old server to the new one. I would not copy the map file directly to /etc/lvmconf: for me, that's the place of "known good" LVM configuration files only. But that's just my personal preference...

The name of the VG on the new system can be different: the procedure to rename a VG is to simply export it, then re-import using a new name. An exported HP-UX VG is nameless: it can be identified only by the VGID listed in the map file, or by explicitly listing all the PVs that belong to it.

Otherwise, your steps look OK.

The vgimport -s will automatically catch all the LUNs with the VGID of the volume group you're importing, so there is no need to vgextend anything. If there are multiple paths to the same PV, they will automatically be registered as alternate paths.

Note that you don't have to unmount the filesystems nor deactivate the VG for running vgexport with the -p option (preview = just create the map file, don't really export). This may be useful if you need to minimize the service interruption.

But you definitely should unmount & deactivate the VG on the old server before mounting it on the new server. Mounting a regular non-cluster filesystem simultaneously on two servers is a recipe for disaster and data loss.

For the same reason, I would export the VG for real from the old server once I've confirmed that it works on the new one.

So, the list of steps, slightly modified:

- vgexport -p -s -v -m vgname.map vgname (from the old server)
- copy vgname.map to /tmp of new server
- mkdir /dev/vgname
- mknod /dev/vgname/group c 64 0xNN0000

(If the server isn't a Serviceguard cluster member, you can pick a new NN value at this point. Never use a value that is already in use by another VG: 00 is for vg00, and my preference is to set aside 01 for DRD.)

- vgimport â s â v â m /tmp/vgname.map vgname
- mkdir lv_mounts
- umount the LVs (on the old server)
- vgchange -a n vgname (on the old server)
- vgchange -a y vgname (on the new server)
- mount
- test that it works
- export the VG for real on the old server, to make sure it won't be accidentally activated there.

MK

[mhm]

Thanks for all you,
Great answers,

Another concern please, the SAN team asked me to disable the Bad Block Relocation Policy, should I do it for the new LV's or it would be imported with configuration also?

[sujit kumar singh]

hi


that shall get imported if already set in the LV properties


regards
sujit

[Vishu]

Hi,

you map file will create the LVs in the new server with all the properties they were having in the old server. If the LVs in the old server has the Bad block relocation disbaled. then it will be disabled in the new server also.

Otherwise you can set it with lvchange command as

# lvchange -r n

[mhm]

Dears,

Regarding to the migration from one server to other and from an old san to new one, is there any need to use vgchgid command on the luns?
will I encounter a problem like this:
vgimport: Warning: Volume Group belongs to different CPU ID
or something similar to it?

[Bill Hassell]

> Regarding to the migration from one server to other and from an old san to new one, is there any need to use vgchgid command on the luns?

That is optional. Importing the VG to a different machine is a standard procedure.

> will I encounter a problem like this:
> vgimport: Warning: Volume Group belongs to different CPU ID
> or something similar to it?

vgimport is the only time you'll see this message. Once imported, the CPUID string is just documentation. It does help if you have a complex SAN fabric as you can look at the VGID, PVID and CPUID of each LUN presented to your server, This would be used to sort out mistakes in SAN switch mapping. The attached script will display the local CPUID and then read and display the VGID, PVID and CPUID from selected LUNs. With that info, you can match LUNs that belong to the same VG (vgimport does this automatically if you don't specify any LUNs to import).

[Matti_Kurkela]

No need to use vgchgid. It would be needed only in Business Copy backup operations, when you need to make a clone of VG A usable as VG B, on the same system that contains VG A.

Using vgchgid in a migration would make the existing map files invalid. That would make the migration more difficult: you could not use "vgimport -s".

Instead you would have to identify which LUN is used for which VG in the old SAN, find the equivalent new LUNs by looking at the SAN team's documentation, and then import the VG by listing the new LUNs one by one in the vgimport command. This would be doable, but very tedious and error-prone compared to using "vgimport -s" with a proper map file.

> vgimport: Warning: Volume Group belongs to different CPU ID

This is just a warning, not an error. It does not stop the import operation, just makes the sysadmin aware that the VG *might* be in use by another system, and the sysadmin should be extra careful.

If you see this message, it means *you* should make very sure that the other system has the VG deactivated before activating it on your new system, because the system cannot do it for you.

MK