cmcheckconf produces error

[Elif Gius]

Hi all,

I deleted a vg from a cluster package which had two vgs. I deleted it from the package.cntl, the cmclconfig.ascii.
I did a vgchange -a n, vgchange -c n ...
then I wanted a cmcheckconf -C cmclconfig.ascii - but there I got an error:

"... Error: Unable to determine a unique identifier fpr physical volume /dev/dsk/... no node xxx. Use pvcreate to give the disk an identifier.
...
cmcheckconf : Unable to reconcile configuration file cmclconfig.ascii with discovered configuration information."

Then I tried a cmquerycl -v -C test_cmclconfig.ascii -n node1 -n node2. But again I got errors:
"... Error: Unable to determine a unique identifier fpr physical volume /dev/dsk/... no node xxx. Use pvcreate to give the disk an identifier.
...
Failed to gather configuration information."

Has anyone an idea?

[Hoefnix]

Hi,

Did you check if you used "FIRST_CLUSTER_LOCK_VG" in the cmclconfig.ascii (can it be that you try to use the removed VG for lock?)

If not I would suggest to grep all config files on the name of the volumegroup.


HTH,
Peter

[Bart Paulusse]

Hi,

Maybe you have to activate the volume group again, run the cmcheckconf so that the configuration change can be adopted in the cluster and then throw away the vg. It looks as if cmcheckconf wants to see the vg before removing it from the configuration.


regards,

Bart

[Hoefnix · Accepted solution]

Hi,

mquerycl searches all specified nodes for cluster configuration and
Logical Volume Manager (LVM) information.

So if the volume still exist in the /etc/lvmtab it will complain about it, because it has no cluster identifier on it (vgchange -c n).

Remove it from the LVM configuration and try again.

HTH,
Peter

[Kent Ostby]

Two ideas:
1) Have you run the "vgchange -c n" from both nodes in the cluster ?

2) Have you physically removed the disks from the system ? If you have removed the disks physically from the system and they are still in the /etc/lvmtab on either system, this can cause the error you are seeing. If they have been physically removed from the system, you need to vgexport the volume group from /etc/lvmtab otherwise SG will attempt to read them again.

Best regards,

Kent M. Ostby

[Ashwani Kashyap]

if that vg was your your cluster lock VG , then you have problems . you should not delete that .

Secondly , mere deleting the entries from the ascii files dose not delete them . Service guard reads all the configuration in the ascii files from the binary file located at /etc/cmcluster/cmclconfig . That file also have to be updated by doing a cmapplyconf of the newly updated ascii files .

[Elif Gius]

hi, thanks for all answers...
we found following.
one VG was only with one PV; the alternate link was missing; the one who has configured this vg forgot to add the alternate path...
at a vgdisplay -v /dev/VGNAME we got an error - could'n query physical volume.
So my collegue and I tried following on one node:
- rmsf /dev/dsk/c21t6d0
- rmsf /dev/rdsk/c21t6d0
- then make a copy of /etc/lvmtab; then removed the lvmtab;
- build a new lvmtab with vgscan
- insf -e
- vgextend /dev/VGNAME /dev/dsk/c21t6d0

after that we exported the vg on node2 and then imported it again

after that the cmcheckconf worked fine, although some warning msgs came.