HP Instant Capacity Release Notes for Version 9.x

Split GiCAP groups
If the active Group Manager system becomes unavailable, an administrator can have a standby
Group Manager take control of 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 issued either when the active
Group Manager has failed, or when a network outage prevents it from communicating with
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 will be unable to contact the active Group Manager and some members of the
groups it manages. If this happens, the previously active Group Manager might remain active,
unaware of the change in control. This is referred to as a bifurcated (or split) GiCAP group. For
details about 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 User's Guide for Version
9.x available at http://www.docs.hp.com.
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 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.
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 side effects. For example, the total temporary capacity for
a group reported by the icapmanage -s command might 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, however, remember that 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 show 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 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.
Removal of member from a group after reignite
In some circumstances, attempting to remove a member from a group after reigniting one or
more hosts on the member will fail. A workaround is to update the host list of the member,
removing and re-adding the reignited hosts. The following is an example of updating the host
list for a group member:
icapmanage -u -m member -h host!host
Known Problems 29