Troubleshooting Serviceguard with Integrity VM

This section describes how to solve some of the problems that can occur using Serviceguard and Integrity VM.

Serviceguard in Host Troubleshooting

If the distributed guest does not start or failover, check both the /var/adm/syslog/syslog.log file and the package log file (/etc/cmcluster/guest—name/guest—name.sh.log).

If a package fails to start, ServiceGuard performs a package halt. The log files include a Halting package section after the Starting package section where, the actual starting failure messages are found. Look at the Halting package section as well as the Starting package section when you view package log files after a package start failure.

If the distributed guest does not fail over, take the package down using the cmhaltpkg command. Make sure the guest has the resources it needs to run on the adoptive node by manuall starting the package on the adoptive node with the same workload using the cmrunpkg command.

If the package does not start under manual control, stop the cluster and test the guest named compass1.

Use the hpvmmodify command to set the guest to be not distributed. For example:
# hpvmmodify -P compass1 -i NONE # hpvmmodify -P compass1 -j 0
Use the hpvmstart command to start the guest with the same VM Host system and workload. Use the virtual console (hpvmconsole) to make sure the the guest OS is installed and applications are running properly.

After testing the guest, create the Serviceguard package again.

If the guest does not start and displays errors about storage problems, and you are using logical volumes, the storage units might not be available to the VM Host. To make the storage units available , enter the appropriate commands, as follows:

For LVM logical volumes, enter the following commands:

# vgchange -c n /dev/vgxx
# vgchange -a y /dev/vgxx

For VxVM logical volumes, enter the following commands:

# vxdg import diskgroup-name
# vxvol -g diskgroup-name startall

If you are using files on a logical volume, also enter the following command:
# mount /dev/vgxx /mount-point

After making sure the backing storage devices are available, restore them to their original state.

Some problems that arise from improper storage configuration include:

Whole disks - Verify that the VM Host has access to the disks. This may be traced to a hardware or storage subsystem issue.
LVM - Before starting a package, ServiceGuard requires that all volume groups associated with the package are inactive. See the Managing Serviceguard manual for details on deactivating LVMs.
VxVm - Before starting a package, ServiceGuard requires that all disk groups associated with the package are deported. See the Managing ServiceGuard manual for details.
Files - Before starting a package, ServiceGuard requires that filesystems of file backing stores associated with the package are unmounted.

If the guest has problems accessing network, make sure the network devices are available on the VM Host system. Packages do not start if any of their defined subnets are unavailable. This causes multiple failures if no standby LANs are available, or when one or more switches, hubs, interfaces or cables fail.

A common issue when starting a package is the lack of available memory. See “Creating Virtual Machines” for more information about providing the required memory resources.

Creating Distributed Guests

This manual describes how to use the hpvmsg_package.sh script to help you configure guests as Serviceguard packages. If you create the Serviceguard package configuration and control scripts manually instead, use the following options to the hpvmcreate, hpvmmodify, or hpvmclone command to identify the Serviceguard package name and to mark the guest as a distributed guest.

Use the —i option to specify the Serviceguard package. (For example, —i SG_package_name.)
Use the —j 1 option to specify that the guest is a distributed guest.

For more information, read the hpvmsg_package.sh file.

Networking

If the guest has network problems after failover:

Make sure the vswitches are properly configured on the adoptive node. If you are using the VLAN feature of Integrity VM vswitches, make sure that appropriate VLAN IDs are assigned to each port.
Adjust the values of the following Serviceguard parameters in the cluster configuration file. The correct settings for the HEARTBEAT_INTERVAL and the NODE_TIMEOUT parameters are system- and load-dependent. Specifically:
- The HEARTBEAT_INTERVAL parameter specifies the normal interval between the transmission of heartbeat messages from one node to the other in the cluster. The value of the HEARTBEAT_INTERVAL parameter is entered in microseconds; the default value is 1,000,000 microseconds. Setting the value of this parameter to less than the default is not recommended. The default should be used where possible. The maximum value recommended is 15 seconds, and the maximum value supported is 30 seconds. This value should be at least half the value of the NODE_TIMEOUT parameter.
- The NODE_TIMEOUT parameter specifies the amount of time after which the Serviceguard node may decide that the other node has become unavailable and initiate cluster reformation. This parameter is entered in microseconds; the default value is 2,000,000 microseconds. The minimum is two times the value of the HEARTBEAT_INTERVAL parameter. The maximum recommended value for this parameter is 30,000,000.. The default setting yields the fastest cluster reformations. However, using the default value increases the potential for spurious reformations due to momentary system hangs or network load spikes. For many installations, a setting of 5,000,000 to 8,000,000 (5 to 8 seconds) is more appropriate. The maximum value recommended is 30 seconds and the maximum value supported is 60 seconds.

Troubleshooting Serviceguard with Integrity VM

Technical documentation

» Table of Contents

» Glossary

» Index

Serviceguard in Host Troubleshooting

Creating Distributed Guests

Networking