Vgimport probs

[W L Wong]

Jim,
Yes, one Symmetrix box, with disks in different hosts that are not shared. System A using the STD (M1/M2) disks, and system B BCVs.

[W L Wong]

pvdisplay info on the disks :

# pvdisplay /dev/dsk/c9t0d1
pvdisplay: Couldn't find the volume group to which
physical volume "/dev/dsk/c9t0d1" belongs.
pvdisplay: Cannot display physical volume "/dev/dsk/c9t0d1".

# pvdisplay /dev/dsk/c11t0d2
pvdisplay: Couldn't find the volume group to which
physical volume "/dev/dsk/c11t0d2" belongs.
pvdisplay: Cannot display physical volume "/dev/dsk/c11t0d2".

[W L Wong]

genexadmin describes my situation exactly here :

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=102080

except in my case the disks are pvcreate'd and vgimport fails with the above msgs.

Thanks.

[Jim Mallett]

The vgimport is not going to work if you added the pvcreate step in between. You basically wiped those disks out. At this point, I think your best best is going to be trying a vgcfgrestore on system A. This will get you back to your initial position and may be your only chance to keep any of the data that was on there.
If that is successful, start the whole process over using the sequence of commands that Michael outlined. Be sure to use the -s option on the vgexport and vgimport as it will make the process easier as you won't need to worry about the paths.
I don't have access to man pages right now so I'm not sure of the syntax on the vgcfgrestore, but as with any command use it carefully. I'll try to check back in when I get up tomorrow, hopefully by then someone will have been able to add to this.

Jim

[Jim Mallett]

I just recreated your issue. I have some disk on my Symm visible to two hosts. I vgexported it from HostA and did a pvcreate from HostB. At that point neither host is going to recognize the old LVM structures.

If a backup of your LVM configuration exists on HostA in /etc/lvmconf do a vgcfgrestore, this will get you back to the starting point and should retain your data providing you haven't written to the disk elsewhere (From HostA):
# vgcfgrestore -n /dev/vgdata21 /dev/dsk/c9t0d1 /dev/dsk/c11t0d2
# mkdir /dev/vgdata21
# mknod /dev/vgdata21/group c 64 0x150000 (hex for 21)
# vgimport /dev/vgdata21 /dev/dsk/c9t0d1 /dev/dsk/c11t0d2
# vgchange -a y /dev/vgdata21
Mount your filesystem, and you should be back in business on HostA.

Then start over and don't pvcreate anything this time (from HostA):
- Unmount your directory.
- Deactivate your volume group.
- vgexport your volume group using -s
# vgexport -v -s -m /tmp/vgdata21.map /dev/vgdata21
- Copy your map file to the 2nd system.

From HostB:
# mkdir /dev/vgdata21
# mknod /dev/vgdata21/group c 64 0x150000
# vgimport -v -s -m /tmp/vgdata21.map /dev/vgdata21
# vgchange -a y /dev/vgdata21

Please check my syntax before executing (5am). I'm going to see if I can sneak back into bed without getting yelled at now.

Good luck... Jim

[W L Wong]

Jim,
I'll have to give you 10 points on effort alone. :)

Please let me try to explain it one more time. HostA has STD disks which hostB (with BCVs) does not see, and vice-versa.

STD-to-BCV mapping has been done. STD disks in HostA will eventually get TF sync'ed into BCVs in HostB on a daily basis as backup.

I have vgexported HostA's VG :
# vgexport -m vgdata01.mapfile -p -v /dev/vgdata01

The "-s" option was not used as the disks are not shared between hosts.

At this point, have done a full TF sync from STD_hostA to BCV_hostB (as Michael pointed out).

On hostB, have done the mknod etc ensuring the minor number is unique. I had also pvcreate'd both the disks which are supposed to be vgimport'ed into.

And I get the errors when vgimport'ing as above.

Assuming that on hostB these are new BCVs (disks), so a pvcreate shouldn't hurt? I'm stumped.

Help!

[Tim D Fulford]

Am I missing the point here? If I undeestand correctly host A disks has NOTHING to do with Host B disks. If this is the case the vgimport is not the tool for you. Simply create the volume group. It will not contain ANY data or the LVM structires of host A. You can synchronise the two data sets by copying the data (backup on A, then restore on B), but the data will not stay in sync...

# mkdir /dev/vg01
# mknod /dev/vg01/group c 64 0x??0000
# vgcreate vg01 /dev/dsk/... /dev/dsk/...
# lvcreate ...
# newfs ....


Regards

Tim

[W L Wong]

Tim,
vgexport/vgimport was done previously on separate hosts.

As Michael suggested :
1. Full establish for STD -> BCV
2. Split
3. vgexport from hostA
4. copy map files to hostB
5. mkdir vg, mknod
6. vgimport map files in hostB

And this is where it fails. If (6) succeeds then the vgimport'ed vg in hostB would have the filesystem/lv structure of hostA.

[Michael Tully · Accepted solution]

There is a step you have missed. We do this all the time, splitting off BCV's from an R2 set.
This is how:

1. Full establish for STD -> BCV
2. Split
3. vgexport to create map file from hostA
4. copy map files to hostB
5. mkdir vg, mknod
6. vgchgid for each device in a string (man page shows how)
7. vgimport map files in hostB

fsck/mount as necessary. Without running the vgchgid you will not be able to run the vgimport successfully.

[W L Wong]

It works!!! Fool of a Took!

Michael, found out that if we don't vgchgid we will get this warning in vgimport :

vgimport -p -v -m vgdata02.mapfile vgdata32 /dev/dsk/c9t2d0
Beginning the import process on Volume Group "vgdata32".
vgimport: Warning: Volume Group belongs to different CPU ID.
...
...

But it's ok. Thanks everyone, esp Michael and Jim.