Reconfiguring a Package

You reconfigure a a package in much the same way as you originally configured it; for modular packages, see Chapter 6 “Configuring Packages and Their Services”; for older packages, see “Configuring a Legacy Package”.

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.

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 Package Migration from Legacy Style to Modular Style at http://docs.hp.com -> High Availability -> Serviceguard ->White papers.

Do not attempt to convert Serviceguard Toolkit packages.




	NOTE: The cmmigratepkg command requires Perl version 5.8.3 or higher on the system on which you run the command. It should already be on the system as part of the HP-UX base product.

Reconfiguring a Package on a Running Cluster

You can reconfigure a package while the cluster is running, and in some cases you can reconfigure the package while the package itself is running. You can do this in Serviceguard Manager (for legacy packages), or use Serviceguard commands.

To modify the package with Serviceguard commands, use the following procedure (pkg1 is used as an example):

Halt the package if necessary:
cmhaltpkg pkg1
See “Allowable Package States During Reconfiguration ” to determine whether this step is needed.
If it is not already available, you can obtain a copy of the package's configuration file by using the cmgetconf command, specifying the package name.
cmgetconf -p pkg1 pkg1.ascii

Edit the package configuration file.




	IMPORTANT: Restrictions on package names, dependency names, and service names have become more stringent as of A.11.18. Packages that have or contain names that do not conform to the new rules (spelled out under “`package_name`”) will continue to run, but if you reconfigure these packages, you will need to change the names that do not conform; cmcheckconf and cmapplyconf will enforce the new rules.

Verify your changes as follows:
cmcheckconf -v -P pkg1.ascii
Distribute your changes to all nodes:
cmapplyconf -v -P pkg1.ascii
If this is a legacy package, copy the package control script to all nodes that can run the package.

Reconfiguring a Package on a Halted Cluster

You can also make permanent changes in package configuration while the cluster is not running. Use the same steps as in “Reconfiguring a Package on a Running Cluster ”.

Adding a Package to a Running Cluster

You can create a new package and add it to the cluster configuration while the cluster is up and while other packages are running. The number of packages you can add is subject to the value of MAX_CONFIGURED_PACKAGES in the cluster configuration file.

To create the package, follow the steps in the chapter Chapter 6 “Configuring Packages and Their Services”. Use a commands such as the following to verify the configuration of a newly created pkg1 and distribute the configuration to all nodes in the cluster:

cmcheckconf -P /etc/cmcluster/pkg1/pkg1conf.ascii

cmapplyconf -P /etc/cmcluster/pkg1/pkg1conf.ascii

If this is a legacy package, remember to copy the control script to the /etc/cmcluster/pkg1 directory on all nodes that can run the package.

To create the CFS disk group or mount point multi-node packages on systems that support CFS, see “Creating the Disk Group Cluster Packages” and “Creating a File System and Mount Point Package”.

Deleting a Package from a Running Cluster

Serviceguard will not allow you to delete a package if any other package is dependent on it. To check for dependencies, use cmviewcl -v -l <package>. System multi-node packages cannot be deleted from a running cluster.

You can use Serviceguard Manager to delete the package.

On the Serviceguard command line, you can (in most cases) delete a package from all cluster nodes by using the cmdeleteconf command. To delete one of the Veritas Cluster File System packages (on systems that support CFS), use the cfscluster, cfsdgadm, or cfsmntadm command. This removes the package information from the binary configuration file on all the nodes in the cluster. The command can only be executed when the package is down; the cluster can be up.

The following example halts the failover package mypkg and removes the package configuration from the cluster:

cmhaltpkg mypkg
cmdeleteconf -p mypkg

The command prompts for a verification before deleting the files unless you use the -f option. The directory /etc/cmcluster/mypkg is not deleted by this command.

On systems that support CFS, you can remove nodes from a multi-node package configuration using the cfs commands listed in Appendix A. All the packages that depend on the multi-node package must be halted on that node.

To remove the CFS mount point and disk group packages, follow these steps:




	NOTE: Any form of the mount command (for example, mount -o cluster, dbed_chkptmount, or sfrac_chkptmount) other than cfsmount or cfsumount in a HP Serviceguard Storage Management Suite environment with CFS should be done with caution. These non-CFS commands could cause conflicts with subsequent command operations on the file system or Serviceguard packages. Use of these other forms of mount will not create an appropriate multi-node package which means that the cluster packages are not aware of the file system changes.

