vgchange -c y

[Ed Kwan_2]

How can I tell if a vg already has the -c flag set ?

I ran into cannot activate vg exclusively message in ServiceGuard periodically, its easy to fix but can I find out ahead of time.

Thanks, Ed

[Sridhar Bhaskarla]

Hi Ed,

To find it ahead of the time, one way is to do a vgchange -a y vgxx and it should complain saying that the requested mode conflicts with the configured mode. Then you can perform a vgchange -c y and start up the cluster.

-Sri

[Sridhar Bhaskarla]

Hi (Again),

Friday evening.

If "vgchange -a y " is successful, then it means it is not cluster aware and you can do a "vgchange -a n" followed by "vgchange -c y". If you get the error, then you are good.

-Sri

[Oleg Zieaev_1]

Hello Ed.

In vgdisplay output you will see on VG Status line available, exclusive.
vgchange will not let you do -e or -s unless your group is configured as cluster aware (vgchange -c). Please note that in order to do vgchange -c vgXX your system must have cmld daemon running.

Hope this helps,
-0leg

[Ed Kwan_2]

Thanks for all the answers.

However, I cannot try to activate it because its already activated on the primary node.

Vgdisplay will tell me the activated vg is in Exclusive mode, the problem was when I fail over to the 2nd node, the same vg fail to activate because the -c flag is not set.

I can workaround it, just wondering if there is a way to tell on the failover node.

Thanks, Ed

[Oleg Zieaev_1]

Ed,
On failover node you do not have to worry about the mode.
You create your group file for VG and then vgimport -v -s -m vgXX.map vgXX

Once package is started your volume group will be activated in the correct mode.
Just make sure your VG is mentioned in cmclconf.ascii file :)

Hope this helps.
-0leg

[Sridhar Bhaskarla]

Hi Ed,

If you are looking at the failover node, you do not need to bother if the volume group is already activated on the primary group unless the activation mode you specified on the primary node is not default viz., "vgchange -a e".

Look at your control file (search for VGCHANGE) to see if the activation mode does not match on both the nodes.

-Sri

[A. Clay Stephenson]

That data is carried in the PV's themselves so that the vgchange -c y only needs to be done once on any server in the cluster. This change will then apply to any host that tries to activate this VG.

[melvyn burnard]

well if you want to get REALLY technical, you can always use adb to look at the lVM headers.
For example, assuming the PV is /dev/dsk/c1t6d0
doing:
echo "0x12080?84X" | adb /dev/dsk/c1t6d0

results in something like this being returned:
12080: 0 1 21D734 0

Note we get the location (12080) echoed back, followed by four fields (because we specified 4X).
The fourth field is a zero if NOT a clustered PV, but returns the Cluster id if it is part of a clusterd vg as follows:

12080: 0 0 0 3E4BAD31

So here the PV is cluster aware, and is part of cluster id 3E4BAD31
HTH

[Ed Kwan_2]

Melvyn has the answer I was looking for. Thank you for everybody to respond.

My original problem was somehow some of the vg has lost its -c setting and therefore will not failover correctly. It was documented in one of the postings in ITRC, when you do a cmapplyconf without specifying some of the vg at the bottom of the cluster configuration file.

Thanks for all the help.