HP Instant Capacity Version 10.x Release Notes (5900-1580, March 2011)

from the partition, shutting down the partition from within the operating system using shutdown
-R -H, or with the MP RR command.
However, even if the cells are made inactive, the Instant Capacity software reserves usage rights
to minimize the possibility that the complex is taken out of compliance if the partition is booted
with all cores active. Unique considerations apply to this assumed reserved state. In this state,
additional activations may not be allowed unless temporary capacity is authorized on the activation.
Use one of the following methods to allow continued resource migrations after the iCAP daemon
puts the complex in the assumed reserved state:
• Reboot the failed partition, if possible.
• Delete the failed partition.
• Reduce the number of cores considered active at the next boot by setting the UONB (Use on
Next Boot) value to false for one or more of the cells in the failed partition, or by removing
one or more cells from the partition. Note, powering off the cells does not change the assumed
reserved state.
• 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
Known Problems 21