Can't use volume group(s) when recreating cmclconfig

[Stack]

When setting up our cluster our initial cmclconfig binary file was deleted. When we try to recreate a cluster binary file serviceguard tells us the volume groups belong to another cluster. What is the best method to remove the previous cluster information from the volume group(s) so we can continue to recreate the cluster? I tried "vgchange -c n", but it didn't work. Do I need to vgexport/vgimport the vgs? Thanks.

[Marco Santerre]

So just to make sure on what you are doing is that you are just taking the ascii that was once created a while ago and doing a cmapplyconf?

My suggestion is if you cluster is still running, I would do a cmgetconf and then a cmapplyconf with your cluster down

[Hoefnix]

If it still complains about vg's belonging to another cluster while you cluster is running, try to do vgchange -c y (after your previous vgchange)

then try to run cmquerycl -C /etc/cmcluster/cmclconfig.ascii

Then just do an cmapplyconf -C /etc/cmcluster/cmclconfig.ascii

Hopes this works fine.

[Stephen Doud]

'vgchange -c n ' should work. IT should strip the cluster ID and the 'exclusive' activation mode from the VG.

Please provide the specific messages that were reported when the vgchange failed.

Vgexporting 'clustered' vg's does not remove any data structures from the VGDA on disks in that vg, hence, vgimport will only restore the VG to the /etc/lvmtab but will not remove any cluster-related information from the disk.

-StephenDoud

[Stack]

Thanks to all. Somehow when the cluster creation failed, the volume group was never properly deactivated on the second node and so the vgchange -c n never worked properly. When we deactivated the volume group on BOTH nodes, we were able to successfully remove the cluster info and rebuild the cluster.