Managing Serviceguard Sixteenth Edition, March 2009

Control-script entries for nodeA and nodeB
IP[0] = 15.244.65.82
SUBNET[0] 15.244.65.0
IP[1] = 15.244.65.83
SUBNET[1] 15.244.65.0
Control-script entries for nodeC and nodeD
IP[0] = 15.244.56.100
SUBNET[0] = 15.244.56.0
IP[1] = 15.244.56.101
SUBNET[1] = 15.244.56.0
Reconfiguring a Package
You reconfigure a package in much the same way as you originally configured it; for
modular packages, see Chapter 6: “Configuring Packages and Their Services ” (page 253);
for older packages, see “Configuring a Legacy Package” (page 338).
The cluster can be either halted or running during package reconfiguration. The types
of changes that can be made and the times when they take effect depend on whether
the package is running or not.
If you reconfigure a package while it is running, it is possible that the package could
fail later, even if the cmapplyconf succeeded. For example, consider a package with
two volume groups. When this package started, it activated both volume groups. While
the package is running, you could change its configuration to list only one of the volume
groups, and cmapplyconf would succeed. If you issue cmhaltpkg command,
however, the halt would fail. The modified package would not deactivate both of the
volume groups that it had activated at startup, because it would only see the one volume
group in its current configuration file.
For more information see “Allowable Package States During Reconfiguration ”
(page 352).
Migrating a Legacy Package to a Modular Package
The Serviceguard command cmmigratepkg automates the process of migrating legacy
packages to modular packages as far as possible. Many, but not all, packages can be
migrated in this way; for details, see the white paper Migrating Packages from Legacy
Style to Modular Style at http://docs.hp.com -> High Availability ->
Serviceguard -> White papers.
Do not attempt to convert Serviceguard Toolkit packages.
Reconfiguring a Package 349