HP Instant Capacity Version 10.x User Guide (762794-001, March 2014)

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 if 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 GiCAP 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. if 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.
Reinstalling a group member
If a group member is reignited, use the icapmanage command as follows to reestablish
communication between the newly ignited group member and the Group Manager:
icapmanage -a -m <member>:<host> -g <group_name>
Removing a GiCAP group member 77