vgchange issues with EMC Timefinder on BCVs

[W L Wong]

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 are TF sync'ed into BCVs in HostB on a daily basis as backup.

BCV disks on hostB were setup as follows :
1. Timefinder full sync from hostA_STD to hostB_BCV
2. Split
3. hostA : vgexport -p -v -m
4. copy map files to target system
5. hostB : mkdir vg, mknod
6. vgchgid
7. vgimport -v -m
8. vgchange -a y
9. vgcfgbackup
10. fsck
11. edit /etc/fstab
12. mount fs

At this point, hostB's BCVs have got same filesystems as hostA's STDs.

Daily backup script then does the following :
1. Umounts filesystems of BCVs
2. Deactivate BCV VGs on hostB via "vgchange -a n "
3. Perform Timefinder incremental sync and splits
4. Reactivate VG via "vgchange -c n " and "vgchange -a y "

At this point, the following errors occur :

vgchange: Warning: Couldn't attach to the volume group physical volume "/dev/dsk/c9t2d1":
Cross-device link
vgchange: Warning: Couldn't attach to the volume group physical volume "/dev/dsk/c11t2d2":
Cross-device link
vgchange: Could not attach to volume group "/dev/vgdata01" all of
its physical volumes.
vgchange: Warning: couldn't query physical volume "/dev/dsk/c9t2d1":
The specified path does not correspond to physical volume attached to
this volume group
vgchange: Warning: couldn't query physical volume "/dev/dsk/c11t2d2":
The specified path does not correspond to physical volume attached to
this volume group
vgchange: Warning: couldn't query all of the physical volumes.
vgchange: Warning: Couldn't attach to the volume group physical volume "/dev/dsk/c9t2d1":
Cross-device link
vgchange: Warning: Couldn't attach to the volume group physical volume "/dev/dsk/c11t2d2":
Cross-device link
vgchange: Warning: couldn't query physical volume "/dev/dsk/c9t2d1":
The specified path does not correspond to physical volume attached to
this volume group
vgchange: Warning: couldn't query physical volume "/dev/dsk/c11t2d2":
The specified path does not correspond to physical volume attached to
this volume group
vgchange: Warning: couldn't query all of the physical volumes.
vgchange: Couldn't activate volume group "/dev/vgdata01":
Quorum not present, or some physical volume(s) are missing.

vgchange: Warning: Couldn't attach to the volume group physical volume "/dev/dsk/c9t2d3":
Cross-device link
vgchange: Could not attach to volume group "/dev/vgdata02" all of
its physical volumes.
vgchange: Warning: couldn't query physical volume "/dev/dsk/c9t2d3":
The specified path does not correspond to physical volume attached to
this volume group
vgchange: Warning: couldn't query all of the physical volumes.
vgchange: Warning: Couldn't attach to the volume group physical volume "/dev/dsk/c9t2d3":
Cross-device link
vgchange: Warning: couldn't query physical volume "/dev/dsk/c9t2d3":
The specified path does not correspond to physical volume attached to
this volume group
vgchange: Warning: couldn't query all of the physical volumes.
vgchange: Couldn't activate volume group "/dev/vgdata02":
Quorum not present, or some physical volume(s) are missing.

--------------------
To fix the VGs on hostB, I have to vgcfgrestore and then activate them, and fsck and mount them.

Does anyone know why this happens? How can I fix this?

[Jakes Louw]

I assume that you are creating the VGs with unique minor numbers?

[Bryan D. Quinn]

Hello,

I think you need to perform another vgchgid.

Daily backup script then does the following :
1. Umounts filesystems of BCVs
2. Deactivate BCV VGs on hostB via "vgchange -a n "
3. Perform Timefinder incremental sync and splits
4. vgchgid on BCV volumes
5. Reactivate VG via "vgchange -c n " and "vgchange -a y "


Hope this helps!

-Bryan

[W L Wong]

The script works on other systems with no issues....I'm bummed. Any more ideas?

