HP Serviceguard Version A.11.20 Release Notes, August 2011

configuration files such as/etc/fstab and /etc/lvmtab will contain references to persistent
device files, but Serviceguard’s functioning will not be affected by this.
CAUTION: You cannot migrate to the agile addressing scheme during a rolling upgrade if you
are using cluster lock disks as a tie-breaker, because that involves changing the cluster configuration.
But you can migrate the cluster lock device file names to the new scheme without bringing the
cluster down. For the requirements and a procedure, see “Updating the Cluster Lock Configuration”
in Chapter 7 of Managing Serviceguard.
NOTE: It is possible, though not a best practice, to use legacy DSFs on some nodes after migrating
to agile addressing on others; this allows you to migrate different nodes at different times, if
necessary.
For more information about agile addressing, see following documents at http://www.hp.com/
go/hpux-core-docs:
• the Logical Volume Management volume of the HP-UX System Administrator’s Guide
• the HP-UX 11i v3 Installation and Update Guide
• the following white papers:
The Next Generation Mass Storage Stack◦
◦ HP-UX 11i v3 Native Multi-Pathing for Mass Storage
◦ LVM Migration from Legacy to Agile Naming Model HP-UX 11i v3
See also the HP-UX 11i v3 intro(7) manpage.
Support for HP Integrity Virtual Machines (HPVM)
Serviceguard supports HP Integrity Virtual Machines (HPVM). HPVM runs only on HP Integrity
systems; it does not run on HP 9000 systems.
IMPORTANT: For the most up-to-date compatibility information, see the
Serviceguard/SGeRAC/SMS/Serviceguard Mgr Plug-in Compatibility and Feature Matrix, at
http://www.hp.com/go/hpux-serviceguard-docs —> HP Serviceguard, under the heading
General reference. See also the “Integrity VM/Serviceguard Support Matrix” in the white
paper Designing high-availability solutions with HP Serviceguard and HP Integrity Virtual Machines
on the same web page under White papers.
Serviceguard A.11.20 supports an HPVM either as a package or as a cluster node. If any
Serviceguard cluster node is a virtual machine, the amount of time Serviceguard needs to wait for
a failed node’s I/O to complete increases; see “About HPVM and Cluster Re-formation Time”
(page 31).
See also “About cmappmgr” (page 29).
About HPVM and Cluster Re-formation Time
When a node fails and the cluster re-forms, Serviceguard must wait a certain amount of time to
allow I/O from the failed node to be written out to the target storage device. Only after that time
has elapsed can Serviceguard allow an adoptive node access to that device; otherwise data
corruption could occur. The amount of time Serviceguard waits is calculated by Serviceguard and
is not user-configurable.
The above is true whether or not the cluster includes virtual machines (VMs), but using VMs as
Serviceguard nodes increases the amount of time Serviceguard needs to wait before it is safe to
allow another node access to the same storage. This additional wait can increase cluster re-formation
time by as much as 70 seconds.
Features Introduced Before A.11.20 31