Managing Serviceguard A.11.20, March 2013

Running a Package
For a failover package, when a volume group with an iSCSI disk is added as a part of a package
startup, the disk underlying the volume is registered and reserved by the node where the package
is running. When the package is halted, all the registration and reservation keys are cleared.
In multi-node packages, when a package with a volume group is applied, reservation is made to
the disk by one of the nodes where the package is up and running. All other nodes where the
package instance is running register to the disk. All nodes will have access to the disk, because
the reservation type used is WERO. When the package is halted, the keys are revoked only on
the nodes on which the package is halted. If the node on which the package is halted holds the
reservation, then the reservation is transferred to another node where the package is up and
running.
If a disk mentioned in the package contains any registrations (made outside the Serviceguard
environment), then the package fails to start. You must clear all registrations from the disk. The
following message is displayed:
ERROR: Physical Volume <PV_name> used in the VG has registration which
is not from any of the cluster nodes.
NOTE: If the package does not halt gracefully, you must manually clear the keys using the
pr_cleanup(1m) command. For more information, see the pr_cleanup(1m) and the
vg_pr_key(1m) man pages. To verify whether any keys exist on the disk, use the vg_pr_key
command with the -g option. See the example in “Distributing Persistent Reservation Keys on
Extended Volume Groups” (page 92).
You can use cmviewcl -f line to see whether PR is enabled for a given package; for example,
cmviewcl -v -f line pkg1
...
PKG_PR_MODE="pr_enabled"
Distributing Persistent Reservation Keys on Extended Volume Groups
An LVM volume group configured using iSCSI storage in a package can have persistent reservations
and registrations on its physical volumes. When you extend the LVM volume group to add another
disk (using vgextend(1m)), the persistent reservation and registration keys (if any) must be copied
to the new physical volumes. Serviceguard provides the /usr/sbin/vg_pr_key command to
do this. For more information, see the vg_pr_key(1m) man page. For the usage of vgextend,
see “Creating Volume Groups” (page 183).
After extending the volume group if you plan to run the cmapplyconf command for the package,
then you need not run vg_pr_key. cmapplyconf will copy the keys to the new physical volumes.
It is recommended to use vg_pr_key only when cmapplyconf is not run for the package after
vgextend is run.
The following example illustrates how you can use the vg_pr_key command to copy the
registrations/reservations to extended volume groups.
Example
The following command displays all the registered keys, the reserved key, and the node from which
the reservation was made for all physical volumes in the volume group /dev/iscsi_vg3:
vg_pr_key -g -v /dev/iscsi_vg3
Volume Group: /dev/iscsi_vg3
-Physical Volume: /dev/rdsk/c11t0d0
REGISTERED KEYS : 0xbcb00001,0xbcb00002
RESERVED KEYS : 0xbcb00002
RESERVED FROM NODE : jack4
-Physical Volume: /dev/rdsk/c12t0d0
REGISTERED KEYS : NONE
92 Understanding Serviceguard Software Components