MC Service Guard error

[Sana Chaarani]

Hi,

When I check the configuration of my cluster with the cmcheckconf file, I have an error on all my VGs, saying : ERROR, vgapp1 is configured differently on node1 than it is on node2

It goes on and then say anyways, checkconf completed with no errors. Run cmapplyconf.

What does that mean ?

Thanks for your help

Sana

[V.Tamilvanan]

Hi,
Can you check for the consistency of both the package configuration and package control file on both the systems.
If possible attach the syslog.log file.

HTH

[Animesh Chakraborty]

Hi,
I think it is due to alternate path of the harddisk(pv link).

You can add or remove alternate link with vgextend/vgreduce command as necessary.

[Karthik S S]

Is the VG - vgapp1 is shared b/w both the systems??. If not you can ignore this error. If it is shared then,

1. On the 1st node export the VG - vgapp1, ftp the map file to the 2nd node.

"vgexport -m /tmp/vgapp1.map -p -v vgapp1"

2. Do a "vgexport vgapp1" on the 2nd node.

3. Create VG directories under /dev, create a group file with the same minor number, and import the VG using vgimport command

After this you again run cmcheckconf and check if the error repeats ...

Karthik

[V. V. Ravi Kumar_1]

Hi,
What is your FIRST_CLUSTER_LOCK_VG in your cluster config ascii file.
It should be shared and accessed by all the nodes in the cluster. if not do an export with -p option on primary node and import on secondary nodes, as suggested.

Regards

[Massimo Bianchi]

Hi,
is the number of disk, including alternate link, cpnfigured correctly ?

If on one node there a re the PVlinks and not on the other, SG will complain a lot.

If you are absolutely sure regarding lvm, you can even sckip those checks (option -k if i remember well), but use it with care

Massimo

[Stuart Abramson_2]

Well, did you look at "vgapp1" on both nodes and verify that they were identical or not?

[Stephen Doud]

I believe Animesh is on the money. I see this problem frequently in customer calls at the HP Solution Center.

The cluster creation process is preceded by VGCREATE-ing volume groups on one server and VGIMPORT-ing them into the other cluster node. A summary of the process for a ServiceGuard'ed package VG is:

1. VGCREATE a volume group from disks that are seen by multiple nodes.

2. Create a volume group MAP file and copy it to the adoptive nodes. The map file is created with the VGEXPORT -S option, causing the resulting file to contain the VGID at the top of the file.

3. Use the map file to VGIMPORT the VG on the adoptive node.

The problem comes in step 1 - the VGCREATE process. It does not require the Admin to include the alternate links to the disks. Thus they are not included in /etc/lvmtab. Though the VGEXTEND command can be used to add them into /etc/lvmtab later, most admins forget to do so.

Step 3 properly loads ALL of the /dev/dsk paths to the disks into the lvmtab file on the other node, because the VGID helps VGIMPORT find all of them.

When cmcheckconf/cmapplyconf are performed, ServiceGuard causes both nodes to compare /etc/lvmtab for each VG. If the number of paths listed for each VG does not match between nodes, though they are the same VG, a WARNING is generated on newer versions of ServiceGuard. (Such a problem would have caused an ERROR on older versions of ServiceGuard, preventing cmapplyconf
from being successful).

To correct the problem on the primary node, VGEXTEND the rest of the paths into the /etc/lvmtab file. If the paths are not known, create a map for the VG, export and reimport that VG when it is not active on the node:

$ vgexport -pvs -m map. /dev/

$ ll /dev//group - record the minor number of the "group" file for re-use
during reimport (see JJ in mknod below)

- halt the package operating /dev/ if it is running.

$ vgexport /dev/

$ mkdir /dev/

$ mknod /dev//group c 64 0xJJ0000

$ vgimport -vs -m map. /dev/

$ cmcheckconf -C

-Stephen