Remove any dependencies on the package being deleted. Delete dependency_ parameters from the failover application package configuration file, then apply the modified configuration file:
cmapplyconf -v -P app1.config
Unmount the shared file system
cfsumount <mount point>
Remove the mount point package from the cluster
cfsmntadm delete <mount point>
This disassociates the mount point from the cluster. When there is a single VG associated with the mount point, the disk group package will also be removed
Remove the disk group package from the cluster. This disassociates the disk group from the cluster.
cfsdgadm delete <disk group>

Resetting the Service Restart Counter

The service restart counter is the number of times a package service has been automatically restarted. This value is used to determine when the package service has exceeded its maximum number of allowable automatic restarts.

When a package service successfully restarts after several attempts, the package manager does not automatically reset the restart count. However, you may choose to reset the counter online using the cmmodpkg -R -s command, thus enabling the service in future restart situations to have the full number of restart attempts up to the configured service_restart limit. For example:

cmmodpkg -R -s myservice pkg1

The current value of the restart counter may be seen in the output of the cmviewcl -v command.

Allowable Package States During Reconfiguration

In many cases, you can make changes to a package’s configuration while the package is running. The table that follows shows exceptions - cases in which the package must not be running, or in which the results might not be what you expect.

Parameters not listed in the table can be changed while the package is running.

In all cases the cluster can be running, and packages other than the one being reconfigured can be running. (And remember too that you can make changes to package configuration files at any time; but do not apply them (using cmapplyconf or Serviceguard Manager) to a running package in the cases indicated by Table 7-2 “Types of Changes to Packages ”.)




	NOTE: All the nodes in the cluster must be powered up and accessible when you make package configuration changes.

Table 7-2 Types of Changes to Packages

Change to the Package	Required Package State
Add a new package	Other packages can be in any state.
Delete a package	Package must not be running. You cannot delete a package if another package has a dependency on it.
Change package type	Package must not be running.
Add a module (modular package)	Package must not be running.
Delete a module (modular package)	Package must not be running.
Change run script contents (legacy package)	Package should not be running. Timing problems may occur if the script is changed while the package is running.
Change halt script contents (legacy package)	Package should not be running. Timing problems may occur if the script is changed while the package is running.
Add a service	Package must not be running.
Remove or change a service	Package must not be running.
Service timeouts	Package must not be running.
Service failfast	Package must not be running.
Add a subnet	Package must not be running. Subnet must already be configured into the cluster.
Remove a subnet	Package must not be running.
Add an IP address	Package must not be running.
Remove an IP address	Package must not be running.
Add or delete nodes from package’s `ip_subnet_node` list (in cross-subnet configurations; see “`ip_subnet_node` ”)	Package can be running, with these restrictions: The package must not be running on the node that is being added or deleted. The node must not be the first to be added to, or the last deleted from, the list of `ip_subnet_node`s for this `ip_subnet`.
Add a resource	Package must not be running.
Remove a resource	Package must not be running.
Add a volume group	Package should not be running.
Remove a volume group	Package should not be running.
Add a file system	Package must not be running.
Remove a file system	Package must not be running.
Add, change, or delete modular external scripts and pre-scripts	Package must not be running.
Change package `auto_run`	Package can be either running or halted. See “Choosing Switching and Failover Behavior”.
Add or delete a configured dependency	Both packages can be either running or halted with one exception: If a running package adds a package dependency, the package it is to depend on must already be running on the same node(s).
Add CFS packages	To add an `SG-CFS-DG-id#` disk group package, the `SG-CFS-pkg` Cluster File System package must be up and running. To add an `SG-MP-id#` mount point package to a node, the `SG-DG-id#` disk group package must be up and running on that node.
Change location of script log file	Package must not be running.




	NOTE: Check the Serviceguard, SGeRAC, and SMS Compatibility and Feature Matrix and the latest Release Notes for your version of Serviceguard for up-to-date information on CVM and CFS support: http://www.docs.hp.com -> High Availability -> Serviceguard.