HP Virtual Server Environment Management for Integrity Version 4.0 Release Notes

• Only One SRD is Allowed to be Deployed You might see a message similar to the following:
Error trying to deploy SRD, mysystem.vpar.000 to
mysystem2.mydomain.com. SRD, mysystem2.fss.000 is already deployed.
Only one SRD is allowed to be deployed.
Workaround Undeploy the SRD using the --force option with the gwlm undeploy
command, and restart gwlmagent on the managed node.
• SRD Deployment Times Out and Displays a Blank Screen If you attempt to deploy an SRD,
but:
— gWLM times out and displays a blank screen
— There are events from each managed node similar to the following event:
gWLM Agent MySystem.MyDomain.com
Information Unable to manage the following hosts:
Associated Exception Unable to manage the following hosts: MySystem.MyDomain.com: The gWLM agent
process on the host is not running -- start the agent and retry.
You need to configure gWLM to work with hosts on multiple LANs.
Workaround Read the HP Global Workload Manager User's Guide section on Using gWLM
with Hosts on Multiple LANs.
• Application Hangs in fss group On HP-UX 11i v2 (B.11.23), an application inside an fss
group might hang when running in a single-processor virtual partition, nPartition, or system.
Workaround Install patch PHKL_33052.
• Scripts Not Placed in Correct Workloads With compartments based on psets or fss groups,
gWLM allows you to place scripts in the compartments using application records with
alternate names. This works only if the shell or interpreter being used is listed in the file
/etc/shells. Typically, perl is not in this file. So, perl scripts (and any other scripts based
on shells or interpreters not listed in /etc/shells) are not properly placed.
Executables are not affected by this issue.
Workaround Add /opt/perl/bin/perl, and any other needed shells or interpreters,
to the file /etc/shells. Global Workload Manager will recognize the added shells or
interpreters within 30 seconds.
NOTE: Because the full pathname is not required for the script, a rogue user could get
access to compartments based on psets or fss groups — that would otherwise not be accessible
— by using the name of the script for new scripts or wrappers.
• Processes Moved to Default pset or Default fss Group All process placement with the
gwlmplace command on a managed node is lost if:
— The managed node is rebooted.
— The local gwlmagent daemon is restarted.
— You undeploy the current SRD.
In these cases, processes are placed according to any application records or user records that
apply. If no records exist, nonroot processes are placed in the default pset or default fss
group; root processes are left where they are.
Workaround To maintain the process placements across redeploys, use gWLM's application
records or user records when creating or editing your workload definitions in gWLM.
• 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
Global Workload Manager 49