VG activation modes difference

[Fenny_1]

Hi All,
in all my cluster packages VG are getting activated with exclusive option

vgchange -a e

now i want to change that into

vgchange -a y

can anyone tell me wat impact that change will make and after changing that would i be able to shift my package to failover node?
And is there anyother cluster file needs to be changed except *.cntl?

and what steps i need to perform to make that change is it's a production node and i dont wana take any risk.

Thanks in advance waiting for a quick response.

[Torsten.]

Please read this man page

http://docs.hp.com/en/B2355-60105/vgchange.1M.html

and you will see that you don't want to change this.

vgchange -a e

is pretty normal for a VG in a cluster.

[Fenny_1]

Hi torsten,
Actually i need to synch my BC volumes with my production volumes.
As right now my production volumes are activated in exculsive mode so after resync i cant mount my BC volumes on any other node.

As during vgchange, it gives me error

vgchange: Activation mode requested for the volume group "/dev/BC1_xpvgsieapp" conflicts with configured mode.

So to resolve that, i need to activate my VG's in production without exclusive option.

I hope you'll understand my prb. waiting for your feedback

[Doug O'Leary]

Hey;

Good catch on the reason for the issue but bad idea on the resolution. You need to keep the vgs activated in exclusive mode on the production servers. Any number of errors will result if you don't do that - not the least of which is your packages won't start.

The correct action is to run vgchgid on the bcvs. It's absolutely essential to ensure you run vgchgid on *all* the BCVs simultaneously - in one call.

vgchgid will change the volume group ID on the disks. It comes up with a new ID every time it's run so if you dont' run it on all the BCVs simultaneously, you'll have to resync the BCVs with the production and star t over.

The process you want to import the bcvs will look something like:

set -A bcvs $(list-o-bcvs-that-belong-to-one-vg)
/usr/sbin/vgchgid ${bcvs[*]}
mkdir /dev/vg_backup
mknod /dev/vg_backup/group c 64 0x0#0000
vgimport -m ${map} vg_backup ${bcvs[*]}

HTH;

Doug

[Torsten.]

Don't know what VG is which one, sorry. I don't know your config.

As stated in the man page, you need to disable the cluster mode (-c n) (and halt the package) to be able to use "-a y".
Maybe "-a r" can help you.


If you don't want to stop this node, do nothing.

[Torsten.]

read also

http://docs.hp.com/en/B2355-60105/vgchgid.1M.html

to understand the background.

[David Bellamy]

Fenny the method Doug explained is the method we use to split our BCV'S for backup. if you create a script it is pretty easy to do it at any time.

[Fenny_1]

Hi All,
Thanks for all your replies. I tried VGCHGID but the problem is that the command is hanged for so long and didnt gave me any result.
Could anyone tell me wats the reason for that.

[Doug O'Leary]

Hey;

You did split the bcvs before running the vgchgid command, right? That command is damn near instantaneous so any delay is a cause for concern.

Please post the commands exactly as you typed them so we can get a better idea what happened.

Doug

[Ninad_1]

Fenny,

As Doug has already said you need vgchgid and then vgimport.
The high level steps for using BC copies is -
Take a vgexport -v -p -m vg01.map /dev/vg01
and so on for all the VGs on the production [ the -p is very important so that actual export does not happen, only map file gets created] Copy the map files onto server you will use for BC volumes.
1. Take BC copies into PSUS state
2. Split the BC pairing to bring the LDEVs to PAIR statee
3. On the server where you want to use the BC volumes (assuming the BC vols are visible to the server) - do a
vgchgid /dev/rdsk/cxtydz /dev/rdsk/...
for disks [ BC vols ] belonging to same VG
4. mkdir /dev/vg...
mknod ....
5. vgimport -m map_from_prod_vols /dev/vg.. /dev/dsk/cxtydz ...
6. vgchange -a y /dev/..
7. Mount filesys

Also please provide the exact steps and exact commands you have used to help you further.

Regards,
Ninad

[Gary L. Paveza, Jr.]

I couldn't tell if you were mounting your BCV onn your production server or a secondary server. I use a secondary server here (backup server).

To activate the volume group on the BCV, I do the following:

vgchange -c n /dev/vgXXX\
vgchange -a y /dev/vgXXX

Note that this is on the secondary server - not on the primary.

It removes the cluster lock on the BCV volume groups (which is not needed because there is no cluster).

You have to do this every time you split/mount. When you sync back, just issue a vgchange -a n /dev/vgXXX and sync. The sync will put the cluster lock back on the disk.

[Fenny_1]

I want to mount my BC volumes to another server not on the primary machine

[Gary L. Paveza, Jr. · Accepted solution]

Then you don't need vgcgid unless you already have a vg with that ID.

The way I do it:

Whenever I make a change to the volume group on the primary server I recreate it on the backup server:

On primary:

vgexport -m /var/tmp/vgXX.map -s -p -v /dev/vgXX
copy /var/tmp/vgXX.map from primary to backup server

Do BCV Split

On backup server

vgexport /dev/vgXX
mkdir /dev/vgXX
mknod /dev/vgXX/group c 640xYY0000
vgimport -m /var/tmp/vgXX.map -s -v /dev/vgXX

You have to remove the cluster mark on the volume group on the backup server

vgchange -c n /dev/vgXX

Activate it:

vgchange -a y /dev/vgXX

Now you can mount your filesystems.

To sync the BCV

umount all your filesystems
vgchange -a n /dev/vgXX

Sync your BCV.

Repeat split, vgchange -c n /dev/vgXX, vgchange -a y /dev/vgXX each time you want to split.

I've seen several other scripts where the vgimport portion is built into the script so you don't have to worry that you'll forget.