cmquerycl does not sense the Volumes that are Shared.

[Kennedy G. Doss]

ServiceGuard Gurus:

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
               hp10s222

Bridged networks (local node information only - full probing was not performed):

1       lan0           (hp10s221)

2       lan1           (hp10s221)

3       lan0           (hp10s222)

4       lan1           (hp10s222)

IP subnets:

IPv4:

157.206.120.0      lan0      (hp10s222)
                   lan0      (hp10s221)

157.206.122.0      lan1      (hp10s222)
                   lan1      (hp10s221)

IPv6:

Possible Heartbeat IPs:

IPv4:

157.206.120.0                     157.206.121.97      (hp10s222)
                                  157.206.121.96      (hp10s221)

157.206.122.0                     157.206.122.98      (hp10s222)
                                  157.206.122.99      (hp10s221)

IPv6:

Route Connectivity (local node information only - full probing was not performed):

IPv4:

1   157.206.120.0

2   157.206.122.0

Possible IP Monitor Subnets:

IPv4:

157.206.120.0      Polling Target 157.206.120.1

IPv6:

Possible Cluster Lock Devices:

NO CLUSTER LOCK:                        15 seconds

LVM volume groups:

/dev/vg00               hp10s222

/dev/vglocal            hp10s222

/dev/vg99               hp10s222

/dev/vg02               hp10s222

/dev/vg01               hp10s222

/dev/vglock             hp10s222

/dev/vg00               hp10s221

/dev/vglocal            hp10s221
root@hp10s222:#

[taylor06]

i think you did not import the  shared vg's to the secondary node on the shared pv's............

[Stephen Doud]

/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.

Method:
on hp10s222:

 $ 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

On hp10s221:

$ 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

[bingoarunprasat]

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.

[Kennedy G. Doss · Accepted solution]

HP-UX Admins:

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.

Warm Regards,

-Kennedy Doss