cluster enabling for shared vg

[Ra Jose]

In SG environment, I know that we execute "vgchange -c y vgNAME" to make vgNAME cluster aware. This is done only once. I have seen people doing it whenever a pkg is brought up. The cluster pkg does not do the above command, it only imports the vg by doing "vgchange -a y vgNAME". Does anybody know why we have to run "vgchange -c y vgNAME" everytime? Is there anyway to verify whether a vg is cluster enabled or not.
Thank you all for your replies.
Rajos

[A. Clay Stephenson · Accepted solution]

The vgchange -c y command only needs to be done one time and because the change is written to the LVM metadata area of the disks themselves, once that change is made, it applies to all nodes. The "VG Status" line of vgdisplay will indicate "exclusive" although this can only be displayed on the currently active node.

[Sundar_7]

vgchange -c y VGNAME needs to be executed only once. But there are exceptions to it, especially if you use hardware replication with the combination of SG for Diaster Recovery.

But in most cases, vgchange -c y VGNAME will need be done only once. This installs the Cluster ID in the LVM headers and can only be activated in the exclusive mode from then on and the node on which is activated should be running the cluster daemons.

vgchange -a y VGNAME - doesnt import the volume groups. It merely just activates the volume groups. Unlike VxVM, you dont dynamically import the VG config in LVM.

Once you ran vgchange -c y on a VG, you CANNOT activate the VG using vgchange -a y. It should be activated using vgchange -a e.

[Duncan Edmonstone]

Rajos,

Well first, the cluster packag script should be doing:

vgchange -a e vgNAME

not:

vgchange -a y vgNAME

If someone is having to do a vgchange -c y vgNAME before starting you package, that may be beacuse someone wanted the filesystems mounted when the package and cluster were down and used:

vgchange -c n vgNAME
vgchange -a y vgNAME

which would remove the VG from the cluster and activate in standard mode.

Unless someone is doing this every time, I can't think why you would have to keep doing a vgchange -c y vgNAME, unless there is something dodgy in /etc/lvmrc

If the vg is cluster enabled then:

vgchange -a y vgNAME

would fail.

HTH

Duncan

[Steven E. Protter]

Shalom,

Note that HP does not provide a filesystem capable of handling shared access. You will need something like that to prevent your cluster from melting down after you enable and mount in shared mode.

SEP

[Ra Jose]

Thank you all. Sorry for the typo as Sunder and Duncan noted that it is "vgchange -a e".