LVM command just for clarification of BCV import

[Todd McDaniel_1]

I have vgimported from a mapfile 2 VGs which are snapshots of BCVS from another host...

Everything looks good but I got some strange messages, that Id liek to get some adivce on.

I know why i got the too many disks error since I added the ALT paths as well... I am more concerned about the LVol errors... which I am not sure why I got them... I have done this before, but it has been a while so I have forgotten what messages I got then.



Beginning the import process on Volume Group "/dev/vgoradata1".
vgimport: Warning: Volume Group contains "16" PVs, "32" specified. Continuing.
Logical Volume is not defined on any physical volume.
"/dev/vgoradata1/fs03" is missing Physical Volumes.
Logical Volume is not defined on any physical volume.
"/dev/vgoradata1/fs04" is missing Physical Volumes.
Volume group "/dev/vgoradata1" has been successfully created.
Warning: A backup of this volume group may not exist on this machine.
Please remember to take a backup using the vgcfgbackup command after activating
the volume group.

[Sridhar Bhaskarla]

Hi Todd,

Did you ensure that you got all the disks included in SRDF?. Looks like the disks corresponding to fs03 and fs04 are not available anymore.

Make sure those logical volumes are not with '0' size on the source system. You will get the same errors if the lvols are of zero size.

-Sri

[Rick Garland]

Do you have service guard running as well?

[Sundar_7]

hmm..how is that you are importing the volume group ? Are you manually specifying the physical volumes with vgimport or using the -s option to import the PVs matching the VGID in the map file ?

Execute lvdisplay -v /dev/vgoradata/fs03, figure out the physical volumes and ensure that PV's corresponding BCV is mentioned in the vgimport command line, if you are manually listing the PVs.

[Todd McDaniel_1]

No BCVS...

I used vgexport -s -v -p -m options...Also, I specified the disks on the vgimport command

Oh wait... i didnt use the -s on the vgimport... i will redo them and see what happens with the -s option without specifiying the disks.

[Sundar_7]

May be with vgimport command, you missed out on a PV but mentioned alternate links of the some other PV :-).

vgexport -p -s -m -v in the source machine

vgimport -s -v -m /dev/vg

You can use vgimport with -s option as long as you dont execute vgchgid on the disks before importing.

[Todd McDaniel_1]

Sundar,

# vgimport -s -v -m vgoradata.mapfile.todd /dev/vgoradata
Beginning the import process on Volume Group "/dev/vgoradata".
Couldn't access the list of physical volumes for volume group "/dev/vgoradata".

I tried it with the disks and without and got the same message....

[Sundar_7]

Did you execute vgchgid on the disks ? - vgchgid changes the VGID on the disks and when vgimport tries to search for the physical volumes with the VGID matching that of in the map file, it fails to find any PV since vgchgid has already changed the VGID on the PVs.

1) Create a fresh map file from the source system

2) vgimport -s -v -m /dev/vg

[Todd McDaniel_1]

I have never used vgchgid in the past. Not sure that I need that.

I want the same IDs dont I if these are going to be mounted from BCV snapshot?

[Sridhar Bhaskarla]

Hi,

One of the things to note - if you are executing vgchgid before proceeding with vgimport - while running 'vgchgid' you have to specify all disks otherwise, the VGID will become different on them causing your vgimport to fail.

If you have the list of the PVs, then you can try again to change the VGIDs but ensure the disks you are specifying are in fact correct.

-Sri

[David Child_1]

If I understand correctly you made a BCV copy of /dev/vgoradata1 on hostA. You are trying to import the BCV copy onto hostB.

1. If hostB can "see" both the STD and BCV devices you will need to run vgchgid on each BCV device, then specify each of those devices on the vgimport line (without -s). Otherwise hostB might import the BCV devices, the STD devices, or a combination.

Note: As you are probably aware you must specify all devices on the same vgchgid line for it to work correctly. Example: vgchgid /dev/rdsk/c3t1d1 /dev/rdsk/c3t1d4. Not vgchgid /dev/rdsk/c3t1d1; vgchgid /dev/rdsk/c3t1d4

