New Package build problem

[Sebastien Masson]

I build a new package in My ServiceGuard cluster, and when I run the cmapplyconf command to apply my new package in the current cluster, I receive this error message :

Warning: Volume group /dev/vgoradata is configured differently on node corvus than on node mensa
Error: Volume group /dev/vgoradata on node mensa does not appear to have a physical volume corresponding to /dev/dsk/c0t9d0 on node corvus (4315643611006792347).
Error: Volume group /dev/vgoradata on node mensa does not appear to have a physical volume corresponding to /dev/dsk/c0t11d0 on node corvus (4315643611006792348).
Warning: Volume group /dev/vgoradata is configured differently on node mensa than on node corvus
Error: Volume group /dev/vgoradata on node corvus does not appear to have a physical volume corresponding to /dev/dsk/c0t9d0 on node mensa (4315643611006371258).
Error: Volume group /dev/vgoradata on node corvus does not appear to have a physical volume corresponding to /dev/dsk/c0t11d0 on node mensa (4315643611006371260).
cmapplyconf : Unable to reconcile configuration file /etc/cmcluster/cltest.config
with discovered configuration information.


Someone can tell me what is the number between parenthesis and what going wrong. Already build many package like this one and I never see that before...

[Duncan Edmonstone · Accepted solution]

At a guess, it's probably a combination of the VGID and the volume physical serial number. Either way the error message seems to suggest that something may have gone awry during your vgexport/vgimport process for your vgoradata volume group. Try deleting and re-creating this volume group on your adoptive node.

HTH

Duncan

[Frederic Sevestre]

Hi,
You should try to export rebuild the vg on one of your nodes.
example : On mensa
vgexport -p -v -s -m vgoradata.mapfile vgoradata
rcp vgoradata.mapfile corvus:/tmp/vgoradata.mapfile

On corvus :

vgexport vgoradata
mkdir /dev/vgoradata
mknod /dev/vgoradata/group c 64 0x0....
vgimport -v -s -m vgoradata.mapfile vgoradata

And try again the cmapplyconf.

Fr??d??ric

[James R. Ferguson]

Hi Sebastien:

Have a look at Knowledge Base document #UMCSGKBRC00007671 (attached). I suspect this may be your problem. As for the number in parenthesis, I'd guess, in part, it's a volume group or physical volume LVM id.

Regards!

...JRF...

[Sridhar Bhaskarla]

I wonder if you are able to see the disks corresponding to the volume groups on the other system. Try exporting and importing the volume groups back on mensa using the "s" option.

-Sri

[Sebastien Masson]

You know what....

On both of my server, the path to disk are /dev/dsk/c0t9d0 and /dev/dsk/c0t11d0. I do a double, triple check, with hardware remove to be sure i'm not on wrong disk.

If I do a pvcreate -f /dev/rdsk/c0t9d0 and then I grab the VGID with echo 0x2008?4D|adb /dev/dsk/c0t9d0 on my both server, I got two different number !@#*!@*&#!*@&#^. What that... please... All my other shared VG show same number across server ..

Thats is the problem I guess :-)

[Sanjay_6]

Hi Stephen,

Hope you did a vgcreate before you tried to look for the VGID.

Do a pvcreate first on both the disks. Then do a vgcreate and vgextend. Then do a vgexport on one system and vgimport on the other system. Activate the VG on both the systems one by one and do a vgdisplay. If this works okay, you can go ahead and create LV on this Vg. Else you should look for some clash somewhere.

Hope this helps.

Regds

[Sridhar Bhaskarla]

1. The first sixteen digits correspond to the VGID. This should be the same across both the systems. I am not sure about the remaining digits could be the serial of the PVs as mentioned by Duncan.

2. You do not want to do a pvcreate on the disks on both the systems. You would setup a volume group on one system and simply import it on another.

Doing a pvcreate on another system after the volume group was setup on the first node is going to erase the VGID on the disk.

So, you cannot apply the configuration.

-Sri

[Sebastien Masson]

Here it is:

On host A (uname -i: 438563351)
#pvcreate -f /dev/rdsk/c0t9d0
#echo 0x2008?4D|adb /dev/dsk/c0t9d0
2008: 438563351 1006797988 0 0

On host B (uname -i: 431564361)
#pvcreate -f /dev/rdsk/c0t9d0
#vgcreate /dev/vg01 /dev/dsk/c0t9d0
#echo 0x2008?4D|adb /dev/dsk/c0t9d0
2008: 431564361 1006371258 431564361 1006371262

Host A (uname -i: 438563351)
# echo 0x2008?4D|adb /dev/dsk/c0t9d0
2008: 431564361 1006797997 431564361 1006798119

Conclusion:

The last number is the VGID, so someone can tell if adb extract bad information or what ?!! (and it sure, that the same disk).

[Sebastien Masson]

I try to grab the VGID with the dd command:

# dd if=/dev/rdsk/c0t9d0 of=root.disk bs=8k skip=1 count=1
# od -Ax -tx root.disk

At Address 0000010 the first two fields are the root volume group ID

And it the same on both machine. So the problem is maybe the Kernel (adb doesn't display good information between the two machine). But both server are K-Class. K220 and K420. Both use same SCSI card and are connected to a simple Jamaica JBOD. with 2 9GB Seagate LVD

[Sridhar Bhaskarla]

Sebastian,

Try this way.

vgexport vg01 (fresh start)

on host A

#pvcreate -f /dev/rdsk/c0t9d0
#vgcreate vg01 /dev/dsk/c0t9d0 (after mknod group etc)
#echo 0x2008?4D/adb /dev/dsk/c0t9d0
#vgexport -v -p -s -m /tmp/vg01.map vg01
#rcp /tmp/vg01.map hostB:/tmp
This map file will have VGID.

on hostB

#mkdir /dev/vg01;mknod group c 64 0x0?0000
#vgimport -v -s -m /tmp/vg01.map vg01
#echo 0x2008?4D|adb /dev/dsk/c0t9d0

Now in your procedure, YOu will not get correct information initially on hostA as you didn't create the volume group that time. Later on hostB, you updated the VGID by vgcreate. So, it will be the same on hostA in the next step.

adb does extract information correctly.

-Sri

[Sebastien Masson]

No thanks for all your help. It's a problem and after installing the Decembre2001 patch bundle (HP-UX 11.11) everything fine.

It's really a problem in the kernel. adb doesn't repport the good think..