HP Instant Capacity support for HP Integrity Superdome 2 with Dynamic Cores - Release Notes (762795-001, March 2014)

Split GiCAP groups
If the active Group Manager system is unavailable, an administrator can ensure that a standby
Group Manager takes control of the group operations at any time using the icapmanage -Q
command. While this can be done routinely (for example, to allow shutting down a functioning,
active Group Manager for maintenance), normally, this command is executed either when the
active Group Manager has failed, or when a network outage prevents it from communicating with
the group members. When a standby manager takes control, it attempts to update all members
and the current active Group Manager. However, in failure cases, it is possible that the
icapmanage -Q command is unable to contact the active Group Manager and some members
of the groups it manages. If this happens, the previous active Group Manager may remain active,
unaware of the change in control. This is referred to as a bifurcated (or split) GiCAP group. For
information on how to repair and manage split groups, see the section titled Group Manager
Failover Considerations in either the icap(1M) manpage, or the HP Instant Capacity Version 10.x
User Guide available at http://www.hp.com/go/hp-icap-docs.
icapstatus borrow/loan values
Under some circumstances, the borrow and loan values reported by the icapstatus command
for a member of a GiCAP group do not reflect expected changes in values. This typically happens
when the usage rights are released by a member system but are not yet assigned or reclaimed by
another member system in the group. The icapmanage -s -v command shows which resources
are held by the Group Manager. While RTUs count may seem wrong – any actual icapmodify
operations results in the RTUs moving to the correct member.
vparmodify activates TiCAP regardless of TiCAP pre-authentication flag
If a member cannot communicate with the active GM due to any reason when core activation is
attempted with vparmodify, TiCAP cores may be implicitly used regardless of the TiCAP
pre-authorization flag. This symptom does not occur with icapmodify for the same vPar under
the same situation.
Adding a member with multiple OAs in a wrong order
You can specify the host name of both the active OA and standby OA to add a member.
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
14 Instant Capacity support for HP Integrity Superdome 2 with dynamic cores release notes