HP Instant Capacity Release Notes for Version 9.x

least one core 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.
28 Major Changes, New Features, and Requirements of Instant Capacity Version 9.x