HP Instant Capacity support for HP Integrity Superdome 2 with Dynamic Cores Release Notes

Invalid contact address corrupts the GiCAP database
If a GiCAP member sets the contact email address value of spaces (using the command
icapmodify -c " "), the GiCAP database gets corrupted. If this happens, the GiCAP group
must be re-created.
Removing the standby group manager when it has a failure
If the standby Group Manager fails and you decide to remove it from being a standby (by executing
the command icapmanage -r -S on the active Group Manager), and 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: You must not run the above sequence of commands on any system that is the active
Group Manager for the group, because 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 ensure that a standby
Group Manager takes 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 results in the RTUs moving to the correct member.
Known problems 9