HP Instant Capacity Version 10.x Release Notes (5900-2363, September 2012)

Split GiCAP groups
If the active Group Manager system is unavailable, an administrator can ensure that a standby
Group Manager takes control of the group operations at any time using the icapmanage -Q
command. While this can be done routinely (for example, to allow shutting down a functioning,
active Group Manager for maintenance), normally, this command is executed either when the
active Group Manager has failed, or when a network outage prevents it from communicating with
the group members. When a standby manager takes control, it attempts to update all members
and the current active Group Manager. However, in failure cases, it is possible that the
icapmanage -Q command is unable to contact the active Group Manager and some members
of the groups it manages. If this happens, the previously active Group Manager may remain active,
unaware of the change in control. This is referred to as a bifurcated (or split) GiCAP group. For
information on how to repair and manage split groups, see the section titled Group Manager
Failover Considerations in either the icap(1M) manpage, or the HP Instant Capacity Version 10.x
User Guide available at www.hp.com/go/hp-icap-docs.
icapstatus borrow/loan values
Under some circumstances, the borrow and loan values reported by the icapstatus command
for a member of a GiCAP group do not reflect expected changes in values. This typically happens
when the usage rights are released by a member system but are not yet assigned or reclaimed by
another member system in the group. The icapmanage -s -v command shows which resources
are held by the Group Manager. While RTUs count may seem wrong – any actual icapmodify
operations results in the RTUs moving to the correct member.
Temporary capacity reporting in a group
Temporary capacity is sometimes held by the Group Manager for quick deployment to individual
members. This can have unexpected results. For example, the total temporary capacity for a group
reported by the icapmanage -s command may exceed the total obtained by adding the individual
temporary capacity balances reported for the members of the group or temporary capacity might
be shifted from one member system to another member system, even when an activation request
gets an error. In general, temporary capacity for a group is pooled for use by all members of the
group. Therefore, the true balance for the group is always represented by the group total reported
by the icapmanage -s command, and that total is always available to all members of the group.
Note that in version 8.02 or later, the verbose option (-v) is enhanced to display more information,
most notably the TiCAP balance held by the Group Manager.
Automatic multi-homing not supported
GiCAP does not support automatic multi-homing (multiple NICs and IPs for a host). A member is
always contacted using the hostname (or a list of hostnames) provided when it is added to the
group. A member always communicates with the Group Manager through its hostname. If the
Group Manager is not reachable through that hostname by a given member, the member is unable
to participate in the group.
Considerations when upgrading hardware on a Group Manager
If you upgrade the hardware on a Group Manager system, you must preserve and restore the
UUID and the partition information on the system.
If AGM is unable to get status of SGM it shows that as Active GM
If AGM is unable to collect status of SGM due to any reason (network is not reachable (or) cimserver
is down (or) cimserver is not responding within the given time (or) WEBMProvider is not responding),
AGM assumes that SGM is also an active GM. And this can be very well a case of split group.
Verify if cimserver on SGM is working fine, and whether it is reachable from AGM, if this problem
persists.
Known problems 9