HP Instant Capacity release notes for Version 10.x (March 2011)

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 10.x 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 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
26 Major Changes, New Features, and Requirements of Instant Capacity Version 10.x