HP Instant Capacity Version 10.x Release Notes (5900-1580, March 2011)

the rest of the group does not believe it to be a standby Manager. If you want to re-establish it as
the standby, simply issue the command icapmanage -a -S on the active Group Manager.
However, if you have already established another standby Group Manager (for example), or just
want to remove the leftover standby information, you need to stop the cimprovider and remove
the GiCAP database from the previously failed system. Use commands similar to the following on
the system where you want to remove the standby information:
icapmanage -s # verify that this is the *obsolete* standby system
cimprovider -d HP_GiCAPProviderModule
rm /etc/opt/iCAP/GiCAP_db
IMPORTANT: Do not issue the above sequence of commands on any system that is the active
Group Manager for the group, as it removes the GiCAP database entirely and leaves the group
members in an orphaned state.
icapmanage hangs when specifying illegal standby group manager
When adding a standby Group Manager using the icapmanage -a -S command, you cannot
specify a system to be a standby for itself. The icapmanage command does detect and give an
error in the case where you specify a hostname exactly equal to the hostname where you invoke
the icapmanage command. However, if you specify an alternate hostname for the OS instance
running the icapmanage command, the command will hang.
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 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 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
22 Major Changes, New Features, and Requirements of Instant Capacity Version 10.x