HP Instant Capacity Version 10.x Release Notes (5900-2062, December 2011)

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 run 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 displays
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 hangs.
Split GiCAP groups
If the active Group Manager system is unavailable, an administrator can have a standby Group
Manager take 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 will result 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, however, 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.
Known problems 9