HP Instant Capacity Release Notes for Version 9.x

Compatibility with gWLM
iCAP version 9.0 is not compatible with gWLM version 4.0 or earlier. gWLM version 4.1 or later
is required.
Changes to icapmanage output
The icapmanage –s command has been changed to show the current date and time, the full
iCAP version string, and information about the standby Group Manager.
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
20 Major Changes, New Features, and Requirements of Instant Capacity Version 9.x