Disk replication and lvm

[Terrence]

I've got identical setups in two separate data centers. An rp7420 running HPUX 11.23 and a Falconstor IPStor.

I've successfully replicated some luns (or San resources in Falconstor's terminology) between the rp7420's. My problem is I'm at a loss as to how to get the volume group and logical volume information built on the replicated system.

I considered vgexport/vgimport but the scsi device files are different on each server.
c24t0d0 on the source and c18d0t0 on the destination for example.

Can I just use vgimport/vgexport? I do this frequently on my service guard clusters but I'm wondering about which switches to use. Normally I'll use -s -v -m -p. Do I drop the -s?

Also do I have to detail all the volume groups on the vgimport command?

For example:

vgimport -v -s -m /tmp/vg01.map /dev/vg01 /dev/dsk/c18t0d0 \
/dev/dsk/c18t0d1 \
/dev/dsk/c18t0d2 \

[A. Clay Stephenson · Accepted solution]

You are on the right track. Duplicating the LUN's copies everything including the LVM meta-data so you actually have everything that you need. You don't need to run pvcreate's, vgcreate's, etc. The one "gotcha" is if you are ever going to activate the original and copied LUN's on the same host then you should run vgchgid on all the LUN's of the copy. Run one vgchgid command and list all the copy LUN's; this will assign a new VGID so that nobody gets hurt if both are activated on the same box.

If you are using standard LVOL names (lvol1, lvol2, ...) then you don't need a map file otherwise on the original machine:

vgexport -p -m /tmp/vg01.map /dev/vg01
and copy /tmp/vg01.map to the target machine.
Without the -s option, only the LVOL's will be listed.

On the target machine:
Do an ls -l /dev/vg*/group and note the minor device numbers. The only requirement is that your new VG uses a unique minor device number. By convention, vg01 uses 0x010000, vg02 uses 0x020000, and so on but that is just convention.

mkdir /dev/vg01
mknod /dev/vg01/group c 64 0x010000
vgimport -v -m /tmp/vg01.map /dev/vg01 /dev/dsk/c18t0d0 \
/dev/dsk/c18t0d1 \
/dev/dsk/c18t0d2
vgchange -a y /dev/vg01
vgcfgbackup /dev/vg01

[Juan M Leon]

I agree with Clay, But I will add one more option on the vgexport.
vgexport -s -p -m mymapfile /dev/vg01
The -s option will allow you to import the disks to the volume group without the need to supply didk information.

Good luck

[A. Clay Stephenson]

No, no, no! You do not want the -s option because that will search all the visible LUN's/disks trying to match the VGID's on all the LUN's --- the originals and the copies. You could fix this by running vgchgid on the copied LUN's but in order to do this, you would need to know the pathnames to the copied LUN's but if you know the pathnames you don't need to use -s. -s is really intended for the case where you don't know the pathnames of the LUN's/disks that comprise a volume group.

[Steven E. Protter]

Shalom,

export/import would get the logical volumes across to the replicated system.

It would not make the replicated system bootable.

That is what Ignite is for.

http://docs.hp.com/en/IUX/

You could also use dd on the entire boot disk, this might leave you with a system that could be modified to become bootable.

Not all systems however will boot off a SAN disk.

SEP