hpux icap man page on unix.com

iCAP(5) File Formats Manual 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 cellular (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 management 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/icapUserGuide.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 available 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-
specific 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
codewords are made available through the HP Utility Pricing Solutions portal (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, additional 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 activat-
ing cores), or other commands including (see parmodify(1M)) and (see parmgr(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 expi-
ration of the temporary capacity, and counts of active and inactive components.

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 nPartitions and thus, the new numbers to activate on reboot of the nPar-
titions.

Note that the status field intended active can differ from the status field actual active (AA) in some cases, including the following:

o In an nPartition, activations or deactivations can be deferred, meaning that the change is pending until the next reboot.

o If there are deconfigured (failed) cores, it may be impossible 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.

o 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 com-
mands 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 typically happens only during the window of time that resources are being shifted across the vir-
tual partitions of an nPartition. 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 environ-
ment, cores that are not assigned to any virtual partition are considered inactive (in addition to other classes of inactive cores). Unas-
signed 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 deactivate 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
adjustment 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 software, 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 performed 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
Capacity 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 Capacity 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
operation. The first step involves the user migrating the cores into or out of the default processor set; the second step is the activa-
tion 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 temporary 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 purchased, 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
portal) 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 flexibility 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 tem-
porary capacity.

A similar scenario exists for load balancing. Rather than using temporary 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
manage 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 recommended 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 par-
titions 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 manage-
ment 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 Manager's status becomes "standby". For more details, see the "Group
Manager 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
hardware-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 Manager, 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 associated 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 available, and as long as the grouping rules indicate hardware compati-
bility.

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 codeword, 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.
However, 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 contributed 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
sometimes 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 pur-
chased TiCAP: group members use the command to activate shared temporary capacity. This differs from the sharing of usage rights in that
temporary 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 member.

UPGRADES AND GICAP
Care must be exercised before upgrading or changing hardware or operating 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 section "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 mod-
ifies 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 purchased for the Group Manager), then all groups managed by that Group Man-
ager are out of compliance and all group functions are restricted until the problem is resolved. The problem can be resolved by purchasing
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 purchased 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 purchased
for the complex. Within a GiCAP group, temporary capacity is used as an additional compliance mechanism to support the high availability
features of a group.

Because group members are automatically considered to be users of temporary capacity, to avoid unexpected TiCAP depletion in a group, it is
important to avoid the situations that cause the Instant Capacity software 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 complex 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 Manager 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 additional 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 Considerations" 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 Manager, 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 exam-
ple to allow shutting down a functioning active Group Manager for maintenance, normally this command is issued either when the active Group
Manager has failed, or when a network outage has made it unable to communicate 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 unreachable 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 command), 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 iso-
lated 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 Manager as the active Group Manager and demote the other to standby
status. 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 con-
tact 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 issuing another command on the newly active Group Manager (formerly the
standby) once the failed Group Manager is rebooted and is network-contactable 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 sharing 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 significant 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
hostnames 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 managers 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
compatible 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 complexes managed by the Group Manager.

SEE ALSO
icapmodify(1M), icapnotify(1M), icapstatus(1M), icapmanage(1M), icapd(1M), parmgr(1M), parmodify(1M), parolrad(1M), vparmodify(1M).

iCAP(5)

hpux man page for icap