HP Virtual Server Environment Management for Integrity Version 4.0 Release Notes

• Configurations with Psets Nested in Virtual Partitions Rejected With vPars version < 4.0
gWLM does not support nesting psets in virtual partitions when the vPars version is
earlier than vPars A.04.00. However, it has not always rejected such configurations. gWLM
4.0 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 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.
• "dangerous REALTIME job" Messages in syslog If you install gWLM A.03.00.00 on a system
with Integrity VM A.02.00 installed, you get messages of the following form in syslog:
vm_fssagt[2461]: dangerous REALTIME job 2686 gwlmagent
In place of gwlmagent, you might see parstatus, HPUXChildWrap, or wbemexec.
Workaround You can safely ignore this message. These processes are not real-time
processes. (If you prefer, you can upgrade to Integrity VM A.03.00, which correctly identifies
these processes and does not produce this message.)
• Information Error During Shutdown You may see a message similar to the following:
Information Error during shutdown. The unbinding of objects in the
registry may 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
• Discovery Does Not Show Current Information for Stopped Virtual Machines Global Workload
Manager discovery does not always report current information for stopped virtual machines.
Specifically, when a virtual machine is stopped and the number of vCPUs is changed, gWLM
discovery does not show the changed number of vCPUs. Instead, it shows the number of
vCPUs from the virtual machine's most recent start.
Workaround Start the virtual machines before performing discovery.
• Multiple Network Interface Cards As a client/server application, gWLM is more sensitive
than other types of applications to the network configuration of your host. It supports
management only within a single network domain. For example, if your CMS host has
multiple network interface cards that are connected to multiple distinct networks, gWLM
requires that the fully qualified host name resolve to the IP address that is reachable by the
gWLM agents to be managed.
This issue is most often a concern when a host is connected to both of the following items:
Global Workload Manager 43