HP Instant Capacity support for HP Integrity Superdome 2 with Dynamic Cores - Release Notes (5900-3370, December 2013)

The active OA must be followed by the standby OA. If you specify the standby OA followed by
the active OA with the icapmanage command, you practically do not see any error messages.
Executing the icapmanage -s command, however, indicates that the member was not added.
icapmodify produces "Parse error" for a GiCAP group member
icapmodify can indicate the following error message:
Parse error at line 1: unknown encoding.
The workaround for this issue is to re-add the member to the group.
TiCAP warning period actions are not performed when TiCAP prefetch occurs
When some amount of the TiCAP resource is moved from one member/members to another, the
TiCAP balance on the donor member(s) might fall below the configured TiCAP warning period. In
this case, neither the OA syslog notification nor email alert notification is provided.
Temporary capacity reporting in a group
Temporary capacity is sometimes held by the Group Manager for quick deployment to individual
members. This can have unexpected results. For example, the total temporary capacity for a group
reported by the icapmanage -s command may exceed the total obtained by adding the individual
temporary capacity balances reported for the members of the group or temporary capacity might
be shifted from one member system to another member system, even when an activation request
gets an error. In general, temporary capacity for a group is pooled for use by all members of the
group. Therefore, the true balance for the group is always represented by the group total reported
by the icapmanage -s command, and that total is always available to all members of the group.
Note that in version 8.02 or later, the verbose option (-v) is enhanced to display more information,
most notably the TiCAP balance held by the Group Manager.
Automatic multi-homing not supported
GiCAP does not support automatic multi-homing (multiple NICs and IPs for a host). A member is
always contacted using the hostname (or a list of hostnames) provided when it is added to the
group. A member always communicates with the Group Manager through its hostname. If the
Group Manager is not reachable through that hostname by a given member, the member is unable
to participate in the group.
Considerations when upgrading hardware on a Group Manager
If you upgrade the hardware on a Group Manager system, you must preserve the UUID and the
partition information on the system.
If AGM is unable to get status of SGM it shows that as active GM
If AGM is unable to collect status of SGM due to any reason (network is not reachable (or) cimserver
is down (or) cimserver is not responding within the given time (or) HP_GiCAPProviderModule is
not responding), AGM assumes that SGM is also an active GM. And this can be very well a case
of split group. Verify if cimserver on SGM is working fine, and whether it is reachable from AGM,
if this problem persists.
Connection is lost between GM and member, in case of OA failover
During OA failover (if ENCLOSURE_IP_MODE is not enabled on the member OA), GM does not
know the hostname or the IP address of the new active OA. To resolve this issue:
1. Delete the certificate from cimtrust (in AGM, SGM).
2. Swap the IP address between the active OA and standby OA. If you are unable to perform
this operation from a remote system before the TCP session is disconnected, you need to
perform it by connecting it to each OA CLI using the serial port.
3. After reconfiguring the IP addresses, remove the member from the group.
14 Instant Capacity support for HP Integrity Superdome 2 with dynamic cores release notes