HP Instant Capacity (iCAP) manual Status Reporting

member system needs to be activated, the usage rights made available by the deactivated component can be taken by the system using temporary capacity. In this case you might need to use the -toption to the icapmodify command to activate the component on the third member system by using temporary capacity.

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.

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.

Status Reporting

Usage rights and temporary capacity can sometimes be temporarily assigned to the Group Manager, which can result in difficulty interpreting some of the data from the icapstatus command. The total temporary capacity reported for the group by icapmanage -smight not equal the sum of temporary capacity reported by each member system. This is because the Group Manager prefetches an amount of temporary capacity in anticipation of needing it for a future operation, so the temporary capacity might not be immediately assigned to a member system. Also, individual counts of cores, cells, and memory without usage rights for each member of the group might not add up to the total counts of cores, cells, and memory without usage rights for the group. In all cases, totals reported (by icapmanage -s) for group temporary capacity and usage rights are the important values that represent available resources for the group. Use the verbose (-v) option to the icapmanage -scommand to see resources held by the Group Manager.

The icapstatus command reports usage rights borrowed or loaned by the system from or to other members of the group. Borrowed rights are those that are currently resident on the member and that originated elsewhere. Loaned rights originate on the system but are currently resident somewhere else in the group. They might be either in use or unassigned on another group member, or they might be unassigned on the Group Manager itself. The icapmanage -scommand displays the status of the entire group, while the icapstatus command displays an isolated view of a single member.

Unassigned usage rights are free to be moved to other member systems, even if a particular activation request fails. For example, consider a group where there are no free usage rights. If member m1 releases 2 core usage rights by deactivating 2 cores, and member m2 tries to activate 3 cores, the activation request fails (not enough usage rights), after the Group Manager has already migrated 2 core usage rights from m1 to m2. The borrow and loan values for m1 and m2 show that the loan has occurred, even though the activation on m2 failed to activate any cores. A subsequent activation of 2 cores on m2 will be successful and will occur more quickly because the 2 core usage rights are already assigned to m2, or because the rights are moved elsewhere in the group if requested.

Global Instant Capacity Resource Sharing 113