Manually Adjusting CPU Resources

When an SRD is created, it has a certain number of cores. gWLM manages the SRD using the same number of cores. If the SRD—or a policy used in the SRD—is configured to use Temporary Instant Capacity (TiCAP), gWLM can automatically activate that additional capacity to meet policies. If neither the SRD or its policies are configured to use TiCAP, you may be able to temporarily provide additional resources to a deployed SRD by:

	NOTE: If gWLM detects activated cores for which there is no request, it deactivates them to avoid spending money on the unneeded capacity.After you manually change system resources (by modifying unmanaged partitions or changing bindings, for example), you might see resize errors on one or more of the managed nodes. However, gWLM should recover (and stop issuing errors) by the next resource allocation interval—unless gWLM can no longer access the required resources. Deployed SRDs do not accept manual decreases in the available resources. gWLM will attempt to reclaim any removed resources.Although a deployed SRD might recognize added resources, policy maximum values are still in effect and can clip resource requests. Consider adjusting policy settings to use the added resources.

As already mentioned, gWLM can take advantage of the additional CPU resources only temporarily. To take full, persistent advantage of the extra resources using the gWLM interface in HP SIM:

To take full, persistent advantage of the extra resources using the gWLM command-line interface:

gWLM cannot take advantage—even temporarily—of resources added by:

To make use of these additional resources using the gWLM command-line interface:

To make use of these additional resources using the gWLM interface in HP SIM, follow the procedure given for that interface above.

	NOTE: NOTE: After manually adjusting the number of cores in an SRD, always confirm the changes after two gWLM resource allocation intervals have passed. Changes may not be as expected due to gWLM behaviors such as the ones described below. In an SRD with nested partitions, gWLM samples the inner partitions for their sizes before sampling the outer partitions. Adjusting resources between these samplings can cause gWLM to report incorrect sizes. If you encounter this issue, try making your adjustment again. In an SRD with nested partitions that includes vpars, assume you manually add cores from an unmanaged vpar. If you later remove those cores—without returning them to an unmanaged vpar before gWLM samples compartment sizes—those cores are deactivated.