topic Error while executing cmgetconf in Operating System - HP-UX

Error while executing cmgetconf

vinay_26 — Tue, 05 Jul 2005 05:57:37 GMT

Hi I wanted to add a new Vg on the cluster. When i execute the command cmgetconf it says gathering information and later it gives error as shown below. Even the ascii file is not created to modify the same.

Error: Found two volume groups with the same name /dev/vg_p01_ss01.bcv1 but different ids:
Error: One of the two VGs is configured on nodes:
john james
Error: The other VG is configured on nodes:
abraham

Re: Error while executing cmgetconf

Stephen Doud — Tue, 05 Jul 2005 07:16:20 GMT

In a Serviceguard configuration, a volume group name must have the same VGID across the cluster and vice versa.

The VGID is located in the /etc/lvmtab file on each server and on each disk in an LVM volume group.

Since the VG has the same name across servers, cmgetconf was probably finding an old VGID in one or more of the /etc/lvmtab files, or you in truth have two different VG's with the same name, but different VGIDs.

To see if this is true, on each of the servers in the cluster execute:
# vgexport -pvs -m
vg_p01_ss01.bcv1.map /dev/vg_p01_ss01.bcv1

At the top of the resulting file (vg_p01_ss01.bcv1.map), notice the VGID line... which contains a unique identifier for that VG.
On one of the servers, the VGID will probably be different. If it is not, then /etc/lvmtab may be out of sync across nodes. To remedy this, vgexport the VG, and re-import it (after insuring the map file is newly created)

If necessary,
# cmhaltpkg (package controlling the VG)
# strings /etc/lvmtab > lvmtab.now
# ll /dev/vg_p01_ss01.bcv1/group (record the minor number of the 'group' file - 0xNN0000)
# vgexport -vs /dev/vg_p01_ss01.bcv1
# mkdir /dev/vg_p01_ss01.bcv1
# cd /dev/vg_p01_ss01.bcv1
# mknod group c 64 0xNN0000 (use the NN recorded just above)
# vgimport -vs -m vg_p01_ss01.bcv1.map /dev/vg_p01_ss01.bcv1

Since the name of the VG includes the term 'bcv', I assume that this is an EMC BCV volume group which at one time was split off from it's primary data VG, and perhaps a vgchgid was performed to give the split-off VG a unique VGID - which is a good thing. However, I think some maintenance wasn't performed properly on some of the nodes, because either 'john' and 'james' or 'abraham' have an old VGID. Best to inspect your procedures involving this BCV to see if the VG needs to be exported on one or more machines after
re-merging it back with the primary data VG.

Re: Error while executing cmgetconf

vinay_26 — Tue, 05 Jul 2005 08:20:07 GMT

You are right stephen i checked the VGIDs its same accross 2 systems and unique in the system where the VG is activated.What will be the impact.

1. what will be the impact if i leave it as it is?

2. do i need to correct this before i make changes to the cluster?

Re: Error while executing cmgetconf

Stephen Doud — Tue, 05 Jul 2005 08:53:55 GMT

> What will be the impact

You will not be able to make any changes to the cluster until you correct the condition because all of the cluster configuration commands will stumble on the problem.

Why is the BCV VG listed in lvmtabs where it is not activated? If it is a BCV VG, then won't it be re-merged into vg_p01_ss01 at some time?

If you don't want to permanently remove the BCV vg from the other 2 nodes, do the following:

On the node where the VG is active, create the map file per my previous steps.

Then copy the map file to the other two nodes.

Per the steps I described previously, vgexport the vg_p01_ss01.bcv1 VG from the other two nodes, and re-import it.
After this, cmgetconf should work - as well as the other cluster configuration commands.

Re: Error while executing cmgetconf

vinay_26 — Tue, 05 Jul 2005 09:29:53 GMT

so Exporting the mapfile from the node where its active and importing it on to the other 2 nodes is sufficient.

I hope there is no restart of package or cluster is required for the mentioned activity?

Re: Error while executing cmgetconf

Stephen Doud — Tue, 05 Jul 2005 10:11:25 GMT

The vgexport/vgimport will take place on the nodes where the package is not active. Hence, no interference with any currently running cluster activity.
vgexport/vgimport does not affect and cluster information on the LVM structures on the disk - so this should be all that you have to do to correct the problem.