2. If hostB can only "see" the BCV devices you should be able to use 'vgexport -s -v -m vgoradata1.map -p /dev/vgoradata1' on hostA; copy vgoradata1.map to hostB; run 'vgimport -s -v -m vgoradata1.map /dev/vgoradata1' on hostB. If vgchgid has been run on any of the BCV devices you are out of luck using the shared (-s) option.

The error messages you are getting of concern;

Logical Volume is not defined on any physical volumes

It almost sounds like its the wrong map file for the devices. I think you might get this message if a volume group was imported and had 2 LVs defined, but you used a mapfile with 4 LVs specified. Just a thought.

David

[Sundar_7]

I want the same IDs dont I if these are going to be mounted from BCV snapshot?

VGID is just how kernels running in the individual nodes refer the volume group.

You would need to execute vgchgid if the source and BCV copies are to be mounted in the SAME node. In this case, since the VGID will be same in both the source and BCV snapshots, you need to change the VGID on the BCV snapshots before you can mount them. This is primarily becoz kernel will not allow two volume groups with the same VGID be activated.

But if your BCV snapshots are going to be mounted on a different node, then you dont need to execute vgchgid.

[Todd McDaniel_1]

HostA has the real disks.
HostB has the BCVs which is where Im tryin to mount them. HostB cannot see the STD devices on HostA.

I know all of the BCV disks via my Syminq output from EMC... so I do know the BCVS if I need to specify them.

However, one thing I didnt mention is that I may need to resync the BCVs on HostB with the STD devices on HostA...

I think that may be my basic problem.

[Sundar_7]

Yes, that obviously is an issue here if you have created /dev/vgoradata/fs03 and fs04 after the last time you syncd your BCV with STD devices.

I think the error messages seem to make sense to me :-). Sync up BCV with STD, you should be good to go.

[Todd McDaniel_1]

yes I think that is it...

I talked with my DBA and he is goin to do that establish and let me know.

I probably blew away the disk header when I mounted them as FS.




So check back tomorrow same Bat channel!!! for the exciting conclusion!!!

[Michael Tully]

Todd,

We do this scenario just about twice a week.

When finished with the BCV's and want to resync
On host that has the BCV's mounted
Unmount all valids filesystems
deactivate the volume groups
# vgchange -a n /dev/myvg
Remove the volumes
# vgexport /myvg
# rm -rf /dev/myvg

Go to the system that does your symcli commands and start your resync, hopefully you are using device groups, otherwise it is very difficult.

e.g
# symmir -g mygrp -noprompt establish

Once the volumes are sync'ed you can then split them off again ready for the host to use them.

# symmir -g mygrp query (to check synching progress)

# symmir -g mygrp -instant -noprompt split

Go to intended host

# mkdir /dev/mygrp
# mknod /dev/mygrp/group c 64 0x090000
# vgchgid `cat mygrp_rdsk` (list of LUN devices on a single line e.g. /dev/rdsk/c10t2d0 /dev/rdsk/c10t2d1 ...) This changes the VGID to the current system

# vgimport -v -m mygrp.mapfile -p /dev/mygrp `cat mygrp_dsk` (list of devices on a single line like before e.g. /dev/dsk/c10t2d0 /dev/dsk/c10t2d1 ...)
This was the preview, if all okay drop the preview option.

# vgimport -v -m mygrp.mapfile /dev/mygrp `cat mygrp_dsk`
After a successful import you can then mount your filesystems. You may still need to run an fcsk on each logical volume prior to mounting.

HTH
Michael

[Todd McDaniel_1]

It worked!!!

I think since I had mistakenly used the BCVS as real FS... I blew away the disk header.

My DBA re-established the BCVs with the STD devices.

Here is my output from my import command.

# vgimport -s -v -m vgoradata.mapfile.todd /dev/vgoradata
Beginning the import process on Volume Group "/dev/vgoradata".
Logical volume "/dev/vgoradata/fs01" has been successfully created
with lv number 1.
Logical volume "/dev/vgoradata/fs02" has been successfully created
with lv number 2.
Volume group "/dev/vgoradata" has been successfully created.
chdcfas1-root:/root/LVMcommands/BCVmounts
# vgchange -a y /dev/vgoradata
Activated volume group
Volume group "/dev/vgoradata" has been successfully changed.

[Todd McDaniel_1]

Thanks all... it was my own stupidity.

As usual I made it harder than it should have.