Using HP Integrity Essentials Global Workload Manager 3.0.1 with Global Instant Capacity 8.02.01

4
The interval provided by gWLM is nominal, typically providing only twice the time of a typical
implementation of a reallocation plan. When using GiCAP, several factors can require your
increasing the allocation interval. These factors are:
• More time needed for icapmodify operations in GiCAP groups
Any gWLM SRD that includes workloads from multiple nPartitions or which allows use of TiCAP will
make use of iCAP software commands to activate (icapmodify -t -a) and de-activate
(icapmodify -d) CPU resources in the nPartitions. Under some conditions, these commands may
take longer to execute when applied to partitions that are in a GiCAP group.
• Automated, conflicting activation
An increase in execution time can also occur if a usage right is inadvertently taken from a gWLM
managed system. This can occur if an icapmodify -a command is executed on a GiCAP group
member not managed by gWLM in between the time that gWLM issues a de-activation command in
one partition of a complex and an activation command in another partition of the same complex.
The activation command issued by gWLM will result in either the transfer of a usage right to the
activating complex or the activation of a TiCAP core. In either case, the execution time of the
activation command is extended as other members of the GiCAP group are surveyed for available
usage rights. If the only source of icapmodify commands on GiCAP group member complexes
outside a given SRD is manual activation, it is not likely to be a significant source of disruption of
gWLM operation. However, if those complexes are subject to frequent modification, for example by
automated scripting or even gWLM management in multiple complexes that are members of the
same GiCAP group, you should set the resource allocation interval for any SRD that has a managed
compartment that is part of the GiCAP group to take into account the delays.
Changing the Size of an SRD by Transferring Usage Rights
gWLM 3.0.1 always tries to maintain an SRD at the size it had when it was created. As a result,
manually executing icapmodify commands to transfer usage rights into or out of compartments in a
deployed SRD only changes the size of the SRD temporarily. For example, if you de-activate cores in
a partition managed by gWLM and then activate them in an unmanaged partition, gWLM will
attempt to maintain the SRD size by activating usage rights. If usage rights are not available, gWLM
will use any available TiCAP (assuming gWLM is configured to use such resources). In addition to not
being permanent, manual icapmodify commands can produce temporary resource management
errors. As a result, you should avoid using icapmodify on partitions managed by gWLM in a
deployed SRD.
To make permanent changes in the size of an SRD by transferring usage rights from other members of
a GiCAP group:
1. Undeploy the SRD
2. Transfer the usage rights to increase or decrease the size of the SRD
Increase the SRD size by de-activating usage rights (icapmodify -d) on GiCAP group members
outside the SRD and then activating those usage rights (icapmodify -a) on GiCAP group
members that are in the SRD.
Decrease the SRD size by de-activating usage rights (icapmodify -d) on GiCAP group
members that are in the SRD and then activating those usage rights (icapmodify -a) on GiCAP
group members outside the SRD.
3. Re-create the SRD and deploy it