same VGID for vg00 on different nodes

[njia_1]

Hi

I am having a strange problem when I tried to add an additional node to a two nodes cluster.

We have a small SAN and about 12 mixed rp24* and rp34* server. They are all connected to a HITACHI SAN.

The existing 2 nodes cluster consists of 2 rp2470. The way these two nodes were build is I used one rp2470 instlled HPUX + service guard + whatever need to a LUN on SAN. Then created 2 shadow image(low level copy,done by the SAN) of this LUN. Assigned these two shadow image to another 2 rp2470, change hostname, IP address. Then configured the 2 nodes cluster without any problems.

Now when I tried to added an additional node(fresh installed HPUX) to the cluster, I saw the following error messages when I did cmcheckconf -v -C ./cmclconf.ascii

Error: Found two volume groups with the same name /dev/vg00 but different ids:
Error: One of the two VGs is configured on nodes:
mms24a mms24c
Error: The other VG is configured on nodes:
mms24b
Error: Found two volume groups with the same name /dev/vg00 but different ids:
Error: One of the two VGs is configured on nodes:
mms24b
Error: The other VG is configured on nodes:
mms24a mms24c
Warning: The volume group /dev/vg00 is activated on more than one node:
mms24a
mms24c
Warning: Volume groups should not be activated on more than one node.
Use vgchange to de-activate a volume group on a node.
cmcheckconf : Unable to reconcile configuration file ./cmclconf.ascii
with discovered configuration information.

mms24a and mms24c are shadow image of a LUN on SAN so they end up having the same VGID, mms24b is fresh installed so the VGID for vg00 is different.

I am suprised because according to my understanding, vg00 has nothing to do with cluster, I mean it is not shared and of course vg00 on a different server should have different VGID, why the cmcheckconf command is not happy with vg00 ?

Can I change VGID without losing any data ?

[melvyn burnard]

The reason it is complaining about this is as you say, VG's should have different VGID's unless they are shared.
This is usually caused by someone using dd to copy a disc and then using the copied disc as the root disc for another server.

You should be able to change the VGID without any problems, but if you are worried, always do a recovery backup using Ignite first.

[Luk Vandenbussche]

Hi,

I find it strange. Doesn't vg00 contains your bootdisk. Did you make it shareable?

Have you installed also the latest patches for your serviceguard version (available at www.docs.hp.com). This might solve a lot of problems

[Mark Nieuwboer]

njia,

somewere in your cluster configuration is vg00 marked as a cluster volumegroup.
i thing somewhere in the cluster.ascii file.
try to change this in the real cluster volumegroup.

grtz. Mark

[Duncan Edmonstone]

Yes you can vgchgid your vg00 to sort this out.

However, I'd be v. careful about how you do it - vgchgid is usually used on a BCV/BusinessCopy/ShadowImage *before* it's vgimported onto a system. So to be safe I'd go to LVM maintenance mode, vgexport your vg00, then run vgchgid, vgimport, and update root/boot pointers with lvlnboot before rebooting back to multi-user mode.

And of course, keep that Ignite backup handy (or another Shadowcopy maybe?)

HTH

Duncan

[njia_1]

Hi Melvyn,

If I can then how is vgchgid is the command ?

Hi Luk/Mark,

I did not make vg00 shareable, mms24a, mms24c have same VGID for vg00 because these two vg00s are shardow images of a golden HPUX image. Some kind of low-leve coping done by disk array.

Hi Ducan,

your suggestions matches what I found out yesterday myself. but not sure how to boot inot LVM maintenance mode and how to change boot pointers, Could you please provide some more information ?

Question

This cluster was a 3 nodes cluster, all nodes booting form SAN, all have vg00s copied from the same golden HPUX image, so they all have same VGID for vg00 and it is working fine no problem at all.

then I removed mms24b, destoried that LUN(golden HPUX image is kept) now I need to added this third node back to the cluster. Then cmcheckconf commands is not happy about the VGIDs, why it was working before ? with 3 vg00s all have same VGID.

[njia_1]

Hi there,

thanks for all your replies and time, I found a quick solution to this.

I used "-k" option to both cmcheckconf and cmapplyconf commands to verify VGs only listed in cmclconf.ascii file. So VG00s are not checked.

it is working fine now.

thanks