icapmanage(1M)icapmanage(1M)NAMEicapmanage - Global Instant Capacity (GiCAP) management commands for
GiCAP groups.
SYNOPSISicapmanage-i -U <rule_file>
icapmanage-C <codeword>
icapmanage-a -g <group_name>
icapmanage-r -g <group_name>
icapmanage-T <hostlist> [-g <group_name>]
icapmanage-a -m <member_name>:<hostlist> -g <group_name>
icapmanage-r -m <member_name>
icapmanage-s -g <group_name> [-b] [-v]
icapmanage-Q [-n]
icapmanage-R [<hostlist>] [-U <rule_file>]
icapmanage-a -S <host>
icapmanage-r -S <host>
icapmanage-t
icapmanage-u -m <member_name> -h [<hostlist>][!<hostlist>]
icapmanage-x <host>
icapmanage-z <host>
DESCRIPTION
A Global Instant Capacity (GiCAP) group consists of a Group Manager
system and one or more partitionable complexes which are the members.
The primary purpose of a GiCAP group is to enable group members to
share Instant Capacity usage rights (for cores, cell boards, and mem‐
ory) and temporary capacity. A Group Manager has either active or
standby status. An active Group Manager coordinates and monitors
resource sharing, has had hardware grouping rules applied, and has had
GiCAP sharing rights purchased for and applied to it. Optionally, an
active Group Manager can designate as a standby Group Manager any HP-UX
system that runs Instant Capacity software but has not itself had GiCAP
sharing rights applied. The standby Group Manager has the ability to
take control as an active Group Manager if the original active Group
Manager should become unusable for any reason.
Because the members of a group are partitionable complexes and GiCAP
must be able to contact all of the partitions, GiCAP members must be
defined by specifying a <hostlist> to describe the host OS instances of
all the partitions.
The symbol <hostlist> is a string of one or more host names or IP
addresses with the form <host>[,<host>]...
A host can be a vPar or nPar OS instance, but it cannot be a virtual
machine ("guest"). When using HPVM on a prospective GiCAP group mem‐
ber, you must specify the name of the HPVM host OS instance, not the
name of an HPVM guest OS instance.
The command, which is used to create, manage, and remove groups, can be
invoked only on a Group Manager system. On a standby Group Manager,
only the -Q and -s options are allowed, all other options are
restricted to use only on the active Group Manager. The command should
not be invoked on a group member system.
The command can be used to install a grouping rules file, apply a GiCAP
sharing rights codeword, create and remove GiCAP groups, test if a
server can be added to a GiCAP group, update a GiCAP group by adding or
removing members, show grouping rules and supported hardware, seize
core usage rights from member partitions of a GiCAP group to be used by
another member of the group, restore seized core usage rights to the
original member partition, update an existing GiCAP member by adding or
removing hosts, set up and activate a standby Group Manager, transfer
the GiCAP database to the standby Group Manager, and remove a standby
Group Manager.
WBEM version A.02.05 or higher must be installed on the Group Manager,
the standby Group Manager (if any), and on all OS instances of all mem‐
ber systems in order to use Global Instant Capacity. Similarly, the
CIM Server configuration property sslClientVerificationMode must be set
to a value of "optional" on all Group Managers and member OS instances.
(The CIM Server may need to be restarted if the property was not previ‐
ously set to this value.) For details, see cimconfig(1M). Note that
communication between the managers and members of groups is established
using SSL certificates that are supplied by the GiCAP software.
For a complete overview of Global Instant Capacity, see icap(5), and
for more detailed information see the located at /usr/share/doc/ica‐
pUserGuide.pdf.
Options
recognizes these options and arguments:
-a Add a GiCAP group, add a member to a group, or desig‐
nate a system as a standby Group Manager.
To create a new group, use the -a option, along with
the -g option to name the new group.
To add a member to a GiCAP group, use the -a option,
along with the -m option to specify a member name and
list of hostnames, and the -g option to specify the
group name. The list of hostnames must contain a rep‐
resentative host for each nPartition or virtual parti‐
tion of the complex, and each host must be up and the
Group Manager must be able to contact it. (To avoid
potential problems, the Group Manger should also be
able to contact any standby manager that is defined.)
To add multiple members to a GiCAP group, you must run
multiple times; you cannot specify multiple members in
a single command.
To add a standby Group Manager, use the -a option,
along with the -S option to identify the host system
that is to serve as the standby Group Manager.
-b Provide brief status information only. Show summary
group information without information specific to the
Group Manager and the members.
-g <group_name>
Specify a GiCAP group name for a GiCAP operation.
-h Used with the -u option to identify hosts to be added
to or removed from an existing GiCAP group member's
list. A hostlist identifies hosts to be added. A
hostlist preceded by an exclamation point (!) identi‐
fies hosts to be removed. There must be no interven‐
ing blanks within a hostlist, and if both add and
remove lists are specified, the entire string must be
contiguous.
-i Install a grouping rules file on a Group Manager sys‐
tem.
-m <member_name>:<host>[,<host>]...
Add a member (a partitionable complex) to a group,
with name member_name. Specify an OS instance (host)
for each nPartition or virtual partition of the com‐
plex (do not specify virtual machine or guest OS
instances).
A member of a group must encompass all nPar and vPar
OS instances of a complex, and each OS instance speci‐
fied as a host must be accessible (ping-able) in order
for the command to succeed. When you first add a mem‐
ber to a group, you are prompted for the root password
for each specified host. The password is used for
initial communication only and is not saved or stored.
If you are using the HP Virtual Server Environment
(VSE), it may be helpful to define the member_name to
be the same as the VSE complex name (which includes
the serial number).
A member complex can be added to a group if it is not
in an exception state, if there are enough GiCAP shar‐
ing rights available to match the number of cores
without usage rights on that complex, and if the com‐
plex's hardware is compatible with the grouping rules
and with the other members of the group.
-m <member_name>
Specify the member name when removing a member from a
GiCAP group.
-n Prevents from attempting to exchange SSL keys with
member hosts which the new active Group Manager cannot
contact. This option allows to be issued from a
script without the script having to deal with the pos‐
sibility of root password prompts. If -n is specified
and there are member hosts which the new active group
manager cannot contact, the active manager will not be
able to use those hosts for GiCAP operations. If a
GiCAP group member has no hosts which the active man‐
ager can contact, that member will not be able to par‐
ticipate in the GiCAP group.
-r Remove a member from a group, remove a GiCAP group, or
remove a system from use as a standby Group Manager.
When used with the -m option to specify the member
name, removes that member from a GiCAP group. In
order to do the remove, at least one host defined for
the member must be up and the Group Manager must be
able to contact it. (To avoid potential problems, the
Group Manager should also be able to contact any
standby manager that is defined.) Note that a member
cannot be removed from a group until any borrowed
usage rights are returned to the group and any loaned
usage rights are returned to the member. Removal of a
member from a group releases sharing rights and makes
them available for future use.
When used in combination with the -g option, removes
the specified GiCAP group. All members must be
removed before the group can be removed.
When used in combination with the -S option, removes
the identified host system from use as a standby Group
Manager.
-s Request status about one or more GiCAP groups. Speci‐
fication without any additional options displays group
and member information for all GiCAP groups managed by
this Group Manager. Use the -g <group_name> option to
limit the information to the named group only. Use -b
to display group-level information only. Use -v to
include additional manager-specific information and
more detailed group and member information, especially
partition-specific information for members. For more
information about fields that are displayed see "Sta‐
tus Information" .
-t Transfer a copy of the GiCAP database from the active
Group Manager to a standby Group Manager. The active
Group Manager transfers the GiCAP database to the
standby Group Manager whenever the active Group Man‐
ager makes changes to the database. In addition, the
Instant Capacity software uses this command as part of
an automatically generated job (see cron(1M)) to
ensure that this copy takes place if something should
prevent normal replication of the GiCAP database to
the standby Group Manager. While you should not need
to issue this command, you may wish to do so occasion‐
ally, especially if there are intermittent problems
with network communications between the active Group
Manager and the standby Group Manager. You may also
wish to issue this command before having the standby
Group Manager take over (via the command on the active
Group Manager) for planned downtime on the active
Group Manager. The transfer operation works only on
the active Group Manager system.
-u Update the list of hosts (OS instances) associated
with an existing GiCAP group member. This command is
typically used when the vPar or nPar configuration of
a member complex changes. The -m option identifies
the member to be updated. The -h option identifies
the hosts to be added or removed.
Note: You are prompted for the root password for each
host to be added. The password is used for initial
communication only and is not saved or stored.
For a given command execution, host removals are pro‐
cessed before host additions. As a result, the same
host can be removed and readded with one update opera‐
tion. With removes or adds applied, the resulting
list must contain a representative host for each nPar‐
tition or virtual partition of the associated server.
When adding hosts, each host must be up and the Group
Manager must be able to contact it. (To avoid poten‐
tial problems, the Group Manager should also be able
to contact any standby manager that is defined.)
-v Provide verbose status information. Include all lev‐
els of information (group, manager and member). For
Group Managers, include resources being held by the
Group Manager including temporary capacity. For mem‐
bers, include borrow and loan information as well as
partition-specific information such as the allocation
of resources among the hard partitions, and partition-
specific information about seized or seizable usage
rights (see ). This option is ignored if the -b
option is also specified.
This verbose option also attempts to contact every
host of each group member to check that two-way commu‐
nication can be established between the issuing group
manager (either active or standby) and each such host.
The command without -v attempts to contact multiple
hosts on a group member only if that is necessary to
find a host that responds. In either case, reports
which hosts it failed to contact. Use of the -v
option can be useful as a general health check of
group communication.
-x <host> Acquire core usage rights from the nPartition contain‐
ing the specified host to make them available to other
group members, also known as rights seizure. Rights
seizure takes almost all the available usage rights
from the hard partition containing the specified host.
The specified host must be known to the GiCAP manager
(it appears in the output of ) and not currently run‐
ning. If other hosts are associated with the same
hard partition, they cannot be currently running. The
operation can be performed once for each hard parti‐
tion on the member. For confirmation, the command
verifies each known host on the hard partition. The
hard partition containing the specified host is left
with one core usage right per active cell. Any core
usage rights in excess of this amount becomes avail‐
able for use elsewhere in the GiCAP group. For exam‐
ple, if a partition of 2 cells is currently consuming
6 core usage rights, makes 4 core usage rights (6 - 2)
available for reassignment.
While rights can be seized from any hard partition
that is unavailable, the Instant Capacity software
makes some additional restrictions when all partitions
of a complex are unavailable. As a result, there are
different behaviors and constraints depending on
whether or not a partition can be contacted on the
specified member complex.
If, at the time of rights seizure, at least one member
partition can be contacted, then the software is able
to make an immediate adjustment to the available core
usage rights, just as if an operation had been per‐
formed before the specified hard partition stopped
running. This makes core usage rights available for
potential loans to other member systems. In this sit‐
uation, the seized core usage rights do not have an
expiration date. However, if the cells are not made
inactive and the system is not rebooted within 12 to
24 hours of this rights seizure, the Instant Capacity
software in still-running partitions takes note that
the iCAP daemon has not been running in the failed
partition for a significant period of time, and there‐
fore assumes that the partition might be booted to an
operating system that is unaware of iCAP and is using
all cores on the partition. This is referred to as
the "assumed active" state and can result in temporary
capacity charges or compliance exceptions. To avoid
this, cells can be made inactive by removing them from
the partition, shutting down the partition from within
the OS by using , or with the MP command. However,
even if the cells are made inactive, the Instant
Capacity software reserves usage rights to minimize
the possibility that the complex will be taken out of
compliance if the partition is booted with all cores
active. This will not affect temporary capacity but
may affect the ability to do activations on other par‐
titions of the complex, or may affect the ability to
do resource migrations within the GiCAP group (if
any). This "assumed reserved" state can be avoided by
rebooting or deleting the failed partition or by
authorizing temporary capacity on activations. For
more details, refer to the section on .
If, at the time of rights seizure, all member parti‐
tions are unreachable, the rights seizure is deferred
and must be viewed as a limited and immediate loan of
usage rights from the specified partition to the
group. This loan of seized usage rights expires in 10
days. Upon expiration, usage rights are automatically
restored to the member partitions from which they were
seized. The expiration date for a rights seizure
operation effectively terminates the period during
which the core usage rights are available to other
group members for purposes of disaster recovery. If
none of the member partitions are reachable by the
expiration date for a particular member, the usage
rights are automatically restored (reassigned) to the
member partition (or complex, in the case of unas‐
signed seized rights) from which they were seized.
However, if the seized usage rights have been rede‐
ployed to other members and are not released at expi‐
ration time, the group might go out of compliance, or
temporary capacity might be used to maintain compli‐
ance.
If any partition of the inaccessible member from which
rights seizures were deferred reconnects to the group
before the expiration date, then the seized core usage
rights (for all partitions) are finalized as a loan
from the member to the group, the expiration date is
no longer relevant, and the usage rights can there‐
after be manipulated with normal operations.
While rights seizure operations can be performed in a
virtual partition environment, the rights seizure
always operates on, and affects, the entire nParti‐
tion. This means:
· Rights seizure can be performed only if all the
virtual partitions for an nPartition are down.
· For a given nPartition, you can specify any of the
virtual partition host names as the target of a
rights seizure operation or as the target of a
usage rights restore operation.
· Because rights seizure leaves only a minimum of
core usage rights with the nPartition, is it likely
that the remaining number of core usage rights is
not sufficient to satisfy the number of cores
assigned to each virtual partition in the nParti‐
tion. This means that the virtual partitions
likely cannot be booted (due to noncompliance) once
the original failure is corrected. To avoid this
problem, usage rights must be restored (using the
option) before failback.
-z <host> Restore previously seized core usage rights to the
nPartition containing the specified host. Core usage
rights must be available in the GiCAP group or the
command fails.
This option can be useful particularly when core usage
rights have been seized from systems running vPars,
because the restoration of core usage rights may be
necessary in order to be able to reboot the vPar,
depending on the vPars database definition and the
allocation of usage rights among the vPars. If this
is a potential problem, the restoration command must
be performed before rebooting any vPar within an nPar
from which rights were seized.
-C <codeword>
GiCAP codeword application. This option allows the
user to apply a GiCAP codeword to a Group Manager sys‐
tem. (This option cannot be used to apply an iCAP
codeword such as an RTU or TiCAP codeword.) For GiCAP
sharing rights codewords, first purchase the GiCAP
codeword from HP. The number of rights purchased must
equal or exceed the number of cores without usage
rights for all planned members for all groups managed
by the Group Manager. Next, retrieve the codeword
from the HP Utility Pricing Solutions portal and apply
it to the Group Manager system. Unlike iCAP code‐
words, GiCAP codewords are generated for a specified
partition on a Group Manager system, and can only be
applied to that partition. Like iCAP codewords, GiCAP
codewords are also generated in a sequence and must be
applied in the order they are generated for the Group
Manager partition. However, GiCAP codewords are
sequenced independently from any iCAP codewords for
the same complex, and can be applied independently
from any such iCAP codewords. Application of the
GiCAP codeword allows members to be added to one or
more GiCAP groups.
-Q Make a standby GiCAP Group Manager the active Group
Manager for all group members. The new active Group
Manager attempts to contact all group members, inform‐
ing them that this system is the active Group Manager.
The new Group Manager also attempts to contact the
previous Group Manager to make it the standby Group
Manager. If the new Group Manager cannot contact a
group member, that group member will continue to be
managed by its current manager. This may result in
the member not being able to loan or borrow usage
rights or it may result in a split group. (For
details, see icap(5) in the section titled "Group Man‐
ager Failover Considerations".) The current system
becomes the active Group Manager regardless of whether
these attempted contacts succeed or fail.
When attempting to contact all group members, the new
active Group Manager may find that it must establish
SSL communication with a member host. If so, it will
prompt for that host's root password so that it can
exchange SSL keys with the host (unless the -n option
is also specified). HP recommends that SSL communica‐
tion between the standby Group Manager and all member
hosts has been previously established before the use
of the command. Normally this occurs automatically
when adding a new member to a group, updating the host
list for an existing member, or adding a standby Group
Manager.
This command can be issued on an active Group Manager.
In this case, the active Group Manager continues as
the active Group Manager. It attempts to contact all
group members and the previously active Group Manager
and informs them that this system is the active Group
Manager. This is useful if a prior command failed to
contact some group members or the previously active
Group Manager.
Note that if the active Group Manager manages multiple
groups, all members of all such groups must be con‐
tacted during this operation.
-R [<host>[,<host>]...]
Report hardware grouping information. When used with
a list of host names, report all hardware types with
which the hosts might be grouped. The hosts can be
specified using either the IP address or the name of
the host. If the hosts are not compatible with each
other, no hardware is reported. Without a list of
host names, report all supported hardware and grouping
rules. Specification of the -U option reports hard‐
ware associated with the specified rule file instead
of the installed rule file, and can be used to evalu‐
ate a new grouping rules file before installing it
with the -i option.
-S When used in combination with the -a option, identi‐
fies a host system to be set up as a standby Group
Manager. This command will prompt for the root pass‐
word of the host so that the active Group Manager can
exchange SSL keys with the designated standby host,
establishing the ability to communicate with it. The
active Group Manager proceeds to update all member
hosts of all managed groups with information about the
standby Group Manager, establish secure communications
between the member hosts and the standby Group Man‐
ager, and set up a job responsible for the periodic
transfer of the GiCAP database to the standby Group
Manager. Note that a transfer also occurs whenever
the database is updated on the active Group Manager
until such time as the standby Group Manager takes
control or is removed from use as a standby Group Man‐
ager.
When used in combination with the -r option, identi‐
fies a host system which is to be removed from use as
a standby Group Manager. The active Group Manager
updates all member hosts of all managed groups about
the removal, discontinues the GiCAP database transfer
operations (removes the job created when the standby
Group Manager was set up), and directs the identified
host system to remove its copy of the GiCAP database.
A standby Group Manager can be added anytime after the
active Group Manager has grouping rules installed on
it (before or after the application of sharing rights
to the active Group Manager, before or after groups
are created). A Group Manager in standby status can
be removed at any time.
-T <host>[,<host>]...
Test hardware compatibility for one or more host sys‐
tems in order to determine which groups the systems
can join. When used with the -g option to specify a
group name, tests whether the specified host systems
have hardware compatible with the group. Without the
-g option, report which of all the groups managed by
this Group Manager have hardware compatible with the
host systems. A host can be specified using either
the IP address or the name of the host. The host
names do not have to be from the same complex, but to
best predict the possibility of joining a group, the
list of hosts should include all the nPartitions for a
particular complex. If the hosts are not compatible,
no groups are reported as having compatible hardware.
-U <rule_file>
Specify the filename of a rule file.
Status Information
This section describes the fields that might be displayed when is used
to show status. The exact choice of options used in combination with
the -s option determines how much of the information is displayed.
First, the display shows the software version number of the Global
Instant Capacity software and the current date and time. This is fol‐
lowed by the identification information for the Group Manager: serial
number, nPar ID (if any), and vPar code (if any). This identification
information is necessary when requesting a sharing rights codeword from
the portal. Next, the Group Manager status (active or standby) is dis‐
played. On an active Group Manager, this is followed by the name of
the dedicated standby Group Manager (if any). On a standby Group Man‐
ager, this is followed by the name of the associated active Group Man‐
ager. Next, the display shows the number of sharing rights that have
been purchased and applied to this Group Manager, and how many sharing
rights are currently in use versus the number still available to accom‐
modate addition of new members or new groups with new members. The
output of the command uses symbols next to the value of some fields in
certain circumstances. These symbols are as follows:
* Indicates an estimated number of active cores, memory
or cells, because full information is not available
(for example, when a host is not reachable, or on some
platforms when cells are powered off).
# Indicates that all cores in the partition, rather than
any specific number, have been requested to be active.
The number indicates the current number of cores in
the partition.
These values can be displayed for each group managed by the Group Man‐
ager.
Group <group_name>:
This field displays the name of the GiCAP group.
Group Members:
This summarizes the name of each member in the group,
and also shows the host names comprising each member
complex.
Instant Capacity Resource Summary for the group
This section shows values which are summed across all
group members.
Number of cells without usage rights:
This field displays the total number of
cells across all group members which must
remain inactive because usage rights have
not been purchased.
Number of inactive cells:
This field displays the actual number of
inactive cells across the group. It does
not include counts for inactive cells asso‐
ciated with inaccessible members (no parti‐
tions could be contacted).
Amount of memory without usage rights:
This field displays the total amount of mem‐
ory which must remain inactive across all
group members because usage rights have not
been purchased.
Amount of inactive memory:
This field displays the actual amount of
inactive memory across the group. It does
not include counts for inactive memory asso‐
ciated with inaccessible members (no parti‐
tions could be contacted).
Number of cores without usage rights:
This field displays the total number of
cores which must remain inactive across all
group members because usage rights have not
been purchased.
Number of inactive cores:
This field displays the actual number of
inactive cores across the group. It does
not include counts for inactive cores asso‐
ciated with inaccessible members (no parti‐
tions could be contacted).
Number of cores using temporary capacity:
This field displays the number of cores
using temporary capacity within the group.
It does not include values for unreachable
members (no partitions could be contacted).
Temporary capacity available:
This field displays the amount of pooled
group temporary capacity that is available
to any member of the group.
Projected temporary capacity expiration:
This field displays the date and time that
temporary capacity is projected to expire
for the group at the present consumption
rate.
Temporary capacity balance:
This field displays the total amount of tem‐
porary capacity assigned to the group. This
value is different from "Temporary capacity
available" , and is displayed only when mem‐
bers with temporary capacity cannot be con‐
tacted by the group manager (their temporary
capacity is not available to the group but
is part of the group total).
Unassigned cell usage rights:
This field displays the number of cells that
can be activated immediately in the group
because of usage rights that are not in use.
This field is displayed only when the -v
option is specified.
Unassigned memory usage rights:
This field displays the amount of memory
that can be activated immediately in the
group because of usage rights that are not
in use. This field is displayed only when
the -v option is specified.
Unassigned core usage rights:
This field displays the number of cores that
can be activated immediately in the group
because of usage rights that are not in use.
This field is displayed only when the -v
option is specified.
Seized core usage rights:
This summary field displays the number of
expiring core usage rights that were seized
from inaccessible members (see ). This
field is displayed for all status options
(-s, -b, -v), but only when usage rights
were seized from member systems where none
of the partitions could be contacted.
Expiration of seized core usage rights:
This summary field displays the earliest
expiration date for core usage rights that
were seized from members where none of the
partitions could be contacted (see ). The
expiration date for a rights seizure opera‐
tion effectively terminates the period dur‐
ing which the core usage rights are avail‐
able to other group members for disaster
recovery.
This field is displayed for all status
options (-s, -b, -v), but only when usage
rights were seized from member systems where
none of the partitions could be contacted.
Information Displayed for the Group Manager
This section describes resources that are temporarily
held by the Group Manager. The resources are avail‐
able to all members of the group and include cell,
memory, and core usage rights, and temporary capacity.
Manager-held resources usually represent a transient
state, for example when usage rights have been
released (or seized using ) from one member of a group
but have not yet been activated on another target mem‐
ber system. These values are displayed only when the
-v option (verbose) is specified.
Information displayed for each member of the group
This section is repeated for each member of the group
if the -b option is not specified. With a few excep‐
tions, the information in this section consists of a
subset of the information provided by the command on
the member systems. In all cases, a Resource Summary
minimally includes the values for cells, memory, and
cores without usage rights for the member system, and
the balance of temporary capacity assigned to the mem‐
ber complex. If any partition of the complex can be
contacted, the resource summary also contains counts
of inactive cells, memory and cores, the count of
cores using temporary capacity, and the projected date
of temporary capacity expiration. If the -v option is
specified and any partition of the member can be con‐
tacted, the member resource summary includes counts of
borrowed cell, memory, and core usage rights, and par‐
tition-specific information is included in the "Allo‐
cation of Instant Capacity Resources among the parti‐
tions" section.
If core usage rights have been seized from the member,
the count of cores without usage rights is adjusted by
the number of seized usage rights, to reflect the
overall balance of cores without usage rights that
must be maintained in the group.
If none of the partitions of the member can be con‐
tacted, then the Resource Summary contains limited
information, using the last-known values for the mem‐
ber. Only the fields listed for unreachable members
have values that are included in the group totals.
For example, the group total for inactive cores does
not include counts for unreachable members, but the
group total for number of cores without usage rights
includes last-known values for unreachable members.
Additionally, information about rights seizure can be
displayed for members where none of the partitions can
be contacted:
Seized core usage rights:
This summary field displays the total number
of expiring core usage rights that were
seized from all partitions of this member
(using operations when none of the parti‐
tions could be contacted). This member sum‐
mary field is not displayed when the -v
option is specified (because the -v option
includes a detailed list instead).
Expiration of seized core usage rights:
This summary field displays the earliest
expiration date for core usage rights that
were seized from all partitions of this mem‐
ber (using operations). The expiration date
for a rights seizure operation effectively
terminates the period during which the core
usage rights are available to other group
members for disaster recovery.
This member summary field is not displayed
when the -v option is specified. However,
if multiple rights seizure operations
occurred for this member, there might be
multiple expiration dates. To see a more
detailed list of partition-specific rights
seizure counts and expiration dates, use the
-v option.
Unassigned core usage rights seized:
This field displays the number of unused
core usage rights (not previously assigned
to any partition) that were seized from this
member. This field is displayed only when
the -v option is specified.
You can use to restore core usage rights
that were previously seized from partitions.
It does not restore previously seized core
usage rights if those rights were not
assigned to a partition at the time of
seizure. In other respects however, these
unassigned seized usage rights are similar
to usage rights seized from partitions: if
the member reconnects to the group manager
before the expiration date, the seized usage
rights are completed as a loan to the group.
If the expiration date occurs before recon‐
nection, the seized usage rights revert to
the member system from which they were
seized.
Core usage rights seized from npar <n>:
This field displays the number of expiring
core usage rights that were seized from a
specific partition of the member. This
field is displayed only when the -v option
is specified, and it is repeated for each
partition where usage rights were seized for
disaster recovery, if none of the member
partitions could be contacted.
Expiration:
This field displays the expiration date for
core usage rights that were seized with
operations from the preceding named parti‐
tion, or from the complex in the case of
unassigned usage rights. The expiration
date for a rights seizure operation effec‐
tively terminates the period during which
the core usage rights are available to other
group members for purposes of disaster
recovery.
This field is displayed only when the -v
option is specified and only for systems
where usage rights were seized for disaster
recovery, if none of the member partitions
could be contacted.
In general, the Instant Capacity software is designed to enforce the
concept that a certain number of resources must remain inactive in
order to stay in compliance with the iCAP contract. For that reason,
many of the display fields for and also for are negative counts of
usage rights, such as Cores without usage rights and Cells without
usage rights.
At the same time, the GiCAP software is intended to allow the transfer
of usage rights among members of the group. So, seizure of usage
rights, borrows and loans of usage rights are described as positive
counts of usage rights, such as Number of core usage rights seized and
Borrowed core rights. The Group Manager also sometimes holds usage
rights during transient states, so all the Group Manager resources are
described as positive counts of core usage rights.
To properly interpret the display of usage rights, it is sometimes nec‐
essary to total the usage rights using both positive and negative (sub‐
tractive) values. For example, if the group contains two members, each
having 3 cores without usage rights, then the total for the group is 6
cores without usage rights. If a rights are seized from one member,
for example taking 2 core usage rights away, then those 2 core usage
rights are held by the Group Manager before the 4 are used by another
member of the group. During that transitional period, the total for
the group remains 6 cores without usage rights, but the member total
for the unreachable member is adjusted to be 5 cores without usage
rights (2 were taken away from the unreachable member) and 3 cores
without usage rights (for the other member). At the same time, the
Group Manager holds 2 usage rights. The total for cores without usage
rights is calculated as 6=5+3-2.
In this example, "counts of cores without usage rights" are also
adjusted as a result of rights seizure operations in order to maintain
the contractually required balance of cores without usage rights. Sim‐
ilar adjustments are made every time a resource (cores, cells, memory)
is borrowed from or loaned to other members of the group. These
adjustments are automatically reflected in the output on the member
systems; in the case of unreachable members and rights seizure, you
might see the adjustment first in the display from the output.
EXTERNAL INFLUENCES
Environment Variables
· LANG determines the locale to use for the locale categories
when both LC_ALL and the corresponding environment variable
(beginning with LC_) do not specify a locale. If LANG is not
set or is set to the empty string, a default of "C" is used
(see lang(5)).
· LC_CTYPE determines the interpretation of single- and multi‐
ple-byte characters.
· LC_MESSAGES determines the language in which messages are
displayed.
If any internationalization variable contains an invalid set‐
ting, icapmanage behaves as if all internationalization vari‐
ables are set to C (see environ(5)).
International Code Set Support
Single- and multiple-byte character code sets are supported.
RETURN VALUE
exits with one of these values:
0 Command succeeded.
>0 Command failed; error message sent to STDERR.
FILES
/var/adm/GiCAP.log
Log file for GiCAP operations and messages.
/etc/opt/iCAP/GiCAP.rules
Encrypted file containing grouping rules used by the
Group Manager.
/etc/opt/iCAP/GiCAP_db
Encrypted file containing information about sharing
rights and information about each group managed by the
Group Manager.
/etc/opt/iCAP/GiCAP.configFile
Present on every host of a GiCAP group member. It
contains information needed by the iCAP software to
contact the Group Manager for the host.
/etc/opt/iCAP/GiCAP_keygen
Script used to establish (or reestablish) SSL certifi‐
cates.
/etc/opt/iCAP/GiCAPcert.pem
/etc/opt/iCAP/*.pem
/etc/opt/iCAP/GiCAPpkey.pem
SSL certificate files.
/etc/opt/iCAP/GiCAP.checkScavengedMember.xml
Script used by the Group Manager to periodically check
for members reconnecting to the group after a seizure
operation.
EXAMPLES
Install a new grouping rules file:
icapmanage-i -U /tmp/GiCAP.rules
Purchase a sharing rights codeword from HP with rights equal to or
greater than the number of cores without usage rights for all planned
members of the group. Retrieve the codeword from the portal, and apply
the sharing rights codeword to the Group Manager system.
icapmanage-C R8J2DBW.5UTxyWQ.2MekJ43.G5cdTVP.1-m9kvweQ.AYqEXym.wj3dyLj.Fbtg7s1
Create a GiCAP group named ADMIN1:
icapmanage-a -g ADMIN1
Test whether a server complex has hardware that is compatible with the
group:
icapmanage-T mypar1.node.hp.com,mypar2.node.hp.com -g ADMIN1
Add a member called IT to the ADMIN1 group. Supply the root password
for each of these partitions in response to the prompts:
icapmanage-a -m IT:mypar1.node.hp.com,mypar2.node.hp.com -g ADMIN1
root@mypar1.node.hp.com's password:
root@mypar2.node.hp.com's password:
Designate host mystandby for use as a standby Group Manager:
icapmanage-a -S mystandby.node.hp.com
Remove host mystandby from use as a standby Group Manager:
icapmanage-r -S mystandby.node.hp.com
Take control as an active Group Manager:
icapmanage-Q
Show the full status of the ADMIN1 group:
icapmanage-s -g ADMIN1 -v
Seize core usage rights from a partition that is unavailable to make
them available to other group member activations:
icapmanage-x mypar1.node.hp.com
Restore previously seized usage rights to the partition from the previ‐
ous example:
icapmanage-z mypar1.node.hp.com
Report supported hardware and grouping rules for a specific grouping
rules file:
icapmanage-R -U /tmp/GiCAP.rules
Add host mypar3 to existing member IT:
icapmanage-u -m IT -h mypar3.node.hp.com
Add host mypar4 to existing member IT, and remove host mypar3:
icapmanage-u -m IT -h mypar4.node.hp.com!mypar3.node.hp.com
Remove group member IT from its group:
icapmanage-r -m IT
Remove the ADMIN1 group:
icapmanage-r -g ADMIN1
AUTHOR
was developed by HP.
SEE ALSOicapmodify(1M), icapnotify(1M), icapstatus(1M), icapd(1M), icap(5),
cimconfig(1M), cron(1M).
icapmanage(1M)
