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

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
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
122