HP Global Workload Manager 7.3 and 7.3 Update 1 User Guide

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.
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 the
placement rules, which are explained in the online help topic "pset / fss group tips" in the section
"Precedence of placement techniques."
If you use the psrset command to place processes in psets, gWLM is likely to move the processes
to the default pset.
Workaround
To maintain the placement of a process, use gWLM's application records or user records when
creating or editing your workload definitions in gWLM. If using records is not practical, use the
gwlmplace command. However, you will have to use gwlmplace after each redeploy of an
SRD to put the processes back in the desired workloads.
60 Global Workload Manager known issues