HP Serviceguard Using cmeval, Cmeval -v newstate.in, You would see output something like this

NOTE: The preview cannot predict run and halt script failures.

For more information about package dependencies and priorities, see “About Package Dependencies” (page 137).

Using cmeval

You can use cmeval to evaluate the effect of cluster changes on Serviceguard packages. You can also use it simply to preview changes you are considering making to the cluster as a whole.

NOTE: Preview of generic resources is not yet supported with cmeval.

You can use cmeval safely in a production environment; it does not affect the state of the cluster or packages. Unlike command preview mode (the -tdiscussed above) cmeval does not require you to be logged in to the cluster being evaluated, and in fact that cluster does not have to be 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:pkg1autorun=disabled and change it to package:pkg1autorun=enabled. You should also make sure that the nodes the package is configured to run on are shown as available; for example: package:pkg1node:node1available=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:pkg3node:node2action:failing

package:pkg2node:node2action:failing

package:pkg2node:node1action:starting

package:pkg3node:node1action:starting

package:pkg1node:node1action: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 139). 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.

cmeval cannot predict generic resource failures in a package.

This is a simple example; you can use cmeval for much more complex scenarios; see “What You Can Preview” (page 293).

294 Cluster and Package Maintenance