Cmquery

[wayne_104]

Hi

I have inherited a cluster. I am trying to do a cmquery to rebuild the ascii file.

However i get the below errors.

I have varified that the cmnodelist exists in /etc/cmcluster.

there are entries in ~/.rhosts
the /etc/hosts file is correct.

I have checked the inetd thing telneted on telnet localhost 5302 got response.

there is no logs in /var/adm syslog.

what does cmquery do when Gathering network information?

cmquerycl -v -k -C /etc/cmcluster/cmclconfig.ascii -n alsmp1 -n alsmp2
Looking for other clusters ... Done
Gathering storage information
Found 22 devices on node alsmp1
Found 22 devices on node alsmp2
Analysis of 44 devices should take approximately 5 seconds
0%----10%----20%----30%----40%----50%----60%----70%----80%----90%----100%
Found 7 volume groups on node alsmp1
Found 7 volume groups on node alsmp2
Analysis of 14 volume groups should take approximately 1 seconds
0%----10%----20%----30%----40%----50%----60%----70%----80%----90%----100%
Volume group /dev/vg00 is configured differently on node alsmp1 than on node alsmp2
Volume group /dev/vg00 on node alsmp2 does not appear to have a physical volume corresponding to /dev/disk/disk5_p2 on node alsmp1 (a22383084756d0e1).
Volume group /dev/vg00 is configured differently on node alsmp2 than on node alsmp1
Volume group /dev/vg00 on node alsmp1 does not appear to have a physical volume corresponding to /dev/disk/disk5_p2 on node alsmp2 (fff8f11f4756d4a2).
The volume group /dev/vg00 is activated on more than one node:
alsmp1
alsmp2
Volume groups should not be activated on more than one node.
Use vgchange to de-activate a volume group on a node.
Gathering network information
Beginning network probing
Completed network probing
Failed to gather configuration information.

[Matti_Kurkela]

"Rebuild the ASCII file"? Why can't you simply use the cmgetconf command to get an ASCII version of the current cluster configuration?

MK

[wayne_104]

i was trying to get to an aggregated network but when i modified the current ascii file and did a check came back with errors.

So decided to do a cmquerycl to see if it could give me some idea of what the problem may be. BTW i am at patch level september 2010.

[Benoy Daniel]

why it is trying to compare VG00 in both the nodes..Looks liek you have put vg00 in the package ASCII file. Please get this removed and try again.

[wayne_104]

hi
I am trying to create the ascii file.
cmquerycl -v -k -C /etc/cmcluster/cmclconfig.ascii -n alsmp1 -n alsmp2.

the vg00 drives are local drives on each node.

[Turgay Cavdar]

Hi,
The problem here is "The volume group /dev/vg00 is activated on more than one node". SO you should first correct this error. Possibly on both hosts VGID of vg00 are same.Did you use dd or bcv of vg00 on the later host? If yes then you should go to LVM maintenance mode and run vgchid command.

[wayne_104]

Hi

As i Said inherited this system so not sure what they did.

But those can be discarded as errors as the cluster is up and running and no problems exist surly?

[Turgay Cavdar · Accepted solution]

Hi,
Check on both hosts for VGID:

# vgexport -s -v -p -m vg00.map vg00 1>/dev/null 2>&1 ; grep VGID vg00.map

[wayne_104]

Looks like they the same so they must have done a dd or mirrored disk.


node 1 VGID fff8f11f4756d4a3

node 2 VGID fff8f11f4756d4a3

[Turgay Cavdar]

I think you should go with vgchid...

[Stephen Doud]

The message, "Volume group /dev/vg00 is configured differently on node alsmp1 than on node alsmp2" indicates that vg00 was cloned from alsmp1 to make a bootable vg00 for alsmp2 or vice versa. Serviceguard was not designed to expect a cloned vg00, so the message above results when one of the VGs is changed. The change was noted:
"Volume group /dev/vg00 on node alsmp1 does not appear to have a physical volume corresponding to /dev/disk/disk5_p2 on node alsmp2 (fff8f11f4756d4a2)."

To avoid the messages, reboot one of the nodes in LVM maintenance mode and use 'vgchgid' on all disks in vg00 at the same time.

[wayne_104]

Hi Thanks

What are the risks involved as this is a production system and cluster.

[Stephen Doud]

Changing the VGID during a maintenance mode boot has not been officially tested by the lab, so it is not "supported" - ie, you're on your own. This is because cloning a vg00 is not a "supported" (tested) means of creating a bootable VG.

Risks are that the admin does not include all PVs during the vgchgid command, in which case the VG is hosed and must be rebuilt (reinstall).

[wayne_104]

Hi stephen

So what then would be the command exactly. This is internal disk hardware raid mirror.
here is my lvmtab.

/dev/vg00
/dev/disk/disk5_p2

Cannot do vgdisplay has error as well as pvdisplay.

ioscan -m dsf /dev/disk/disk5
Persistent DSF Legacy DSF(s)
========================================
/dev/disk/disk5 /dev/dsk/c0t0d0


here is the mounted disks.
Volume groups on alsmp1:
/dev/vg00/lvol1 FS MOUNTED /stand
/dev/vg00/lvol2
/dev/vg00/lvol3 FS MOUNTED /
/dev/vg00/lvol4 FS MOUNTED /home
/dev/vg00/lvol5 FS MOUNTED /opt
/dev/vg00/lvol6 FS MOUNTED /tmp
/dev/vg00/lvol7 FS MOUNTED /usr
/dev/vg00/lvol8 FS MOUNTED /var
/dev/vg02/lvol1

[Stephen Doud]

This topic is treated in
document emr_na-c01032230-4 - "Cloned VG00s and ServiceGuard configuration failures"

After booting 'hpux -lm' and before using vgchgid, use vgexport to remove vg00 from /etc/lvmtab.

The vgchgid(1M) man page states:
/usr/sbin/vgchgid PhysicalVolumePath [PhysicalVolumePath] ...

where PhysicalVolumePath = The raw devices path name of a physical volume.

So after booting the kernel in "hpux -lm"
# vgchgid /dev/rdisk/disk5_p2

Then re-create /dev/vg00 and the group file and vgimport vg00, and then use lvlnboot to re-define the root, boot, swap and dump lvols, then reboot.

However, since this is not a supported procedure, please refer to the document for the rest of the details.

[wayne_104]

Thanks

will do that in the new year. not going to tempt fate over this period.