HP Instant Capacity Version 10.x User Guide (762794-001, March 2014)

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.
If you remove the member when the usage rights are not in use elsewhere in the group, the member
reclaims its loans.
This constraint is not applicable to temporary capacity. A removed member takes 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.
If DNS is not used, you need to remove the IP address information about the Group Manager from
a member being removed. Otherwise, this member cannot be added to other GiCAP group.
Here is the procedure to perform it and restore the original set up:
# icapmanage -P -I
# icapmanage -I
# icapmanage -r —m <member name>
# icapmanage -I <IP Address for the Active Group Manager>
# icapmanage -P —I <IP Address for the Standby Group Manager>
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 the hardware in such a way
that the hardware is no longer compatible with the group, the group is considered to be out of
compliance and group functions are restricted as described in the section 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),
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 TiCAP section.
If a member is removed from the group, the TiCAP balance on that complex continues 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.
198