HP Matrix Operating Environment Software - Manual (Page 60)

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 HP SIM. Simply follow
the instructions in Step 1 of the Manage Systems and Workloads wizard (reached by selecting
Create
→Shared 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, SIM 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.
Workaround
There is no workaround; this is simply how fss groups are implemented on a
system with psets. You can continue with your fss groups inside pset 0 (leaving the other psets
unmanaged), manage using psets instead (ignoring fss groups), or remove all the psets (other
than pset 0) using the following command:
# psrset -d all
Custom metrics lost on redeploy
Custom policies use metric values that you provide via the gwlmsend command. If you redeploy
an SRD that has a custom policy, the most recent value for the policy's metric is lost. In this
situation, gWLM bases its allocations on the minimum request specified in the workload's policy.
The workload can also receive any CPU resources that remain after all the policies have been
satisfied.
Workaround
Update the metric values for all your custom policies immediately after a redeploy.
Process placement using psrset is ignored
When gWLM is managing the psets on a system, every process on the system has to go in a
workload. gWLM places the processes according to application records or user records specified
when you create or edit a workload definition. If no records exist, the processes are subject to
60 Global Workload Manager A.6.0.0.* Known issues