07-16-2013 07:09 PM
I am burnt out - I have not clue why my cmquerycl is not sensing a VGLOCK disk and the other two volumes groups that are shared between two nodes that I want to be a part of a cluster. The 3 volume groups that are marked in red are shared volumes. Generally after I set up the LAN and the volume groups - when I run cmquery, I expect the shared volume groups to appear on both my nodes. In other words, these 3 volumes should appear against the secondary node name as well. In this particular case, it senses the volume group on the primary node only. Not on the secondary Node. Where am I going wrong. Not sure if I have to anyway go ahead and create the cluster and then try failing over the package.
Any input would be very much appreciated.
root@hp10s222:# cmquerycl -C /etc/cmcluster/cmclconfig.ascii -n hp10s222 -n hp10s221
Unable to get IPv6 interface information.
Node Names: hp10s221
Bridged networks (local node information only - full probing was not performed):
1 lan0 (hp10s221)
2 lan1 (hp10s221)
3 lan0 (hp10s222)
4 lan1 (hp10s222)
220.127.116.11 lan0 (hp10s222)
18.104.22.168 lan1 (hp10s222)
Possible Heartbeat IPs:
22.214.171.124 126.96.36.199 (hp10s222)
188.8.131.52 184.108.40.206 (hp10s222)
Route Connectivity (local node information only - full probing was not performed):
Possible IP Monitor Subnets:
220.127.116.11 Polling Target 18.104.22.168
Possible Cluster Lock Devices:
NO CLUSTER LOCK: 15 seconds
LVM volume groups:
Solved! Go to Solution.
08-08-2013 06:21 AM - edited 08-08-2013 06:22 AM
/etc/lvmtab (or /etc/lvmtab_p if the VGs are LVM 2.X version) must contain a list of the VGs and PVs they own.
If you did not vgimport the VG(s) on the second node into that node's /etc/lvmtab, Serviceguard cannot detect them.
$ vgexport -pvs -m /etc/lvmconf/vg01.map /dev/vg01 # -s loads only the VGID and customized LVOL names in the file
- repeat for vg02 and vglock
scp /etc/lvmconf/*map root@hp10s221:/etc/lvmconf
$ mkdir /dev/vg01 /dev/vg02 mkdir /dev/vglock
Use mknod to create 'group' special files with a unique minor number. Example:
$ mknod /dev/vg01/group c 64 0x010000
- repeat for vg02 and vglock
RECOMMENDATION: if possible, use the same minor number that hp10s222 uses
$ vgimport -vs -m /etc/lvmconf/vg01.map /dev/vg01 # uses the VGID in the map file to identify the device special file to load into /etc/lvmtab
- repeat for the other 2 VGs
Test cmquerycl again
11-05-2013 10:42 PM
Have you run 'vgscan' command in other adoptive nodes, if not please run the command and check if the output is similar to this
Reading all physical volumes. This may take a while... Found volume group "<vol-group name>" using metadata type lvm2
Also , if you are using virtual machines , check if the shared storage is in 'independent-persistent' mode and shared option is on.
03-05-2014 11:56 AM
Thanks to all those who responded. Sorry I had not turned my "Email me when someone replies" option and I didn't get notified periodically with the updates.
The issue was resolved by adding the "-N" option to the vgimport command. Without the -N option the the vgimport command updates the device file in the legacy /dev/dsk/cXtYdZ format. With the -N option it puts it in the the new /dev/disk/diskXYZ format. That is what was needed to identify the Physical Path of the LUN for cmquercl to recognize as the same disk. The "-N" did the trick.
On the Primary Server
# vgexport -v -p -s -m vg01shared.map /dev/vg01
On the Secondary Server
# vgimport -p -v -s -m vg01shared.map -N /dev/vg01
Appreciate all the help once again.