HP Global Workload Manager 7.0 User Guide

Workaround
Remove old historical monitoring and configuration data from the gWLM database by entering
the following command:
# gwlm history --truncate --truncate=<CCYY/MM/DD>
If you prefer not to trim the database, you can delete multiple workloads simultaneously using the
gwlm delete command.
For more information, see gwlm(1M).
Integrity VM prevents discovery of psets and fss groups
When the gWLM agent is installed on a system that has Integrity VM installed, discovery operations
report only Integrity VM compartments even if psets and fss groups are present.
Workaround
To discover psets or fss groups on the system, you must remove Integrity VM.
Only workloads with managed siblings can be added to SRDs with nested partitions
Using the gWLM command-line interface, you cannot add a workload to an SRD that has nested
partitions unless a sibling of that workload is already managed in that SRD.
Workaround
This is not an issue when you use the gWLM interface in System Insight Manager. Simply follow
the instructions in Step 1 of the Manage Systems and Workloads wizard (reached by selecting
CreateShared Resource Domain), and select the set of hosts to include in a single SRD.
Configurations with Psets nested in virtual partitions rejected with vPars versions
earlier than vPars A.03.05
gWLM does not support nesting psets in virtual partitions when the vPars version is earlier than
vPars A.03.05. However, it has not always rejected such configurations. gWLM 4.0 and later
does reject these configurations though. So, configurations you used with gWLM 2.x or gWLM
3.x can be rejected when you begin using gWLM 4.0 (and later) agents. Given such a
configuration, if the SRD is undeployed before upgrading the agents, the re-deployment of the SRD
will fail with an error message. If the SRD was left deployed while the agents were upgraded, the
agents will not be able to restore SRD operations. Also, System Insight Manager events will be
generated to report the validation failure.
Workaround
There are two workarounds:
Update to vPars A.04.00 or later.
Update your configurations so that psets are not nested in virtual partitions.
Information error during shutdown
You might see a message similar to the following:
Information Error during shutdown. The unbinding of objects in the
registry might have failed, and the workload management lock has not
been released. Associated Exception
com.hp.gwlm.common.JniPlatformException: prm_ctrl_rel_cfg_lock failed
because vm_fssagt:8343 is the lock owner
Workaround
You can safely ignore this message.
Managing fss groups on systems with psets restricts fss groups
When a system has psets, gWLM uses only pset 0 for fss groups. gWLM is able to manage CPUs
that are allocated only to pset 0.
Limitations 51