HP Instant Capacity Release Notes for Versions 8.x

Known Problems
Occasional Failure Message (HP-UX)
On a busy system, you may occasionally get the message “Failure writing Instant Capacity data
to Dynamic Profile”. This happens because the Instant Capacity software needs to update the
volatile data which is synchronized by the MP. If there are multiple readers and writers accessing
the data at the same time, there is a natural race condition that can result in a failure to update
the data. If that happens, retry the Instant Capacity operation you initiated.
icapmodify and parmodify Timeout (HP-UX)
There is a known problem with commands trying to activate resources in a GiCAP group, such
as icapmodify and parmodify, that may fail due to a timeout error. If you receive a timeout
error similar to the following error message, and resources are available, you should retry the
command.
Internal Error: Exception caught for modify.Timed out waiting for a
response.[Error received whenconnecting to or getting information from
theInstant Capacity (iCAP) provider]
Interaction between iCAP and gWLM (HP-UX)
gWLM version 2.5 fails to migrate CPUs if it is used with iCAP version 8.00 (or later) and a there
is a zero or negative TiCAP balance.
Lowlevel WBEM Errors (HP-UX)
Occasionally, on a busy system, especially one with many partitions, you may get errors such
as:
icapd: Caught exception: ERROR: The following low-level WBEM error occurred:
CIM_ERR_FAILED:A general error occurred that is not covered by a more specific error code:
"@4:Software error.[Error on ioctl.] Connection timed out"
or:
icapd: ERROR: The following low-level error occurred:
ERROR: The following low-level WBEM error occurred: connection timed out
or:
ERROR: The following low-level WBEM error occurred: Empty HTTP response message.
or:
ERROR: The following low-level WBEM error occurred: Locking or unlocking the target failed.
This is due to contention for system resources from the various partitions in the complex. If these
messages are received, retry the Instant Capacity operation.
GiCAP Known Problems (HP-UX)
Under some circumstances, the borrow/loan values reported byicapstatus for a member of
a GiCAP group do not reflect expected changes in values. This typically happens when usage
rights have been released by a member system but have not yet been assigned or “reclaimed”
by another member system in the group. The icapmanage -s -v command will show which
resources are held by the Group Manager.
Temporary capacity is sometimes held by the Group Manager for quick deployment to individual
members. This can have some unexpected side effects. For example, the total temporary capacity
reported by icapmanage -s for the group may in some cases exceed the total obtained by
adding the individual temporary capacity balances reported for the members of the group. Or,
you may see that temporary capacity is shifted from one member system to another member
system, even when an activation request gets an error. But in general, remember that temporary
capacity for a group is pooled for use by all members of the group, so the true balance for the
Known Problems 25