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

Between the time the core usage rights are made available and the Instant Capacity daemon
monitors temporary capacity consumption, the icapstatus command reports that temporary
capacity is being consumed when it is not. When the transfer of usage rights is completed, the
icapstatus output is updated on both systems to reflect the transfer. Because of the delay, the
changes might appear to be unrelated to a user-initiated operation, but they are due to the previously
initiated deactivation that freed up core usage rights.
Temporary Capacity and Status Reporting
The temporary capacity balance reported by icapstatus on a group member reflects only the
temporary capacity that has been applied or transferred to that system via the Group Manager.
You might still receive temporary capacity expiration warning messages even though more temporary
capacity is available in the group.
Temporary capacity is transferred to group members in 30-minute blocks. When a block of
temporary capacity has been consumed, the Group Manager continues to transfer group temporary
capacity to the system every 30 minutes as long as it is available. However, the icapstatus
command on the local system might report temporary capacity as expired even though it is still
being used to activate cores, as shown in the icapstatus listing of “Number of cores using
temporary capacity”.
Temporary Capacity Prefetch
Because temporary capacity is pooled for the group, adjustments to the temporary capacity balance
can be made even when it is not being consumed. For performance reasons, the Group Manager
anticipates potential future use of temporary capacity and might prefetch an amount of temporary
capacity from one or more member systems. Although temporary capacity will not be used on a
member system unless the -t option was specified with the icapmodify command, an
icapmodify command without the -t option might still result in an adjustment of the temporary
capacity balance for members of the group. When this happens, the overall temporary capacity
balance for the group does not change, but there might be differences in the allocation to individual
member systems.
Removing a Global Instant Capacity Group Member
Before removing a member from a GiCAP group, all the borrowed usage rights must be returned
and all outstanding loans reclaimed. Do this by deactivating resources on the member about to
be removed. Loaned usage rights are reclaimed by deactivating 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 constraint on temporary capacity because a removed member will take with it whatever
temporary capacity is assigned to it.
When a member is removed from a group, some number of sharing rights are released and made
available for future use. The number freed is equal to the number of cores without usage rights on
the removed member.
The following commands remove member IT from its group, and then remove group one:
> icapmanage -r -m IT
Member IT removed.
> icapmanage -r -g one
Group one removed.
A group cannot be removed until all members in that group have been removed.
Removing a Global Instant Capacity Group Member 81