HP Instant Capacity Version 10.x Release Notes (5900-2169, January 2012)

Removing the standby group manager when it has a failure
If the standby Group Manager has a failure and you decide to remove it as a standby (by executing
the command icapmanage -r -S on the active Group Manager), then if the failed system
subsequently is booted, it still considers that it is a standby Group Manager. This occurs even
though the rest of the group does not consider it to be a standby Manager. If you want to re-establish
it as the standby, run 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 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
Known problems 9