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

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
After 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 icapmodify and parmodify 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 purchased TiCAP:
group members use the icapmodify -a -t 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 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 you remove the member when the usage rights are not in use elsewhere in the group, the member
reclaims its loans.
This constraint is not applicable to temporary capacity. A removed member takes with it whatever
temporary capacity is currently 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 the hardware in such a way
that the hardware is no longer compatible with the group, 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 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 purchased 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 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
148