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

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.
Internal Representation of the Group Manager
In previous releases, the internal representation of the Group Manager was maintained as an IP
address. It is now maintained by its host name. This enables the use of a GiCAP Group Manager
using DHCP for dynamic IP addresses.
New GiCAP Configuration File for Group Members
In versions 9.0 and later, the file /etc/opt/iCAP/GiCAP.configFile is created on every
host of a GiCAP group member. It contains information needed by the iCAP software when
contacting the Group Manager for the host.
GiCAP Activation Time
In iCAP versions prior to 9.0, the GiCAP Group Manager would do an iCAP compliance check
of every group member whenever the GiCAP Group Manager was restarted. This could occur
quite frequently due to the automatic shutdown of the GiCAP Group Manager WBEM provider by
the local CIM server. The CIM server shuts down WBEM providers, such as the GiCAP Provider,
whenever it has been idle for a period of time. This means that GiCAP Group Manager restarts
could happen multiple times during the day, depending on how frequently the GiCAP Group
Manager was accessed by icapmanage or icapmodify commands.
With this release, the GiCAP Group Manager does an iCAP compliance check on a group member
only once a day or any time a host on that member reboots. The once a day compliance checks
are done at different times for each group member, thereby diffusing the performance impact of
starting up the GiCAP Group Manager.
The impact of this performance improvement depends on the size of your group, and the number
and timing of your GiCAP-related commands.
Summary of New Features and Changes 15