[Geoff Wild · Accepted solution]

My question to you is - why do you need to do a vgchgid?

Standard host:

vgexport -p -v -s -m /tmp/vgXX.map

Copy map file to backup server.

Split bcv's

Backup Server:

mkdir /dev/vgXX
mknod /dev/vgXX/group c 64 0xHH0000

XX = vg numberr, HH = vg number in hex

vgimport -v -s -m /tmp/vgXX.map /dev/vgXX

Then in backup script:

/usr/symcli/bin/symmir -g $DEVICE_GROUP -noprompt establish

symmir -g $DEVICE_GROUP -noprompt split

vgchange -c n $VOLUME_GROUP
vgchange -a y $VOLUME_GROUP

Then mount them...

For masking, make sure the backup server can only see the bcv's - NOT the standards...

Rgds...Geoff

[Bryan D. Quinn]

Hello,

Ok disregard my post. We have a script that was written by EMC professional services, but it is different than what you are doing. We are not moving the map files over to the other host. We just do a vgchgid.

Sorry about that.

-Bryan

[Geoff Wild]

To get rid of the Cross-device link - vgexport those vg's (bcv's) on the backup server, then split the bcv's, mkdrir/mknod the vg's on the backup server and re-import.

Rgds...Geoff

[David Child_1]

As Geoff mentioned, you really don't need to do the 'vgchgid'.

The 'vgchgid' is really only needed when the "BCV host" has access to both the STD devices and the BCV devices. You mentioned each host only sees its own devices (hostA->STDs & hostB->BCVs).

We have some systems that see both BCVs and STDs (in MC/SG cluster) where we need to use the vgchgid and other systems like yours where each host only sees its respective devices. In the later case we don't use 'vgchgid' since the BCV host could only "grab" its own devices.

Important! Not using 'vgchgid' make maintenance easier since you don't need to worry about device files, but if there is ANY chance that at some point in time hostB could access the STD devices, please use 'vgchgid'. You don't want to have hostA and hostB mistakenly trying to access the same devices at the same time.

That being said, here is how I would do it:

1. Umounts filesystems of BCVs
2. Deactivate BCV VGs on hostB via "vgchange -a n "
3. export the volume groups via 'vgexport '
4. Perform Timefinder incremental sync and splits
5. Create new maps on hostA via 'vgexport -s -v -p -m //.map /dev/'
6. scp hostA://.map hostB://.map
7. mkdir;mknod
8. vgimport -s -v -m //.map /dev/
9. Reactivate VG and mount file systems.

You might ask why make a map file each time, etc? Your symptoms look like some device files on hostB have changed. Is this host SAN attached to your Symmetrix? Has anyone moved the storage-side port on the switch? That is one thing that would cause new device files to be created.

Anyway, if your environment is fairly stable then you could skip steps 3 & 5-8. We use it because we are constantly adding/removing/expanding Lvols, etc. and we have had problems on the BCV host due to incorrect LV Names, missing disks, etc. By generating fresh maps each time and using the share option with vgexport/vgimport, we are certain to always get the latest... unless a new volume group is created for a database and the admin forgets to update the TimeFinder device group, etc.

But thats another story...

David

[Sundar_7]

Hi,

We have a similar setup.

Here is what we do

1) Full sync HostB_BCV with HostA_STD
2) BCV Split
3) in HOSTA: vgexport -p -v -m .map > .disks

vgexport also outputs the PVs that are part of this volume group. We capture the output to a file

3) rcp vg.map and vg.disks to HostB.

4) vgchgid

5) HostB has a text file which maps the BCV to the standard device

6) for the PVs in vg.disks , get the corrosponding BCV device from the text file and vgimport.

7) vgchange and mount.

Sundar

[W L Wong]

Thanks to everyone, esp Geoff and David.

vgchgid was indeed the culprit!

Sundar, how does it work in your environment? Doesnt seem to like vgchgid in ours.

cheers!