HP Instant Capacity User's Guide for Versions 8.x

GiCAP Member Removal
Before removing a member from a GiCAP group, all the borrowed usage rights must be returned
and all outstanding loans reclaimed by deactivating resources on the appropriate system. There
is no need to activate resources to reclaim loaned usage rights as the act of removing the member
from a GiCAP group will reclaim the necessary usage rights.
There is no constraint with respect to temporary capacity as it is consumed shortly after it moves
from one member in a GiCAP group to another that requires it; it is never “returned”.
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 used when the member
was added to the group: equal to the number of cores without usage rights contributed by that
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”.
If a GiCAP member is booted with a different operating system than it was running when it
joined the group (for example, it was booted with HP-UX when it joined the group, and it is now
booted with Linux), group membership may be lost. Physical communication between the Group
Manager and group members relies on operating system-specific information. If the operating
system on a group member is changed, the member must be removed from the group before
rebooting with the new operating system, and must be added to the group after rebooting.
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, purchasing and applying core usage
rights (RTUs) to one or more group members, or by removing one or more group members from
their group.
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 will not be 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 return any borrowed usage
rights and reclaim any loaned usage rights before removal.
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.
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 one group before being added to the other group.
Sharing Rights can never be transferred between two Group Manager systems. As you create
new groups and/or add new members to existing groups, you may need to purchase and apply
additional Sharing Rights to the relevant Group Manager systems.
141