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

A server complex can be a member of only one GiCAP group at a time. 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 active Group Manager systems. As you create
new groups or add new members to existing groups, you might need to purchase and apply
additional sharing rights to the relevant active Group Manager systems. This is necessary even if
the member has been moved from another Group Manager that now has excess sharing rights.
Sharing rights can never be applied to a Group Manager with standby status. If a standby Group
Manager is requested to take control, the sharing rights of the former active Group Manager move
to it. If additional sharing rights need to be applied before failing back to the original Group
Manager, they must be purchased specifically for the new active Group Manager system (formerly
the standby Group Manager) and acquired from the portal. After applied, the new total of sharing
rights moves to the originally active Group Manager if it is requested to retake control, although
only if the new active Group Manager is able to propagate its GiCAP database to the originally
active Group Manager.
Additional considerations
Systems that do not have any iCAP components can be part of a GiCAP group. Deactivating
resources on these systems allows them to loan usage rights to other members in the group.
Members of a GiCAP group do not have to be located near each other. IP connectivity between
the members, the Group Manager, and the standby Group Manager (if any), sufficient GiCAP
sharing rights, and adherence to the GiCAP grouping rules are the only constraints.
For systems with multiple network cards, you can specify the additional network paths as additional
hosts when defining member systems in a group, for enhanced connectivity. However, there might
be a significant performance penalty because the iCAP software occasionally must access all the
multiple hosts in that case. You cannot specify the Group Manager and the standby Group Manager
such that they are different network paths to the same system. An OS instance can host one and
only one GiCAP database, regardless of the number of hostnames by which that OS instance
might be reachable.
WBEM version A.02.09 or higher must be installed on the Group Manager and on all member
systems to use GiCAP. The CIM Server configuration property sslClientVerificationMode must be
set to a value of “optional” and enableHttpsConnection must be set to “true” on all GiCAP Group
Managers and on all OS instances of all member systems. (The CIM Server may need to be restarted
if the property was not previously set to this value.) For details, see cimconfig(1M). Note that
communication between the managers and members of groups is established using SSL certificates
that are supplied by the GiCAP software.
If the active GiCAP Group Manager system becomes unavailable, the standby GiCAP Group
Manager can take over GiCAP group operations from the Group Manager. If both the active
Group Manager and the standby Group Manager are unavailable, usage rights and temporary
capacity remain as allocated to each group member. Within a server complex, the usage rights
can be deployed to other partitions, but movement of usage rights between complexes cannot
occur.
On a system with full usage rights, the icapd daemon does not constantly verify the system
configuration. It can take up to 12 hours for each partition of a system converted from non-iCAP
to iCAP to discover that it is now an iCAP system. During this time, icapmanage -s shows
asterisks for the new member, and the icapstatus command issued on that system shows “Runs
iCAP” as “N”. To force a faster conversion, kill the icapd daemon and wait for it to restart.
Additional considerations 85