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

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,
-g and -m options. Members are added by issuing the icapmanage command using the -a
option, the -g option to select the group name, and the -m option 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 -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.
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”.
121