iCAP(5)iCAP(5)NAME
iCAP - Instant Capacity software for HP-UX
DESCRIPTION
The HP Instant Capacity program provides services for instantly
increasing or decreasing processing capacity on supported HP servers to
meet varying system demands. An Instant Capacity server is an HP cel‐
lular (partitionable) server that is governed by an Instant Capacity
contract constraining the number of cores, cell boards, and memory that
must remain inactive at all times. The total number of each type of
component that can be active at any time is referred to as the number
of usage rights for that component type. The Instant Capacity software
provides the ability to dynamically assign usage rights where they are
needed among the various partitions of a complex through the use of
commands like icapmodify(1M)and parmodify(1M), and it provides the
means to load balance system processing capacity through these manage‐
ment commands. When the processing demand significantly changes, you
can purchase additional component usage rights to increase the overall
number of components that can be activated at any time.
Instant Capacity is a part of the HP Utility Pricing Solutions (UPS)
program, and was formerly known as iCOD. For detailed information
about Instant Capacity, see the located at /usr/share/doc/icapUser‐
Guide.pdf.
Initializing an Instant Capacity Server
Instant Capacity software is installed by HP manufacturing on instantly
ignited systems, and is a required component of all HP-UX systems. You
can upgrade to later versions by downloading it from
http://www.hp.com/go/softwaredepot (search for product ID B9073BA), or
by installing it from an OE or AE update.
An Instant Capacity server needs no additional initialization, but some
of the following configuration steps might be useful:
1. Execute the command to configure contact information
(email address) for configuration change notification
and exception reports.
2. If using temporary capacity, execute the command to
configure the temporary capacity warning period.
3. If the server is a GiCAP Group Manager or a member of
a GiCAP group, use the command (see cimconfig(1M)) to
set the CIM Server configuration property
sslClientVerificationMode to "optional" . You might
need to restart the CIM Server (see cimserver(1M)) if
the property was not previously set to this value.
Codewords
Instant Capacity uses codewords for several purposes: to adjust avail‐
able usage rights for system components, to apply an amount of "tempo‐
rary capacity" to the system, and to apply "sharing rights" to a Global
Instant Capacity (GiCAP) Group Manager to enable creation of one or
more groups of member servers that can share usage rights.
All types of codewords must be purchased as specific product numbers
from HP. After purchase, the codeword (an encrypted string) must be
retrieved from the Utility Pricing Solutions web portal and applied to
the appropriate system. Codewords are generated specifically for the
system for which they were purchased. You must always specify at least
the system serial number and the purchase order number in order to
retrieve a codeword from the portal. Application and use of GiCAP
codewords are different from other iCAP codewords and are described in
the section "GiCAP Sharing Rights" .
Prior to activating an Instant Capacity component, a Right to Use (RTU)
codeword must be applied to the complex to increase the component-spe‐
cific usage rights on the complex. After a fee has been paid to HP for
the type and number of components that are to be activated, RTU code‐
words are made available through the HP Utility Pricing Solutions por‐
tal (http://www.hp.com/go/icap/portal).
Instant Capacity codewords (such as RTU codewords) are applied to a
complex using the command on any partition of the complex. iCAP code‐
words are generated with a sequence number, and all iCAP codewords for
a particular complex must be applied in the order in which they were
generated.
After the appropriate codewords have been applied to a complex, addi‐
tional components in the complex may be activated, up to the number of
component usage rights granted by the applied codewords. Depending on
their type, components are activated using the command (if activating
cores), or other commands including (see parmodify(1M)) and (see par‐
mgr(1M)).
In addition to RTU codewords, cores can be activated with temporary
capacity. Temporary capacity codewords allow the activation of more
cores than allowed by the usage rights on the complex, but only for a
limited time.
Software Removal
Instant Capacity software cannot be removed. Other software products
depend on it to approve configuration changes to the system.
Status of Instant Capacity Components
Information about the Instant Capacity components on a complex and the
available usage rights for each type of component can be obtained by
invoking the command. This command also provides information about the
amount of temporary capacity presently in use, the projected expiration
of the temporary capacity, and counts of active and inactive compo‐
nents.
One status field that is important to understand is the intended active
(IA) value for each nPartition. Fundamentally, the intended active
value is the number of cores intended to be active after a reboot. As
processing needs change, the IA value is modified by commands like , ,
and to represent the new distribution of active cores across the nPar‐
titions and thus, the new numbers to activate on reboot of the nParti‐
tions.
Note that the status field intended active can differ from the status
field actual active (AA) in some cases, including the following:
· In an nPartition, activations or deactivations can be
deferred, meaning that the change is pending until the next
reboot.
· If there are deconfigured (failed) cores, it may be impossi‐
ble for the nPartition to reach the configured IA value. The
IA value is not affected by deconfigured cores, but the AA
value may be lower in this case.
· In a virtual partition, core assignments can be increased or
decreased with either the command or the command, but only
changes the intended active for the nPartition. activation
commands are constrained by the intended active value, but
deactivation commands are allowed to deactivate below IA, so
that the number of cores actually assigned to all the virtual
partititons of the nPartition (represented by the AA status
field) may be less than the IA value for the nPartition.
This results in something called "unused capacity" ; but typ‐
ically happens only during the window of time that resources
are being shifted across the virtual partitions of an nParti‐
tion. Overall, this mechanism allows for quicker shifting of
resources within virtual partitions.
If the complex is a member of a GiCAP group, the command provides
information about group membership, including any borrow or loan status
of usage rights. Detailed information about GiCAP groups can be
obtained by invoking the command on a Group Manager system.
Virtual Partitions
Instant Capacity has a minimum version dependency on vPars A.03.05.
For versions of vPars before A.03.05, the command for activating or
deactivating cores in a virtual partition fails with an error message
indicating the vPars version dependency.
Instant Capacity can be present on systems or partitions where virtual
partition technology is employed. In a virtual partition environment,
cores that are not assigned to any virtual partition are considered
inactive (in addition to other classes of inactive cores). Unassigned
cores can be assigned (activated) or deassigned (deactivated) using
either the command or the command, depending on the type of adjustment
needed, the version of vPars being used, and the level of logging or
reporting desired.
One important consideration is that can be used to activate or deacti‐
vate cores in other virtual partitions within the nPartition; only
activates or deactivates cores within the current virtual partition
(the partition where the command is invoked). Another consideration is
that core assignment via the command does not result in logging of the
activation, email configuration change notification, or transmission of
an asset report to HP.
However, the most important consideration is that the command must be
used in a virtual partition environment when you are making any adjust‐
ment to an nPartition. If you are adjusting core assignments across
virtual partitions in a single nPartition, use the command for the best
coordination between the Instant Capacity software and the vPars soft‐
ware, and for optimized performance. The command is the fastest and
most efficient way to adjust capacity within virtual partitions of a
single hard partition, but it does not affect the intended active count
for the nPartition. Therefore, it cannot be used to migrate unused
capacity either to or from other nPartitions.
Note that with vPars A.03.05 or greater, a compliance check is per‐
formed whenever a virtual partition is booted. If the total number of
cores assigned to all virtual partitions in the current vPar database
exceeds the nPartition's intended active core count, the Instant Capac‐
ity software notifies the vPar monitor, and the monitor prevents any
virtual partition from booting until the user performs a hard partition
boot and modifies either the vPar configuration or the Instant Capacity
intended activecount for the nPartition.
For more information about virtual partitions, see vparmodify(1M).
HP Integrity Virtual Machines (Integrity VM)
In an Integrity VM environment, Instant Capacity software provides
meaningful functionality only on the VM Host; it does not run on a vir‐
tual machine (also known as a "guest"). In particular, Instant Capac‐
ity commands will report an error if attempted from a guest. A GiCAP
Group Manager cannot be run on a guest, nor can a guest be specified in
the host list for a GiCAP group member.
Processor Sets
In an environment where processor sets are being used, the command
activates Instant Capacity cores into the default processor set and
deactivates cores from only the default processor set. Activation or
deactivation of cores in nondefault processor sets is a two-step opera‐
tion. The first step involves the user migrating the cores into or out
of the default processor set; the second step is the activation or
deactivation of those cores using the command.
For more information about processor sets, see psrset(1M).
Temporary Capacity (TiCAP) Program
Customers can purchase an amount of temporary capacity time. This tem‐
porary capacity can be used to activate one or more cores beyond the
number for which usage rights have been purchased. These extra cores
can remain active until they consume the available temporary capacity
time. This allows temporary activation of cores without requiring the
purchase and activation of an RTU codeword for permanent activation.
Whenever an Instant Capacity component without usage rights is pur‐
chased, an amount of Instant Access Capacity (IAC) might also be
included. Instant Access Capacity is exactly the same as temporary
capacity, except it is automatically provided with an Instant Capacity
component and is not separately purchased. It provides an immediate
buffer of temporary capacity in case extra capacity is needed before
there is time to purchase either an RTU codeword, a temporary capacity
codeword, or to setup a Global Instant Capacity (GiCAP) group.
Temporary capacity can be added to the complex by applying a temporary
capacity codeword (available from the HP Utility Pricing Solutions por‐
tal) using the command. Information about the amount of temporary
capacity time remaining on a complex can be obtained by executing the
command. A warning is also sent via email when the temporary capacity
balance is expected to be depleted within a certain period of time.
The command allows activating a core using temporary capacity only if
at least 30 minutes of temporary capacity is available for each core
being activated.
Whenever temporary capacity has been applied to a system (or if the
complex is part of a GiCAP group), extra care must be taken to avoid
situations that cause the Instant Capacity software on one nPartition
of a group member to make assumptions that all cores might be active on
another nPartition of the member, for example, when the nPartition is
making boot-related configuration changes (at EFI or BCH). If left in
this state for more than 12 hours, unexpected temporary capacity may be
consumed on the complex.
INSTANT CAPACITY CELL BOARD
Instant Capacity Cell Board offers a way to have additional (inactive)
cell board capacity for your system. These Instant Capacity cell
boards, which contain memory and cores, can be activated after a cell
RTU codeword is obtained from the HP Utility Pricing Solutions portal
and is applied to the complex using the command. To activate a cell,
you must have usage rights for all memory attached to the cell and at
least one core.
GLOBAL INSTANT CAPACITY
Global Instant Capacity (GiCAP) provides HP customers with the flexi‐
bility to move usage rights for Instant Capacity components within a
group of servers. It also provides "pooled" temporary capacity across
the group. This has several potential benefits: cost-effective high
availability, more adaptable load balancing, and more efficient and
easier use of temporary capacity.
For example, in case of planned or unplanned down time, a customer can
transfer usage rights from a failed partition on one server to one or
more other servers in the group that are providing backup availability,
thus allowing additional activations of iCAP components on the backup
servers. Without GiCAP, the only way to provide this failover scenario
is to provision each server with an adequate amount of temporary capac‐
ity.
A similar scenario exists for load balancing. Rather than using tempo‐
rary capacity whenever a server is overloaded (peak profiles for all
workloads on a server), usage rights can be transferred from other
servers in the GiCAP group that have extra capacity. These borrowed
usage rights enable new component activations on the overloaded system.
Pooled temporary capacity for a group of servers is more efficient
because all temporary capacity is available to all servers in the GiCAP
group. It is also easier to manage if temporary capacity needs to be
applied to only one member of the group and monitored across the group
instead of monitoring TiCAP for each member complex.
GICAP GROUPS
Global Instant Capacity is built on the concept of a server group, or
GiCAP group. The group consists of a list of server complexes that are
allowed to share Instant Capacity usage rights (for cores, cell boards,
and memory) and temporary capacity. There are no constraints on the
number of servers allowed in a group, but grouping rules defined by HP
specify the types of servers allowed to group together.
GICAP GROUP MANAGER
For each group, an HP-UX system must be designated as an active Global
Instant Capacity Group Manager. It is this system that maintains
information about the group, group resources, and grouping rules. The
commands are intended to be used only on a Group Manager system to man‐
age one or more GiCAP groups.
The active Group Manager must be an HP-UX system running the Instant
Capacity software version 9.0 or later. The system running the Group
Manager does not need to have any Instant Capacity components, nor does
it need to be a partitionable system. The system must have a machine-
readable serial number, as displayed by the shell command . It is rec‐
ommended that the Group Manager not be on a partition that is a member
of any GiCAP group, and that it manages a single group. If run on a
partitionable system, changing the configuration of the partitions may
result in the GiCAP Manager becoming inoperative.
STANDBY GICAP GROUP MANAGER
The active GiCAP Group Manager can designate a standby Group Manager.
This standby Group Manager can take control of GiCAP group management
from the active Group Manager using the command . This allows GiCAP
group operations to continue if the GiCAP Group Manager is unable to
function.
Note that the requirements and recommendations defined for the Group
Manager also apply to the standby Group Manager; it is a Group Manager
with "standby" status. The Group Manager in charge of the group has
"active" status. If the standby Group Manager takes control, the
intention is that its status becomes "active" and the former Group Man‐
ager's status becomes "standby". For more details, see the "Group Man‐
ager Failover Considerations" section.
GICAP GROUP MEMBERS
Every operating system on a GiCAP group member must be running Instant
Capacity version 9.0 or later. Every GiCAP group member must be hard‐
ware-compatible with other GiCAP group members as determined by the
GiCAP grouping rules.
GICAP GROUPING RULES
Once you have determined which system will host the active Group Man‐
ager, you must acquire grouping rules from the portal and install the
encrypted file on the active Group Manager system using the command.
Under some circumstances (for example, when adding new hardware not
covered by the grouping rules currently in use), you might need to
acquire newer grouping rules from the portal.
GICAP SHARING RIGHTS
To create a GiCAP group with members, you must purchase GiCAP sharing
rights, acquire the GiCAP codeword from the HP Utility Pricing Solu‐
tions portal (http://www.hp.com/go/icap/portal), and apply the associ‐
ated codeword to the active Group Manager system. You purchase at
least as many GiCAP sharing rights as the total number of cores without
usage rights across all the potential group members. Members can be
added to a GiCAP group as long as sufficient sharing rights are avail‐
able, and as long as the grouping rules indicate hardware compatibil‐
ity.
Unlike other iCAP codewords, GiCAP codewords must be generated for, and
applied to, a specific partition if the active Group Manager is on a
partitionable system. This means that in order to retrieve the code‐
word, you must specify the purchase order number, the system serial
number and partition information, if any. Use the command on the
active Group Manager system to get the applicable serial number and
nPar ID, or vPar code.
GiCAP codewords also have a sequence value and must be applied in the
order in which they were generated for the Group Manager system. How‐
ever, GiCAP codewords are sequenced independently from any other types
of iCAP codewords that might be generated for the same system, and can
therefore be applied independently from iCAP codewords.
GICAP GROUP CREATION
After the sharing rights codeword and the grouping rules have been
applied to the active Group Manager, a GiCAP group can be created by
issuing the command using the , and options. Members are added by
issuing the command using the option, the option to select the group
name, and the option to specify a name for the new member along with a
list of hosts running on the system. The list of hosts must include at
least one host per nPartition or virtual partition on the system.
Note that a single partition of a complex cannot join a GiCAP group;
all partitions of a complex must be specified when creating a group
member. All partitions on a group member must be running HP-UX or
OpenVMS. Each member that joins the group decreases the available
GiCAP sharing rights by the number of cores without usage rights con‐
tributed by that member complex.
GICAP RESOURCE SHARING
Once a group is established, Instant Capacity resources (core, cell
board, memory usage rights, and temporary capacity) can be shared among
all the members of the group.
Usage rights are shared by deactivating resources on one group member,
and then activating resources on another member of the group. In
effect, the system on which the resources were deactivated is loaning
usage rights to the activating (or borrowing) system. The activation
and deactivation commands are done using the usual and commands on the
individual member systems to effect this "loan" operation (also some‐
times referred to as a transfer of usage rights).
Any temporary capacity available to individual members of the group is
combined into a larger pool of temporary capacity that is available for
consumption by any and all members of the group, as needed. Usage of
shared temporary capacity is the same as with individually purchased
TiCAP: group members use the command to activate shared temporary
capacity. This differs from the sharing of usage rights in that tempo‐
rary capacity is never a loan to be returned; it is always depleted
through its usage over time.
GICAP MEMBER REMOVAL
Before removing a member from a GiCAP group, all the borrowed usage
rights must be returned, and all outstanding loans must be reclaimed.
Borrowed usage rights are returned by deactivating resources on the
member about to be removed. Loaned usage rights are reclaimed by deac‐
tivating enough resources elsewhere in the group to cover the loan.
The reclamation of loaned usage rights on the member about to be
removed does not require the activation of resources on that member.
As long as the usage rights are not in use elsewhere in the group,
removing the member results in the member reclaiming its loans.
There is no such constraint with respect to temporary capacity. A
removed member will take with it whatever temporary capacity is cur‐
rently assigned to it.
When a member is removed from a group, some number of sharing rights
are released and become available for future use. The number freed is
equal to the number of cores without usage rights on the removed mem‐
ber.
UPGRADES AND GICAP
Care must be exercised before upgrading or changing hardware or operat‐
ing systems for any member of a GiCAP group. If a member of a GiCAP
group changes hardware in such a way that the hardware is no longer
compatible with the group, then the group is considered to be out of
compliance and group functions are restricted as described in the sec‐
tion "Group Compliance".
Also, note that the number of available sharing rights is adjusted
whenever an iCAP codeword is applied to a GiCAP member system which
modifies the number of cores without usage rights on that member. (RTU
and AddOn codewords for cores cause such adjustments.)
If available sharing rights go negative (more in use than were pur‐
chased for the Group Manager), then all groups managed by that Group
Manager are out of compliance and all group functions are restricted
until the problem is resolved. The problem can be resolved by purchas‐
ing and applying additional sharing rights to the Group Manager, by
purchasing and applying core usage rights to one or more group members,
or by removing one or more group members from their group.
GROUPS AND THE TICAP BALANCE
Whenever you have more active cores than the number of core usage
rights, the temporary capacity balance is depleted as a mechanism for
tracking noncompliance of the group, even if TiCAP has not been pur‐
chased for or applied to any member of the group. This differs from
the behavior of TiCAP on a complex which is not a member of a group,
where TiCAP is decremented only if TiCAP had been specifically pur‐
chased for the complex. Within a GiCAP group, temporary capacity is
used as an additional compliance mechanism to support the high avail‐
ability features of a group.
Because group members are automatically considered to be users of tem‐
porary capacity, to avoid unexpected TiCAP depletion in a group, it is
important to avoid the situations that cause the Instant Capacity soft‐
ware to make assumptions that all cores might be active on a remote
nPartition, as described previously in the Temporary Capacity section.
If a member is removed from the group, the TiCAP balance on that com‐
plex will continue to be used as a compliance mechanism (decremented
whenever the number of active cores exceeds the number of core usage
rights), unless the TiCAP balance on the system is exactly 0.
GROUP COMPLIANCE
When a group is out of compliance, the group is said to be "locked".
Sharing of usage rights and temporary capacity between members of the
group is not allowed, although members can return borrowed usage rights
or reclaim loaned rights. Members cannot be added to the group, but
members can be removed from the group as long as the members deactivate
any cores using borrowed usage rights and as long as GiCAP is able to
reclaim any loaned usage rights.
When such an incompatibility is detected, the GiCAP Group Manager sends
email to the local root account and to the registered contact email
address for each member of the group.
MULTIPLE GROUP CONSIDERATIONS
You can create multiple GiCAP groups, and they can be managed by the
same Group Manager or by different Group Manager systems. Note that if
a Group Manager has an associated standby Group Manager, the standby
Group Manager functions as a standby for all the groups managed by that
Group Manager.
A server complex can only be a member of a single GiCAP group at a
time. In order to participate in a different group, it must be removed
from its group before being added to the other group.
Sharing rights can never be transferred between two active Group Man‐
ager systems. As you create new groups or add new members to existing
groups, you might need to purchase and apply additional sharing rights
to the relevant active Group Manager systems. This is necessary even
if the member has been moved from another Group Manager that now has
excess sharing rights.
Sharing rights can never be applied to a Group Manager with standby
status. If a standby Group Manager is requested to take control, the
sharing rights of the former active Group Manager move to it. If addi‐
tional sharing rights need to be applied before failing back to the
original Group Manager, they must be purchased specifically for the new
active Group Manager system (formerly the standby Group Manager) and
acquired from the portal. Once applied, the new total of sharing
rights moves to the originally active Group Manager if it is requested
to retake control, although only if the new active Group Manager is
able to propagate its GiCAP database to the originally active Group
Manager. For more details, see the "Group Manager Failover Considera‐
tions" section.
GROUP MANAGER FAILOVER CONSIDERATIONS
If the active Group Manager system becomes unavailable, the standby
Group Manager can take over GiCAP group operations from the Group Man‐
ager. If both the active Group Manager and the standby Group Manager
are unavailable, or if the active Group Manager fails and the command
was not issued to make the standby Group Manager the active Group Man‐
ager, usage rights and temporary capacity remain as per allocated to
each group member. Within a server complex, the usage rights can be
deployed to other partitions, but movement of usage rights and tempo‐
rary capacity between complexes cannot occur.
An administrator can have a standby Group Manager take control at any
time using the command. While this can be done routinely, for example
to allow shutting down a functioning active Group Manager for mainte‐
nance, normally this command is issued either when the active Group
Manager has failed, or when a network outage has made it unable to com‐
municate with critical group members. When a standby manager is told
to take control, it attempts to update all members and the current
active Group Manager so that group operations can proceed smoothly.
However, in the case of a failure, it is possible that the command is
unable to contact the active Group Manager and some members of the
groups that it now manages. When this happens, the previously active
Group Manager remains active, unaware of the change of control. This
is referred to as a "bifurcated" (or "split") GiCAP group. Members
that were reachable by the standby Group Manager when it took control
cannot accept commands from the old active Group Manager; but unreach‐
able members continue to consider it active. Control operations can be
carried out on both active Group Managers, each communicating with the
members that it (and only it) can reach. Groups and members can be
added or removed on both (subject to the set of members each can com‐
mand), and sharing rights can be added on both. In some cases this can
be valuable; for example, when two data centers each remain functional
but some intervening network link has been broken. Each isolated set
of systems can proceed with independent disaster recovery operations
within their group subset.
At some point, communication is restored and the split groups must be
rejoined. This is accomplished through issuing a new command. It can
be executed on either active Group Manager to confirm that Group Man‐
ager as the active Group Manager and demote the other to standby sta‐
tus. Be aware that doing this loses all database changes made on the
demoted Group Manager during the time that the group was split. There
is no method to merge the two databases, and in particular any new
sharing rights applied to the Group Manager designated now as standby
are lost.
Note that in the more straightforward case where the Group Manager
fails over to the standby Group Manager, but the standby is able to
contact all the members of the group, then on reboot of the originally
active Group Manager, the group is "split" only in the sense that both
Group Managers believe they are the active Group Manager. All members
are being managed by the newly active Group Manager (formerly the
standby), and all group database changes have been captured in the
database managed by the newly active Group Manager. In this case, what
is needed is to update the GiCAP database of the failed GiCAP Group
Manager, and optionally to fail back to the original Group Manager.
Updating the GiCAP database of the failed Group Manager involves issu‐
ing another command on the newly active Group Manager (formerly the
standby) once the failed Group Manager is rebooted and is network-con‐
tactable by the newly active Gorup Manager. Then, you may wish to fail
back to the originally active Group Manager by issuing another command
on that Group Manager.
ADDITIONAL GICAP CONSIDERATIONS
Systems that have no Instant Capacity components can be part of a GiCAP
group. Deactivating resources on these systems allows them to loan
usage rights to other members in the group.
Members of a GiCAP group do not have to be located near each other.
The only constraints are IP connectivity between the members, the Group
Manager, and the standby Group Manager (if any), sufficient GiCAP shar‐
ing rights, and adherence to the GiCAP grouping rules.
For systems with multiple network cards, you can specify the additional
network paths as additional hosts when defining member systems in a
group, for enhanced connectivity. However, there might be a signifi‐
cant performance penalty because the Instant Capacity software occa‐
sionally must access all the multiple hosts in that case. You cannot
specify the Group Manager and the standby Group Manager such that they
are different network paths to the same system. An OS instance can
host one and only one GiCAP database, regardless of the number of host‐
names by which that OS instance might be reachable.
WBEM version A.02.05 or higher must be installed on the Group Manager
and on all member systems in order to use Global Instant Capacity. The
CIM Server configuration property sslClientVerificationMode must be set
to a value of "optional" on all GiCAP Group Managers and on all OS
instances of all member systems. (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 man‐
agers and members of groups is established using SSL certificates that
are supplied by the GiCAP software.
COMPLIANCE
In general, a complex is in a compliant state when the number of active
components of a given type does not exceed the number of usage rights
associated with the type of component. The one exception is that the
number of active cores is allowed to exceed the number of core usage
rights as long as there is a sufficient positive balance of temporary
capacity. A negative balance always indicates a system which is out of
compliance.
A GiCAP group is in a compliant state as long as all the members are in
a compliant state, all the members of the group continue to have com‐
patible hardware as determined by the hardware grouping rules, and the
number of sharing rights installed on the GiCAP manager is equal or
greater than the total number of cores without usage rights on com‐
plexes managed by the Group Manager.
SEE ALSOicapmodify(1M), icapnotify(1M), icapstatus(1M), icapmanage(1M),
icapd(1M), parmgr(1M), parmodify(1M), parolrad(1M), vparmodify(1M).
iCAP(5)
