HP Instant Capacity (iCAP) manual Groups and the TiCAP Balance, 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 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

156