Managing HP Serviceguard A.11.20.10 for Linux, December 2012

Feb 11 17:18:36 [e-mail] volume_group.sh[1871]: To correct this situation, logon to "xyz.hp.com " and
Feb 11 17:18:36 [e-mail] volume_group.sh[1871]: execute the following commands:
Feb 11 17:18:36 [e-mail] volume_group.sh[1871]: vgchange -a n vg01
Feb 11 17:18:36 [e-mail] volume_group.sh[1871]: vgchange --deltag xyz.hp.com vg01
Feb 11 17:18:36 [e-mail] volume_group.sh[1871]: Once "vg01" has been deactivated from “xyz.hp.com",
Feb 11 17:18:36 [e-mail] volume_group.sh[1871]: this package may be restarted via either cmmodpkg (1M)
Feb 11 17:18:36 [e-mail] volume_group.sh[1871]: or cmrunpkg(1M).
Feb 11 17:18:36 [e-mail] volume_group.sh[1871]: In the event that "xyz.hp.com" is either powered off
Feb 11 17:18:36 [e-mail] volume_group.sh[1871]: or unable to boot, then "vg01" must be forced
Feb 11 17:18:36 [e-mail] volume_group.sh[1871]: to be activated on this node.
Feb 11 17:18:36 [e-mail] volume_group.sh[1871]: ******************* WARNING ***************************
Feb 11 17:18:36 [e-mail] volume_group.sh[1871]: Forcing activation can lead to data corruption if
Feb 11 17:18:36 [e-mail] volume_group.sh[1871]: "xyz.hp.com" is still running and has "vg01"
Feb 11 17:18:36 [e-mail] volume_group.sh[1871]: active. It is imperative to positively determine that
Feb 11 17:18:36 [e-mail] volume_group.sh[1871]: "xyz.hp.com" is not running prior to performing
Feb 11 17:18:36 [e-mail] volume_group.sh[1871]: this operation.
Feb 11 17:18:36 [e-mail] volume_group.sh[1871]: *******************************************************
Feb 11 17:18:36 [e-mail] volume_group.sh[1871]: To force activate "vg01", execute the following
Feb 11 17:18:36 [e-mail] volume_group.sh[1871]: command on the local system:
Feb 11 17:18:36 [e-mail] volume_group.sh[1871]: vgchange --deltag xyz.hp.com vg01
Feb 11 17:18:36 [e-mail] volume_group.sh[1871]: The package may then be restarted via either
Feb 11 17:18:36 [e-mail] volume_group.sh[1871]: cmmodpkg (1M) or cmrunpkg (1M) commands.
8.8.7 Node and Network Failures
These failures cause Serviceguard to transfer control of a package to another node. This is the
normal action of Serviceguard, but you have to be able to recognize when a transfer has taken
place and decide to leave the cluster in its current condition or to restore it to its original condition.
Possible node failures can be caused by the following conditions:
• reboot
• Kernel Oops
• Hangs
• Power failures
You can use the following commands to check the status of your network and subnets:
• ifconfig - to display LAN status and check to see if the package IP is stacked on the LAN
card.
• arp -a - to check the arp tables.
Since your cluster is unique, there are no cookbook solutions to all possible problems. But if you
apply these checks and commands and work your way through the log files, you will be successful
in identifying and solving problems.
8.8.8 Troubleshooting the Quorum Server
NOTE: See the HP Serviceguard Quorum Server Version A.04.00 Release Notes for information
about configuring the Quorum Server. Do not proceed without reading the Release Notes for your
version.
8.8.8.1 Authorization File Problems
The following kind of message in a Serviceguard node’s syslog file or in the output of cmviewcl
-v may indicate an authorization problem:
Access denied to quorum server 192.6.7.4
The reason may be that you have not updated the authorization file. Verify that the node is included
in the file, and try using /usr/lbin/qs -update to re-read the quorum server authorization
file.
8.8.8.2 Timeout Problems
The following kinds of message in a Serviceguard node’s syslog file may indicate timeout
problems:
8.8 Solving Problems 253