HP Instant Capacity (iCAP) GiCAP Group Creation, GiCAP Resource Sharing, GiCAP Member Removal

GiCAP codewords also have a sequence value and must be applied in the order in which they were generated for the Group Manager system. However, GiCAP codewords are sequenced independently from any other types of iCAP codewords that might be generated for the same system, and can therefore be applied independently from iCAP codewords.

GiCAP Group Creation

After the sharing rights codeword and the grouping rules have been applied to the active Group Manager, a GiCAP group can be created by issuing the icapmanage command using the -a, -gand -moptions. Members are added by issuing the icapmanage command using the -aoption, the -goption to select the group name, and the -moption to specify a name for the new member along with a list of hosts running on the system. The list of hosts must include at least one host per nPartition or virtual partition on the system.

Note that a single partition of a complex cannot join a GiCAP group; all partitions of a complex must be specified when creating a group member. All partitions on a group member must be running HP-UX or OpenVMS. 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

Once 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-tcommand 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. As long as the usage rights are not in use elsewhere in the group, removing the member results in the member reclaiming its loans.

There is no such constraint with respect to temporary capacity. A removed member will take 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 hardware in such a way that the hardware is no longer compatible with the group, then the group is considered to be out of compliance and group functions are restricted as described in the section “Group Compliance”.

155