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

Improvements in icapmanage error and status messages
In previous releases, running the icapmanage –r –m <member> command on a member not
defined in any group produced an unclear error message. The command now fails with an error
message stating that the member cannot be found in any group. In addition, error and status
messages have been improved for these situations: when no groups are defined, when a group
is locked for compliance reasons, when icapmanage is run by a non-root user, and when
erroneously attempting to add virtual machines (“guests”) as group member host systems.
Changes to the verbose status option of icapmanage
With the V9 release, the verbose status command (icapmanage -s -v) attempts to contact every
host of each group member to check that two-way communication can be established between the
issuing group manager (either active or standby) and each such host. The icapmanage -s
command without -v attempts to contact multiple hosts of a group member only if that is necessary
to find a host that responds. In either case, icapmanage -s reports the hosts it failed to contact.
Use of the -v option can be useful as a general check of group communication.
Changes to icapmodify on GiCAP group members
In previous releases, running the command icapmodify -a -t on a GiCAP group member
resulted in the transfer of only enough temporary capacity to cover the immediate activation of
cores to move the system into a compliant state. This command now causes the immediate transfer
of a larger amount of temporary capacity, if that is necessary to take the member out of the TiCAP
warning period.
Disabling icapmodify in a noncompliant vPar database state
After performing a usage rights seizure by a GiCAP Group Manager on a virtual partition (using
the icapmanage –x command), the number of Actual Active cores might be greater than the
number of Intended Active cores, thus putting the vPar database in a noncompliant state. In this
state, all virtual partitions listed in the vPar database are not allowed to boot. With this release,
the icapmodify command is not allowed and an error is issued stating that the vPar database
is out of compliance. To bring the vPar database into compliance, deactivate cores using the
vparmodify command.
Changes to Temporary Capacity
In iCAP version 8.02, a change was made to use TiCAP debiting as a compliance enforcement
mechanism on all systems, even on systems where TiCAP had never been applied. In version 9.0
this has been changed to pre-version 8.02 behavior so that TiCAP is debited as a compliance
enforcement mechanism only on these systems:
• A system where TiCAP has been applied (the TiCAP balance is nonzero)
• A GiCAP group member system (or a system which had previously been a GiCAP group
member and has a nonzero TiCAP balance)
• A system which has had a TiCAP debit within the past 24 hours
TiCAP debit fixes
Two race conditions that might have caused incorrect TiCAP debiting have been fixed. One was
identified as a potential problem during an ignite installation of one partition, while another partition
was active (and running the iCAP daemon). Another potential problem involved a very small and
unusual timing window when concurrent activations and deactivations were done on different
partitions of the same server.
18 Major Changes, New Features, and Requirements of Instant Capacity Version 10.x