Managing Serviceguard A.11.20, March 2013

When you run cmapplyconf (1m) to configure a new cluster, or add a new node, Serviceguard
sets the variable cluster_pr_mode to either pr_enabled or pr_disabled.
pr_enabled means that packages can in principle use PR, but in practice will do so only if
they fulfill the conditions described in the “Rules and Limitationssection.
pr_disabled means that no packages can use PR.
You can view the setting of cluster_pr_mode in the output of cmviewcl -f line; for example,
...
cluster_pr_mode=pr_enabled
node:beat1|node_pr_key=2fcb0001
node:beat2|node_pr_key=2fcb0002
package:pkg|module_name:sg/pr_cntl|module_name=sg/pr_cntl
package:pkg|module_name:sg/pr_cntl|module_version=1
package:pkg|module_name:sg/pr_cntl|module_scripts=$SGCONF/scripts/sg/pr_cntl.sh
package:pkg|operation_sequence:$SGCONF/scripts/sg/pr_cntl.sh|operation_sequence=$SGCONF/scripts/sg/pr_cntl.sh
package:pkg|pkg_pr_mode=pr_disabled
package:vg_pkg|module_name:sg/pr_cntl|module_name=sg/pr_cntl
package:vg_pkg|module_name:sg/pr_cntl|module_version=1
package:vg_pkg|module_name:sg/pr_cntl|module_scripts=$SGCONF/scripts/sg/pr_cntl.sh
package:vg_pkg|operation_sequence:$SGCONF/scripts/sg/pr_cntl.sh|operation_sequence=$SGCONF/scripts/sg/pr_cntl.sh
package:vg_pkg|pkg_pr_mode=pr_enabled
Applying a Package
If a package is qualified to use PR, Serviceguard first checks for any previous reservations on the
LUN.
If reservations are made by a node within the current cluster, then during package start they
are cleared and new reservations are made on the disk.
If reservations are made by a system outside of the current cluster environment, then
cmapplyconf returns an error message prompting the user to first clear the reservations held
by the LUN. To clear the reservations, do one of the following:
Use the pr_cleanup script provided by Serviceguard. For more information, see the
pr_cleanup(1m) man page and “Revoking Persistent Reservations after a Failure
(page 333).
WARNING! pr_cleanup clears all existing keys on the disk. If any application
(including Serviceguard) are using these keys, they will no longer function properly as
the keys will be cleared. Use this command with caution and ensure that only the keys
that are not required are cleared.
You can use the vg_pr_key command to check the keys that are existing on the disk.
See the vg_pr_key(1m) man page and “Distributing Persistent Reservation Keys on
Extended Volume Groups” (page 92).
In a Serviceguard environment, if by mistake you clear all keys on a running Serviceguard
package using pr_cleanup, you must halt the package where the volume group is
configured to avoid issues that may occur. The keys are restored once you restart the
package.
Use the sg_persist utility. This utility is included in the March 2012 OE Update Release
or later. It is also supported on HP-UX 11i v3 September 2011 (available via web). For
information on sg3_utils, see SCSI Persistent Reservation Utilities Release Notes at
http://www.hp.com/go/hpux-core-docs-11iv3.
If a disk is reserved by a node not present in the current cluster, the following message is displayed:
<PV_name> is already reserved by a node which is not in this cluster.
Please clear the existing reservation using pr_cleanup script.
iSCSI Storage and Persistent Reservations 91