Managing HP Serviceguard A.11.20.00 for Linux, June 2012

Both parameters are optional, but if weight_value is specified, weight_name must also be
specified, and must come first. You can define up to four weights, corresponding to four different
capacities, per cluster. To specify more than one weight for this package, repeat weight_name
and weight_value.
NOTE: But if weight_name is package_limit, you can use only that one weight and capacity
throughout the cluster. package_limit is a reserved value, which, if used, must be entered
exactly in that form. It provides the simplest way of managing weights and capacities; see “Simple
Method” (page 108) for more information.
The rules for forming weight_name are the same as those for forming package_name (page 159).
weight_name must exactly match the corresponding CAPACITY_NAME.
weight_value is an unsigned floating-point value between 0 and 1000000 with at most three
digits after the decimal point.
You can use these parameters to override the cluster-wide default package weight that corresponds
to a given node capacity. You can define that cluster-wide default package weight by means of
the WEIGHT_NAME and WEIGHT_DEFAULT parameters in the cluster configuration file (explicit
default). If you do not define an explicit default (that is, if you define a CAPACITY_NAME in the
cluster configuration file with no corresponding WEIGHT_NAME and WEIGHT_DEFAULT), the
default weight is assumed to be zero (implicit default). Configuring weight_name and
weight_value here in the package configuration file overrides the cluster-wide default (implicit
or explicit), and assigns a particular weight to this package.
For more information, see “About Package Weights” (page 107). See also the discussion of the
relevant parameters under “Cluster Configuration Parameters ” (page 80), in the cmmakepkg
(1m) and cmquerycl (1m) manpages, and in the cluster configuration and package
configuration template files.
monitored_subnet
The LAN subnet that is to be monitored for this package. Replaces legacy SUBNET which is still
supported in the package configuration file for legacy packages; see “Configuring a Legacy
Package” (page 210).
You can specify multiple subnets; use a separate line for each.
If you specify a subnet as a monitored_subnet the package will not run on any node not
reachable via that subnet. This normally means that if the subnet is not up, the package will not
run. (For cross-subnet configurations, in which a subnet may be configured on some nodes and
not on others, see monitored_subnet_access below, ip_subnet_node (page 166), and
“About Cross-Subnet Failover” (page 117).)
Typically you would monitor the ip_subnet, specifying it here as well as in the ip_subnet
parameter (page 165), but you may want to monitor other subnets as well; you can specify any
subnet that is configured into the cluster (via the STATIONARY_IP parameter in the cluster
configuration file). See “Stationary and Relocatable IP Addresses and Monitored Subnets” (page 54)
for more information.
If any monitored_subnet fails, Serviceguard will switch the package to any other node specified
by node_name (page 159) which can communicate on all the monitored_subnets defined for
this package. See the comments in the configuration file for more information and examples.
monitored_subnet_access
In cross-subnet configurations, specifies whether each monitored_subnet is accessible on all
nodes in the package’s node_name list (page 159), or only some. Valid values are PARTIAL,
meaning that at least one of the nodes has access to the subnet, but not all; and FULL, meaning
that all nodes have access to the subnet. The default is FULL, and it is in effect if
monitored_subnet_access is not specified.
164 Configuring Packages and Their Services