icapmanage(1M) icapmanage(1M)
NAME
icapmanage - Global Instant Capacity (GiCAP) management commands for GiCAP groups.
SYNOPSIS
icapmanage -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 memory)
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 Man-
ager, 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
member 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 previously 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 designate 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 host-
names, and the -g option to specify the group name. The list of hostnames must contain a representative host for each
nPartition or virtual partition 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 (!) identifies hosts to be removed.
There must be no intervening 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 system.
-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 nParti-
tion or virtual partition of the complex (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 specified as a host
must be accessible (ping-able) in order for the command to succeed. When you first add a member 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 sharing rights
available to match the number of cores without usage rights on that complex, and if the complex'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 possibility 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 manager can
contact, that member will not be able to participate 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. Specification 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 "Status 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 Manager 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 occasionally, 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 processed before host additions. As a result, the same host can be
removed and readded with one update operation. With removes or adds applied, the resulting list must contain a represen-
tative host for each nPartition 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 potential problems,
the Group Manager should also be able to contact any standby manager that is defined.)
-v Provide verbose status information. Include all levels of information (group, manager and member). For Group Managers,
include resources being held by the Group Manager including temporary capacity. For members, 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 communication 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 containing 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 contain-
ing the specified host. The specified host must be known to the GiCAP manager (it appears in the output of ) and not cur-
rently running. If other hosts are associated with the same hard partition, they cannot be currently running. The opera-
tion can be performed once for each hard partition 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 available 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 addi-
tional restrictions when all partitions of a complex are unavailable. As a result, there are different behaviors and con-
straints 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 performed before the specified
hard partition stopped running. This makes core usage rights available for potential loans to other member systems. In
this situation, 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-run-
ning partitions takes note that the iCAP daemon has not been running in the failed partition for a significant period of
time, and therefore 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 com-
pliance 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 partitions 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 partitions 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 par-
titions are reachable by the expiration date for a particular member, the usage rights are automatically restored (reas-
signed) to the member partition (or complex, in the case of unassigned seized rights) from which they were seized. How-
ever, if the seized usage rights have been redeployed to other members and are not released at expiration time, the group
might go out of compliance, or temporary capacity might be used to maintain compliance.
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 thereafter be manipulated with normal opera-
tions.
While rights seizure operations can be performed in a virtual partition environment, the rights seizure always operates
on, and affects, the entire nPartition. This means:
o Rights seizure can be performed only if all the virtual partitions for an nPartition are down.
o For a given nPartition, you can specify any of the virtual partition host names as the target of a rights seizure oper-
ation or as the target of a usage rights restore operation.
o 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
nPartition. 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 system. (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 with-
out 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 codewords, 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 com-
plex, 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, informing 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 con-
tact 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 Manager 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 communica-
tion 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 communication 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 contacted 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 hardware associated with the specified rule file instead of the
installed rule file, and can be used to evaluate a new grouping rules file before installing it with the -i option.
-S When used in combination with the -a option, identifies a host system to be set up as a standby Group Manager. This com-
mand will prompt for the root password of the host so that the active Group Manager can exchange SSL keys with the desig-
nated standby host, establishing the ability to communicate with it. The active Group Manager proceeds to update all mem-
ber hosts of all managed groups with information about the standby Group Manager, establish secure communications between
the member hosts and the standby Group Manager, and set up a job responsible for the periodic transfer of the GiCAP data-
base 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 Manager.
When used in combination with the -r option, identifies 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 systems 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 identifica-
tion information is necessary when requesting a sharing rights codeword from the portal. Next, the Group Manager status (active or
standby) is displayed. On an active Group Manager, this is followed by the name of the dedicated standby Group Manager (if any). On a
standby Group Manager, this is followed by the name of the associated active Group Manager. 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 accommodate 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 Manager.
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 inac-
tive cells associated with inaccessible members (no partitions could be contacted).
Amount of memory without usage rights:
This field displays the total amount of memory 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 inac-
tive memory associated with inaccessible members (no partitions 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 inac-
tive cores associated with inaccessible members (no partitions 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 temporary capacity assigned to the group. This value is different from
"Temporary capacity available" , and is displayed only when members with temporary capacity cannot be contacted
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 operation
effectively terminates the period during which the core usage rights are available 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 available to all mem-
bers 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 member 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 exceptions, 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 member complex. If any partition of the complex can be con-
tacted, 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 contacted, the member resource summary includes counts of borrowed cell, memory, and core usage rights, and
partition-specific information is included in the "Allocation of Instant Capacity Resources among the partitions" 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 contacted, then the Resource Summary contains limited information, using
the last-known values for the member. 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 partitions could be contacted). This member summary 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 parti-
tions of this member (using operations). The expiration date for a rights seizure operation effectively termi-
nates 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 pre-
viously 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 reconnection, 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 preced-
ing named partition, or from the complex in the case of unassigned usage rights. 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.
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 necessary to total the usage rights using both positive and negative
(subtractive) 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. Similar 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
o LANG determines the locale to use for the locale categories when both LC_ALL and the corresponding environment variable (begin-
ning 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)).
o LC_CTYPE determines the interpretation of single- and multiple-byte characters.
o LC_MESSAGES determines the language in which messages are displayed.
If any internationalization variable contains an invalid setting, icapmanage behaves as if all internationalization variables 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 certificates.
/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 previous 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 ALSO
icapmodify(1M), icapnotify(1M), icapstatus(1M), icapd(1M), icap(5), cimconfig(1M), cron(1M).
icapmanage(1M)