Vgimport probs

[W L Wong]

Have created a mapfile of the a vg using vgexport from system A, and copied the mapfile to system B and when running vgimport I get the error :

vgimport -m vgdata01.mapfile -v vgdata21 /dev/dsk/c9t0d1 /dev/dsk/c11t0d2
Beginning the import process on Volume Group "vgdata21".
Physical Volume "/dev/dsk/c9t0d1" is not part of a Volume Group
Physical Volume "/dev/dsk/c11t0d2" is not part of a Volume Group

I then pvcreate the disks above successfully :

# pvcreate -f /dev/rdsk/c9t0d1
Physical volume "/dev/rdsk/c9t0d1" has been successfully created.
# pvcreate -f /dev/rdsk/c11t0d2
Physical volume "/dev/rdsk/c11t0d2" has been successfully created.

But still get the above errors when vgimporting. pvdisplay fails as well :

# 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".

/etc/lvmtab is clean. Diskinfo shows the disk ok :

# diskinfo /dev/rdsk/c9t0d1
SCSI describe of /dev/rdsk/c9t0d1:
vendor: EMC
product id: SYMMETRIX
type: direct access
size: 35354880 Kbytes
bytes per sector: 512

# diskinfo /dev/rdsk/c11t0d2
SCSI describe of /dev/rdsk/c11t0d2:
vendor: EMC
product id: SYMMETRIX
type: direct access
size: 35354880 Kbytes
bytes per sector: 512

How would I vgimport the vg properly? Would appreciate any advice. Thanks.

[Michael Tully]

Before you can import, you need to firstly create the directory and the device major device for the group.

e.g
mkdir /dev/myvg
mknod /dev/myvg/group c 64 0x020000
vgimport -v -m myvg.mapfile -p /dev/myvg (always run the preview option first)

Are you sure that these two LUN's are part of your volume group? What was your procedure on having system B see the disks from system A ?
There is never any need to run 'pvcreate' when importing. Why did you run 'pvcreate -f' ? 'pvcreate -f' bascially clobbers any LVM related information on your disk.

I am afraid if have picked the correct LUN's you have clobbered your disks ..... Time to get your backups out. You did create backups right ?

[Jim Mallett]

I hope you didn't actually run the pvcreate (as Mike mentioned). That would have overwritten any existing LVM structures on those drives.

The only thing I would add going forward is possibly using the -s option when you do the vgexport as it will add the PVID to the mapfile. That way when you are going to vgimport, you don't need to specify the disk paths.

I had a question somewhat similar to this a while ago and got some great responses that you may want to read through:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=191717

That thread proved very helpful.

Jim

[Shaikh Imran]

Hi,
You say that you have done pvcreate-- Why?
You don't need to do pvcreate if you want to do vgimport.
Now in this situation you say that /etc/lvmtab is empty--So,do
#vgscan -v
This will create a new lvmtab file for you.
Don't Worry it may take some time also.
And this will tell you whether /dev/dsk/c9t0d1 and c11t0d2 are avialable for import or not.
If yes follow the
Michael's Instruction to import those Volume groups.

Regards,

[SANTOSH S. MHASKAR]

No need to pvcreate on the disks, it will destroy your data on the disks. Also no need to use mapfile if u don't want the same lvol names.

Just create dir vgdata21 in /dev

# cd /dev

# mkdir vgdata21

# cd vgdata21

# mknod group c 64 0x0n0000

where n is a distinct no. for volume group

Then import the vg.

# vgimport -v vgdata21 /dev//dev/dsk/c9t0d1 /dev/dsk/c11t0d2

thats all

-Santosh

[SS_6]

When you create map file & do vgexport with -s option, it will scan the vgid and while vgimport using that map file it will look for same vgid and give error which you got is that vgid is not same. Now whenever you have this problem do vgexport -p and don't use -s option but while vgimport do like this
# vgimport -m /tmp/xx.map /dev/dsk/cxtxdx /dev/dsk/cxtxdx and so on.....
If its is a BCV copy of disks that you may sync it again and use -s option because this time same vgid information will be written on these disks.

[W L Wong]

Thanks for all the replies.

I have pvcreate'd the disks already. But this is the scenario.

system A and B do not share disks.

system A has EMC disks which need to be Timefinder sync'ed to system B 's BCV disks.

Hence the vg info of system A needs to be in duplicated into system B.

vgexport of system A was done :
# vgexport -p -v -m vgdata01.mapfile /dev/vgdata01

But when vgimport'ing into system B, I get the above msgs and can't vgimport.

Since the disks have been pvcreate'd, how would vgimport into system B then? It has different device disk files etc.

[Michael Tully]

If these are BCV's then you need to get a fresh copy from the originals. Are the disks on system A RDF1 ? If so you will need to do a full establish from these to your BCV's using the 'symmir' command. e.g. You can this providing you have the SYMCLI license and you have the device group(s) set up correctly.

# symmir -g mydevicegroup.rdf -full establish
# symmir -g mydevicegroup.rdf split
# vgexport -m mymapfile -v -p -s /dev/myvg

System B
copy the mapfile from system A
# ioscan -fn (to get the disks, if you have presented them correctly)
# mkdir /dev/myvg
# mknod /dev/myvg/group c 64 0x020000
# vgchgid /dev/rdsk/cXtYdZ (add each disk)
# vgimport -v -m myvg.mapfile -p /dev/myvg (always run the preview option first)
drop the preview if no errors.
# vgchange -a y /dev/myvg
# vgcfgfgbackup /dev/myvg
You may to have to run an 'fsck' prior to mounting the filesystem.

[Jim Mallett]

The -s on vgexport/vgimport is the key. With that, you don't need to know the device files on the new system. The PVID will be searched on each of the disks and only the appropriate disks added. Michael's steps walk you through it.

The only other question I would have is, you mentioned "system A and system B do not share disks". We are going on the assumption here that the these disks are multi-ported from the Symmetrix to both hosts. If the disks are not ported to both hosts then you will not be able to import them on system B. Do you know that they were configured for both hosts by EMC? Or do you have a tool like Control Center to view the disks?

[W L Wong]

Michael,

Thanks for your suggestions. Have done everything you recommended up till vgimport :

# vgimport -v -m vgdata01.mapfile -p /dev/vgdata21
Beginning the import process on Volume Group "/dev/vgdata21".
vgimport: Unable to read the physical volume.

or

# vgimport -v -m vgdata01.mapfile -p /dev/vgdata21 /dev/dsk/c9t0d1 /dev/dsk/c11t0d2
Beginning the import process on Volume Group "/dev/vgdata21".
vgimport: The Physical Volumes specified on the command line
do not belong to the same Volume Group.

This is what I meant...have TF sync'ed the BCVs, vgchgid etc. In the future the BCVs in system B will be used to backup the data from system A via daily TF syncs.

I think it's because I pvcreate'd both the disks earlier. So how can I vgimport now? Thanks again.

[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.