HP Insight Global Workload Manager 6.0 Software: User Guide

If you receive this message:
• Inspect the /var/opt/gwlm/gwlmagent.log.0 files on the indicated managed nodes
for error messages.
• If partitions have been renamed, restarting the agents in the complex might correct the
problem.
• If available, inspect the discovery tree for unexpected difference in complex or partition
names. Check the functioning of the parstatus, icapstatus and vparstatus commands
on the hosts which do not have the expected IDs. Restarting the cimserver on those hosts
might correct the problem.
Compatibility with PRM and WLM
You cannot use gWLM with either Process Resource Manager (PRM) or Workload Manager
(WLM) to manage the same system at the same time. Attempts to do so result in a message
indicating that a lock is being held by whichever application is actually managing the system.
To use gWLM in this situation, first turn off the application holding the lock.
For PRM, enter the following commands:
# /opt/prm/bin/prmconfig -d
# /opt/prm/bin/prmconfig -r
For WLM, enter the following command:
# /opt/wlm/bin/wlmd -k
Rare incompatibility with virtual partitions
Depending on workload characteristics, gWLM can migrate CPU resources rapidly. This frequent
migration can potentially, although very rarely, produce a race condition, causing the virtual
partition to crash. It can also produce a panic, resulting in one or more of the following messages:
No Chosen CPU on the cell-cannot proceed with NB PDC.
or
PDC_PAT_EVENT_SET_MODE(2) call returned error
Workaround Upgrading to vPars A.03.04 resolves this issue.
With earlier versions of vPars, you can work around this issue as follows: Assign (using path
assignment) at least one CPU per cell as a bound CPU to at least one virtual partition. (It can be
any virtual partition). This ensures that there is no redesignation on CPU migrations. For example,
if you have four cells (0, 1, 2, 3), each with four CPUs (10, 11, 12, 13) and four virtual partitions
(vpar1, vpar2, vpar3, vpar4), you could assign 0/1x to vpar1, 1/1x to vpar2, 2/1x to vpar3, and
3/1x to vpar4, where x is 0,1,2,3.
Workloads in gWLM do not follow associated Serviceguard packages
With the exception of virtual machines, a workload can be managed by gWLM in only one
deployed SRD at a time. As a result, if a workload is directly associated with a Serviceguard
package (using the selector in the Workload Definition dialog), gWLM can manage it on only
one of the hosts on which it might potentially run. However, management of such a workload
might disrupt the Virtualization Manager and Capacity Advisor tracking of the workload
utilization between cluster members. Thus, it is recommended that you not directly manage a
workload associated with a Serviceguard package.
Workaround For all hosts to which a workload associated with a Serviceguard package might
fail over, you must apply a policy to an enclosing operating system instance (virtual partition or
nPartition). You can use a gWLM conditional policy to change the resource allocation depending
on which packages are present. This enables you to control the resource allocation of the enclosing
operating system instance and still monitor the workload via Virtualization Manager.
58 Global Workload Manager A.6.0.0.* Known issues