Managing Serviceguard Nineteenth Edition, Reprinted June 2011

• File systems and volume groups are valid (for a modular package, cmcheckconf checks that
volume groups are already configured into the cluster).
• Services are executable.
• Any package that this package depends on is already part of the cluster configuration.
For more information, see the manpage for cmcheckconf (1m) and “Checking Cluster
Components” (page 261).
When cmcheckconf has completed without errors, apply the package configuration, for example:
cmapplyconf -P $SGCONF/pkg1/pkg1.conf
This adds the package configuration information to the binary cluster configuration file in the
$SGCONF directory (normally /etc/cmcluster) and distributes it to all the cluster nodes.
NOTE: For modular packages, you now need to distribute any external scripts identified by the
external_pre_script and external_script parameters.
But if you are accustomed to configuring legacy packages, note that you do not have to create a
separate package control script for a modular package, or distribute it manually. (You do still have
to do this for legacy packages; see “Configuring a Legacy Package” (page 289).)
Adding the Package to the Cluster
You can add the new package to the cluster while the cluster is running, subject to the value of
MAX_CONFIGURED_PACKAGES in the cluster configuration file. See “Adding a Package to a
Running Cluster” (page 299).
How Control Scripts Manage VxVM Disk Groups
VxVM disk groups (other than those managed by CVM) are outside the control of the Serviceguard
cluster. The package control script uses standard VxVM commands to import and deport these disk
groups. (For details on importing and deporting disk groups, refer to the discussion of the import
and deport options in the vxdg man page.)
The control script imports disk groups using the vxdg command with the -tfC options. The -t
option specifies that the disk is imported with the noautoimport flag, which means that the disk
will not be automatically re-imported at boot time. Since disk groups included in the package
control script are only imported by Serviceguard packages, they should not be auto-imported.
The -foption allows the disk group to be imported even if one or more disks (a mirror, for example)
is not currently available. The -C option clears any existing host ID that might be written on the
disk from a prior activation by another node in the cluster. If the disk had been in use on another
node which has gone down with a TOC, then its host ID may still be written on the disk, and this
needs to be cleared so the new node’s ID can be written to the disk. Note that the disk groups are
not imported clearing the host ID if the host ID is set and matches a node that is not in a failed
state. This is to prevent accidental importation of a disk group on multiple nodes which could result
in data corruption.
CAUTION: Although Serviceguard uses the -C option within the package control script framework,
this option should not normally be used from the command line. Chapter 8: “Troubleshooting Your
Cluster” (page 308), shows some situations where you might need to use -C from the command
line.
The following example shows the command with the same options that are used by the control
script:
# vxdg -tfC import dg_01
This command takes over ownership of all the disks in disk group dg_01, even though the disk
currently has a different host ID written on it. The command writes the current node’s host ID on all
246 Configuring Packages and Their Services