HP Instant Capacity release notes for Version 10.x, August 2010 (T1428-90081)

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.
Changes to icapstatus output
The icapstatus command has been changed so that the Actual Active cores count now includes
the total number of cores assigned to the vPar database, including any cores used by an
inaccessible virtual partition.
The GiCAP section of the icapstatus output has been expanded and now includes information
about the active Group Manager and the standby Group Manager.
The icapstatus output now displays the full iCAP version string and a date and time have
been added to the local nPartition status.
22 Major Changes, New Features, and Requirements of Instant Capacity Version 10.x