Managing Serviceguard Nineteenth Edition, Reprinted June 2011

running, though it must use the same Serviceguard release and patch version as the system on
which you run cmeval.
Use cmeval rather than command preview mode when you want to see more than the effect of
a single command, and especially when you want to see the results of large-scale changes, or
changes that may interact in complex ways, such as changes to package priorities, node order,
dependencies and so on.
Using cmeval involves three major steps:
1. Use cmviewcl -v -f line to write the current cluster configuration out to a file.
2. Edit the file to include the events or changes you want to preview
3. Using the file from Step 2 as input, run cmeval to preview the results of the changes.
For example, assume that pkg1 is a high-priority package whose primary node is node1, and
which depends on pkg2 and pkg3 to be running on the same node. These lower-priority-packages
are currently running on node2. pkg1 is down and disabled, and you want to see the effect of
enabling it.
In the output of cmviewcl -v -f line, you would find the line
package:pkg1|autorun=disabled and change it to package:pkg1|autorun=enabled.
You should also make sure that the nodes the package is configured to run on are shown as
available; for example: package:pkg1|node:node1|available=yes. Then save the file (for
example as newstate.in) and run cmeval:
cmeval -v newstate.in
You would see output something like this:
package:pkg3|node:node2|action:failing
package:pkg2|node:node2|action:failing
package:pkg2|node:node1|action:starting
package:pkg3|node:node1|action:starting
package:pkg1|node:node1|action:starting
This shows that pkg1, when enabled, will “drag” pkg2 and pkg3 to its primary node, node1. It
can do this because of its higher priority; see “Dragging Rules for Simple Dependencies” (page 130).
Running cmeval confirms that all three packages will successfully start on node2 (assuming
conditions do not change between now and when you actually enable pkg1, and there are no
failures in the run scripts.)
NOTE: cmeval cannot predict run and halt script failures.
This is a simple example; you can use cmeval for much more complex scenarios; see “What You
Can Preview” (page 279).
IMPORTANT: For detailed information and examples, see the cmeval (1m) manpage.
Updating the Cluster Lock Configuration
Use the procedures that follow whenever you need to change the device file names of the cluster
lock physical volumes. You may need to do this because you are changing the device itself (the
disk or LUN), or for some other reason — for example, in order to migrate cluster nodes to the
agile addressing scheme available as of HP-UX 11i v3 (see “About Device File Names (Device
Special Files)” (page 77)), or to migrate cluster DSFs to cDSFs; see “About Cluster-wide Device
Special Files (cDSFs)” (page 99).
Updating the Cluster Lock Disk Configuration Online
You can change the device file names (DSFs) of the cluster lock physical volumes (that is, the values
of the FIRST_CLUSTER_LOCK_PV and SECOND_CLUSTER_LOCK_PV parameters in the cluster
configuration file) without bringing down the cluster. Proceed as follows.
Reconfiguring a Cluster 281