Additional Considerations

Systems which do not have any Instant Capacity components can be part of a GiCAP group. Deactivating resources on these systems allows them to loan usage rights to other members in the group.

Members of a GiCAP group do not have to be located near each other. IP connectivity between the members and the Group Manager, sufficient GiCAP Sharing Rights, and adherence to the GiCAP grouping rules are the only constraints.

The GiCAP software uses the HP-UX Secure Shell product to provide secure communication between the Group Manager and the group members. If SSH is installed after Instant Capacity, a provided script (/etc/opt/iCAP/GiCAP_keygen) must be invoked in order to configure secure communication.

It is recommended that the IP address of the Group Manager not be a dynamic address. The member systems of a GiCAP group store the IP address of the Group Manager and therefore will lose communication with the Group Manager if the IP address changes. If the Group Manager’s IP address changes and it loses communication with the member systems, the Group Manager can remove and re-add the members.

If the GiCAP Group Manager system becomes unavailable, usage rights and temporary capacity remain as per allocated to each group member. Within a server complex, the usage rights can be deployed to other partitions, but movement of usage rights between complexes is unavailable when the Group Manager is unavailable.

On a system with full usage rights, the icapd daemon does not constantly check the system configuration. It can take up to 12 hours for each partition of a system converted from non-iCAP to iCAP to discover that it is now an iCAP system. During this time, icapmanage -s will show asterisks for the new member, and icapstatus on that system will show “Runs iCAP” as “N”. To force a faster conversion, kill and restart the icapd daemon.