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

per configured cell in the newly booted partition. This can result in the number of active cores
being large enough to incur temporary capacity charges.
• Contact HP for additional methods.
Inconsistent values reported by icapmanage during rapid updating
If the command icapmanage -s is issued while the group is being rapidly updated ( for example,
during gWLM load balancing), the number of loans and borrows assigned to each member may
not add up in a consistent manner. This is because the status reporting checks with each member
in turn, and if resources are simultaneously being reassigned between group members, the reporting
may reflect an intermediate state. If this occurs, reissue the status command when the group is in
a quiescent state
Cannot re-seize core usage rights from the same complex
If usage rights have been seized from partition A of a complex and used during failover on partition
B of the same complex, and if the problem on partition A is resolved, you should failback to partition
A (using a restore operation or reactivation of cores on A). You should not make partition B the
new primary because if B fails, you cannot re-seize the previously seized rights on partition B, as
this would exceed the allowed number of seized usage rights for the complex. Additionally,
configurations where the primary node and the failover node are part of the same complex are
not recommended for mission-critical applications, because of the possibility of a single point of
failure.
Invalid contact address corrupts the GiCAP database
If a GiCAP member sets the contact email address to a value of spaces (using the command
icapmodify -c " "), this causes the GiCAP database to become 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 has a failure and you decide to remove it as a standby (by issuing
the command icapmanage -r -S on the active Group Manager), then if the failed system
subsequently is booted, it still believes that it is a standby Group Manager. This occurs even though
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.
Known Problems 25