HP Global Workload Manager 7.0 User Guide

Workaround
This message indicates that there are no supported resource-sharing mechanisms available between
the specified hosts. The message can occur if:
• You have specified hosts in different complexes and the complexes are not managed in the
same GiCAP group.
• You have specified hosts in different nPartitions in a complex when there are no iCAP usage
rights to share between the nPartitions.
• The cimserver (or a provider) on one or more hosts is not functioning properly and consequently
complex or partition IDs are not discovered properly.
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 HP Matrix OE visualization and Capacity Advisor tracking of the workload utilization
Limitations 49