HP Instant Capacity Release Notes for Version 9.x

GiCAP Known Problems (HP-UX)
Network-related problems when re-adding members to groups
Some users upgrading to iCAP Version 9 have encountered messages like the following, when
re-adding existing members to a GiCAP group:
icapmanage -a -g Group1 -m xyzmember:abc.hp.com,def.hp.com,ghi.hp.com
icapmanage command failed.
Attempt to re-add xyzmember to Group1 failed due to a match in the list of OSAddresses.
This error means that one or more of the hosts listed in the icapmanage -a -g -m command
may not resolve to the same name as it previously did when the member was first added to the
group. Specifically, in the reported cases it meant that the name lookup for one of the hosts had
changed from a fully qualified host name (abc.hp.com) to being a simple host name (abc).
GiCAP does not match abc with abc.hp.com and therefore, reports this as a mismatch.
If this error occurs, you should execute the nslookup command for each specified host of the
member complex and make sure that each host name is qualified in exactly the same way that
icapmanage -s reports that particular host name for the member. Typically, this problem can
occur if the /etc/hosts file is being used for network name lookups, and the file was changed
to return simple host names when it previously returned fully qualified host names. In this case,
the problem can be fixed by editing the /etc/hosts file.
Partial complex failure with rights seizure
The V9.0 User's Guide and manpages do not properly describe the following condition that can
occur when rights are seized from a server where at least one other nPartition of the complex is
still running.
Rights seized in this situation do not expire.
However, if the system is not rebooted within 12 to 24 hours of the rights seizure, the Instant
Capacity software in the still-running partition(s) takes note that the iCAP daemon has not been
running in the failed partition for a significant period of time. The software assumes that the
failed partition might be booted to an operating system that is unaware of iCAP will use all cores
on the partition. This is referred to as the assumed active state and can result in temporary capacity
charges or compliance exceptions. To avoid this, cells can be made inactive by removing them
from the partition, shutting down the partition from within the operating system using shutdown
-R -H, or with the MP RR command.
However, even if the cells are made inactive, the Instant Capacity software reserves usage rights
to minimize the possibility that the complex is taken out of compliance if the partition is booted
with all cores active. Unique considerations apply to this assumed reserved state. In this state,
additional activations may not be allowed unless temporary capacity is authorized on the
activation.
Use one of the following methods to allow continued resource migrations after the iCAP daemon
puts the complex in the assumed reserved state:
• Reboot the failed partition, if possible.
• Delete the failed partition.
• Reduce the number of cores considered active at the next boot by setting the UONB (Use
on Next Boot) value to false for one or more of the cells in the failed partition, or by removing
one or more cells from the partition. Note, powering off the cells does not change the assumed
reserved state.
• Authorize the use of temporary capacity on requested activations (using the -t option).
This allows the reserved usage rights across the complex to exceed the number of actual
usage rights. Temporary capacity is charged only if the number of active cores exceeds the
number of actual usage rights. If the failed partition remains inactive and the number of
active cores does not exceed the count of actual usage rights, temporary capacity is not
charged. You must be careful with this method. A reboot of the failed partition activates at
Known Problems 27