cant activated vg after truecopy

[yunardi]

Dear Expert,

On a cluster system (test system), I'm doing a storage truecopy between 2 identical storage (source and target). I have shutdown the cluster on target first before truecopy running.

But after truecopy I can't running the package :
Dec 9 17:25:36 - Node "sapr3db": Activating volume group vgsap with exclusive option.
vgchange: Volume group "/dev/vgsap" belongs to a different Cluster. Activation failed.
ERROR: Function activate_volume_group
ERROR: Failed to activate vgsap
Dec 9 17:25:36 - Node "sapr3db": Deactivating volume group vgsap
vgchange: Volume group "vgsap" has been successfully changed.

I try to activated manually, but still error :
sapr3db:/etc/cmcluster/P11>vgchange -c n vgsap
Performed Configuration change.
Volume group "vgsap" has been successfully changed.
sapr3db:/etc/cmcluster/P11>
sapr3db:/etc/cmcluster/P11>vgchange -a y vgsap
vgchange: Activation mode requested for the volume group "/dev/vgsap" conflicts with configured mode.
sapr3db:/etc/cmcluster/P11>
sapr3db:/etc/cmcluster/P11>strings /etc/lvmtab
/dev/vgsap
G:vv
/dev/dsk/c10t0d0
/dev/dsk/c12t0d0

I have done this before on non cluster system and had no problem. This time I'm running it in cluster. Do I need to export and re-import vg ?

Thanks,

[Johnson Punniyalingam]

>>>Do I need to export and re-import vg ?<<

Yes, You should please see below example.


# vgchange -a -e /dev/vg_database vgchange: Warning: Couldn't attach to the volume groupphysical volume "/dev/dsk/c3t2d0":Cross-device linkvgchange: Activation mode requested for the volume group"/dev/vg_for_dd" conflicts with configured mode


# vgexport /dev/vg_for_dd # mkdir /dev/vg_for_dd # mknod /dev/vg_for_dd/group c 64 0x040000 # vgimport /dev/vg_for_dd /dev/dsk/c3t2d0

[yunardi]

Hi Johnson,

Thanks for reply.

I have vg map file from source vg. Usually I used to reimport vg by vgimport -p -s -m vgxxx.map vgname.

But in this cluster environtment, is there any procedure I must do first before export/import ? for example shutdown the cluster daemon ?

Is there will be any impact on cluster config if I reimport the vg, may be I need to recompile the cluster ?

Thanks,

[Eric SAUBIGNAC]

Bonjour Yunardi,

Not sure but I remenber that I did the same thing in a cluster. The problem was that both VG, source and copy, have the same VGID. And MC/ServiceGuard is aware this.

So you should change VGID on one VG, the copy one seems to be the good target. See "man vgchgid". Be aware that you MUST do this command in a single pass on ALL disks from the copy VG at a time.

Eric

[likid0 · Accepted solution]

Here is an example, all of this should go in a script, with all it's checks fsck's etc, just and example from man:


1. The system administrator uses the following commands to create the
Business Continuity (BCV or BC) copy:

1) For EMC Symmetrix disks, the commands are BCV establish and
BCV split.

2) For XP disk array, the commands are paircreate and pairsplit.

Three BCV disks are created.

2. Change the VGID on the BCV disks.

vgchgid /dev/rdsk/c0t0d0 /dev/rdsk/c0t0d1 /dev/rdsk/c0t0d2

3. Make a new volume group using the BCV disks.

mkdir /dev/vgbcv
mknod /dev/vgbcv/group c 64 0x040000

4. Import the BCV disks into the new volume group.

vgimport /dev/vgbcv /dev/dsk/c0t0d0 /dev/dsk/c0t0d1 /dev/dsk/c0t0d2

[yunardi]

Dear All,

The problem solved. Don't need to reimport the vg since this is on different cluster and different storage.

After true copy compled the split process, just do :
shutdown the cluster and set cluster not to autostart after system restart.
vgchange -a n vgxxx
vgchange -c y vgxxx
startup cluster/package

Thanks all for the response.

[yunardi]

Case closed