HP Serviceguard Version A.11.20 Release Notes, August 2011

The additional time Serviceguard needs to wait depends in part on whether or not a VM guest
depot is installed on the VM node. (See HP Integrity Virtual Machines Installation, Configuration,
and Administration, at the address given below, for information on installing a guest depot.)
Serviceguard uses information it derives from the VM guest depot to set the timeout to the optimal
value. If any VM node does not have a VM guest depot, Serviceguard may not be able to obtain
the information it needs to set the optimal timeout, and in that case it sets the additional timeout
to the maximum value, 70 seconds.
IMPORTANT: This additional timeout extension represents a net addition to the time it takes for
the cluster to re-form. For example, if the cluster typically took 40 seconds to re-form before any
VM nodes were added, it will take about 80 seconds when one or more VM nodes are members
of the cluster, if all those nodes have a VM guest depot. If any VM node without a VM guest depot
is a member of the cluster, it will take about 110 seconds. This is true whenever VM nodes are
cluster members, whether or not the re-formation is caused by the failure of a VM node.
For more information about HP Integrity Virtual Machines, see HP Integrity Virtual Machines
Installation, Configuration, and Administration at http://www.hp.com/go/hpux-hpvm-docs.
Access changes as of A.11.16
Serviceguard version A.11.16 introduced a new access method. As of A.11.16, Serviceguard
uses Access Control Policies, also known as Role-Based Access, rather than cmclnodelist or
.rhosts, to authenticate users.
For more information about Access Control Policies, see Chapter 5 of the Managing Serviceguard
manual, the Serviceguard Manager help, and the cluster and package configuration files themselves.
Considerations when Upgrading Serviceguard
• .rhosts
If you relied on .rhosts for access in the previous version of the cluster, you must now
configure Access Control Policies for the cluster users. For instructions on how to proceed, see
the subsection “Allowing Root Access to an Unconfigured Node” under “Configuring Root-Level
Access” in Chapter 5 of the Managing Serviceguard manual.
• cmclnodelist
When you upgrade from an earlier version, Serviceguard converts cmclnodelist entries
into new entries written into the cluster configuration file during the upgrade, as follows:
USER_NAME <user_name>
USER_HOST <host_node>
USER_ROLE Monitor
A wildcard + (plus) is converted as follows:
USER_NAME ANY_USER
USER_HOST ANY_SERVICEGUARD_NODE
USER_ROLE Monitor
After you complete the upgrade, use cmgetconf to create and save a copy of the new
configuration. If you do a cmapplyconf, you want to be sure it applies the newly migrated
Access Control Policies.
Considerations when Installing Serviceguard
When you install Serviceguard for the first time on a node, the node is not yet part of a cluster,
and so there is no Access Control Policy. For instructions on how to proceed, see the subsection
“Allowing Root Access to an Unconfigured Node” under “Configuring Root-Level Access” in Chapter
5 of the Managing Serviceguard manual.
32 Serviceguard Version A.11.20 Release Notes