HP Instant Capacity Version 10.x User Guide (5900-1581, March 2011)

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
icapmodify command on any partition of the complex. iCAP codewords 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 icapmodify command
(if activating cores), or other commands including parmodify (see parmodify(1M)) and parmgr
(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 icapstatus 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 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
icapmodify, parcreate, and parmodify to represent the new distribution of active cores
across the nPartitions and thus, the new numbers to activate on reboot of the nPartitions.
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 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.
• In a virtual partition, core assignments can be increased or decreased with either the
icapmodify command or the vparmodify command, but only icapmodify changes the
intended active for the nPartition. vparmodify 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 typically happens only during the window of time
that resources are being shifted across the virtual 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 icapstatus 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 icapmanage -s command on a Group
Manager system.
117