HP Instant Capacity release notes for Version 10.x (5900-1258, October 2010)

• Authorize the use of temporary capacity on requested activations (using the -t option).
This allows the reserved usage rights across the complex to exceed the number of actual
usage rights. Temporary capacity is charged only if the number of active cores exceeds the
number of actual usage rights. If the failed partition remains inactive and the number of
active cores does not exceed the count of actual usage rights, temporary capacity is not
charged. You must be careful with this method. A reboot of the failed partition activates at
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
Known Problems 29