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

Manager, and all OS instances of all member systems must have the CIM Server property
sslClientVerificationMode set to a value of “optional”.
GiCAP and iCAP do not use any network ports directly. However, version 9.0 GiCAP uses
WBEM/SSL for the communication protocol, requiring use of the CIM HTTPS port 5989. GiCAP
also uses ping (which uses port 7 for the echo protocol) and host lookup services (getaddrinfo
and getnameinfo) which may use the Domain Name System (DNS), Network Information Service
(NIS), or a local host file to provide the lookup function.
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
14 Major Changes, New Features, and Requirements of Instant Capacity Version 10.x