Global Workload Manager

Unpredictable Management when Removing GiCAP Group Members  If you have removed hosts from a GiCAP group before removing them from an SRD, management of the SRD becomes unpredictable. You may not be able to modify the SRD or perform a normal undeploy, in which case you must force an undeploy, delete the SRD, and re-create it.

To correct this problem, unmanage any group members before removing them from the GiCAP group.

System Error 1067  If you receive the following message when installing:

     Initial configuration completed with warnings.  

     System error 1067.  

To correct this problem, create one database instance for each CMS.

Localization Behaviors   Starting with the 4.0 release, gWLM has been localized into several languages. However:

Unable to Manage Partitions with Inactive Cells or Deconfigured Cores  gWLM does not support management of partitions with either inactive cells or deconfigured cores. (gWLM may incorrectly try to allocate and assign those unavailable resources.)

To correct this problem,create one database instance for each CMS. configure the cores and activate the cells.

Unable to Build a Single Shared Resource Domai   The following message might be displayed in the HP SIM interface to gWLM:

Unable to build a single shared resource domain from the set of specified hosts: myhostA.mydomain.com myhostB.mydomain.com

This message indicates that there are no supported resource-sharing mechanisms available between the specified hosts. The message can occur if:

If you receive this message:

gWLM's Secure Communications Requires Perl  To secure communications on a gWLM managed node, /opt/perl/bin/perl (version D.5.8.0.D or later) must be on the system.

Compatibility with HP Integrity Virtual Machines  Global Workload Manager version 4.1 only supports HP Integrity Virtual Machines A.03.00 or later. If you want to manage virtual machines using gWLM version 4.1, you must upgrade to HP Integrity Virtual Machines version 3.0 or later. HP recommends that you upgrade to HP Integrity Virtual Machines version 3.5 or later.

Upgrade to HP Integrity Virtual Machines version A.03.00 or later if possible.

If you cannot upgrade from HP Integrity Virtual Machines version A.02.00, either install gWLM agent version A.02.50.00 or use gWLM version 4.0 to manage only virtual machines with entitlements specified in percentages. (That is, do not manage virtual machines with entitlements specified in CPU cycles.)

To obtain older versions of the gWLM agent, and for assistance with this configuration, contact HP at the following email address: gwlmfeedback@rsn.hp.com.

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

Compatibility with Global Instant Capacity  gWLM 4.1 is compatible with GiCAP in iCAP versions 8.02, 8.03 and 9.01.

For information on restrictions when using gWLM with Global Instant Capacity, visit http://docs.hp.com/en/vse.html and locate the white paper Using Global Workload Manager with Global Instant Capacity.

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

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 may potentially run. However, management of such a workload may 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.

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.

Host Name Aliases Are Not Supported   Host name aliases are not supported by gWLM. Only canonical DNS host names (fully qualified domain names) are supported.

Use only canonical DNS names when configuring gWLM through either HP SIM or an XML file used with the gwlm command.

Making a Configuration Change to a Large SRD is Slow   Changes made to the configuration of a large SRD that is deployed might take a long time (several minutes) to take effect.

There is no workaround. The amount of time needed to complete a change depends on the time it takes to communicate with all the compartments in the SRD.

Events for gWLM CPU Migration Can Affect HP SIM CMS Performance   The HP products System Fault Management (SFM) and Event Monitoring Service (EMS hardware monitors in particular) generate events, or indications, when CPUs are migrated. Depending on workload characteristics, gWLM can migrate CPUs rapidly. Over time, this frequent migration can result in a high enough number of events that the performance of the HP SIM CMS is adversely affected.

The following options are available as workarounds:

For more information about any of these workarounds, see the HP SIM documentation (available from http://www.hp.com/go/hpsim).

Deleting Workloads Takes a Long Time   Once a request to delete a workload is issued, it can take a long time (several minutes) to complete the deletion.

Remove old historical monitoring and configuration data from the gWLM database by entering the following command:

# gwlm history --truncate --truncate=<CCYY/MM/DD>

If you prefer not to trim the database, you can delete multiple workloads simultaneously using the gwlm delete command.

For more information, see gwlm(1M).

Integrity VM Prevents Discovery of psets and fss Groups   When the gWLM agent is installed on a system that has Integrity VM installed, discovery operations report only Integrity VM compartments even if psets and fss groups are present.

To discover psets or fss groups on the system, must remove Integrity VM.

Only Workloads with Managed Siblings Can be Added to SRDs with Nested Partitions   Using the gWLM command-line interface, you cannot add a workload to an SRD that has nested partitions unless a sibling of that workload is already managed in that SRD.

This is not an issue when you use the gWLM interface in HP SIM. Simply follow the instructions in Step 1 of the Manage Systems and Workloads wizard (reached by selecting CreateShared Resource Domain), and select the set of hosts to include in a single SRD.

Configurations with Psets Nested in Virtual Partitions Rejected with vPars Versions Earlier than vPars A.03.05   gWLM does not support nesting psets in virtual partitions when the vPars version is earlier than vPars A.03.05. However, it has not always rejected such configurations. gWLM 4.0 and later 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 and higher 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.

There are two workarounds:

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

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.

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

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 attempts to detect and report network configuration issues that can cause undesirable behavior, but in some cases this detection occurs in a context that can be reported only into a log file.

If you encounter some unexpected behavior (such as a gWLM agent that fails to update or report the status of its workloads), inspect the /var/opt/gwlm/glwmagent.log.0 file on the host for errors.

Incorrectly Configured Host Name or IP Address  You may see the following message in a log file (gwlmagent.log.0 or gwlmcmsd.log.0):

Unable to determine the network address and/or hostname
of the current host. This indicates a mis-configured network and/or a host
name resolution issue for this host. For troubleshooting information, see the
VSE Management Software Release Notes and search for this message. 

The most common cause for this error is a problem in the host name configuration file in /etc/hosts (or equivalent on Windows) or incorrect settings of the /etc/nsswitch.conf file (HP-UX only).

Background information  gWLM is not a simple client/server application. It involves:

Under normal operation, all of these components need complete connectivity. At a minimum, gWLM requires that each host have a primary IP address/host name that is reachable from every other interacting gWLM component--the CMS and all gWLM agents in a single SRD. (gWLM agents in multiple SRDs need not have connectivity within undeployed SRDs.)

By default, gWLM uses the primary IP address/host name for a given host. However, you can set up a management LAN, as discussed in the HP Global Workload Manager User's Guide, to use other IP addresses/host names.

To resolve this problem, correct the configuration of the host so that:

The procedure below explores one way to check the host's configuration.

Fix any issues by editing /etc/hosts or for additional information, see:

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.

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.

Instant Capacity B.11.*.08.03.00.* Incompatible with gWLM  Instant Capacity version B.11.11.08.03.00.* (for HP-UX 11i v1), Instant Capacity version B.11.23.08.03.00.* (for HP-UX 11i v2) and Instant Capacity version B.11.31.08.03.00.* (for HP-UX 11i v3) are not compatible with gWLM.

Upgrade the gWLM-managed system to Instant Capacity version B.11.*.08.03.01.*.

Installing a Newer gWLM Agent on an Older CMS Makes System Unsupported   You can install a newer gWLM agent on a CMS using an earlier version of gWLM. For example, you can install the A.04.00.07 agent on a system with CMS version A.02.00.00.x. This configuration is invalid and leaves the VSE Management CMS software unusable. Starting with gWLM A.04.00.07, the CMS software validates that the agent software version is within the past two major releases and does not exceed the current release.

Update the CMS version. This update also installs the corresponding agent. (Because gWLM requires all managed nodes in an SRD to have the same agent version, you must update the agents on any other managed nodes that could be in an SRD that includes the CMS. For information about performing this update, see the HP VSE Management Software Version 4.1 Installation and Update Guide for HP-UX.

gWLM Fails to Start with Certain Time Zone Settings  gwlmcmsd and gwlmagent can fail to start with certain time zone settings. The following message is displayed in the gwlmagent.log.0 file or the gwlmcmsd.log.0 file when you attempt to invoke either daemon:

Unable to call method, 'main', with signature, 
'([Ljava/lang/String;)V', in class, 'com/hp/gwlm/node/Node'.
Exception in thread "main"

To correct this problem, use Java 1.5.0.12 or later.

Unable to Create New Native Thread   A message containing the following text might be displayed:

... unable to create new native thread

This problem occurs because the following kernel parameters are set too low:

Multiple Time Changes on CMS May Render gWLM Unusable  If the time on the CMS is changed to a point in the future, changes to the gWLM configuration are made and time on the CMS is moved back to the present; gWLM will not recognize any new changes as the latest configuration.

Backup the CMS before performing any changes to time on the CMS system.

Cell-Local Processors and iCAP Environment   Using cell-local processors with virtual partitions inside an nPartition that uses (iCAP) leads to failure of the icod_modify command.

Do not assign CPUs using cell specifications. Consider assigning CPUs to the virtual partitions using a hardware path.

Alternatively, to use cell-local processors, update to vPars A.04.04 on HP-UX 11i v2 (B.11.23) or to vPars A.05.01 on HP-UX 11i v3 (B.11.31).

CMS is Slow to Respond   The CMS is slow to respond.

To correct this problem, time a gwlm list command on the CMS. If it takes more than 10 seconds, perform the following steps:

Combining psets and Virtual Partitions   When using psets on virtual partitions, assigning CPUs to virtual partitions by either path or cell specification can result in processes losing their processor set affiliations when CPUs are removed.

Two workarounds are available:

Error During Discovery of Compartments   The following message might be displayed when you use the Manage New Systems wizard or the gwlm discover command:

Error during discovery of compartments.

In addition, the /var/opt/gwlm/gwlmagent.log.0 file contains the following message:

com.hp.gwlm.common.PlatformException: /usr/sbin/parstatus -w exited with a non-zero exit status. Captured stderr is: Error: Unable to get the local partition number.

This is most likely due to having an outdated version of the nPartition Provider software. Global Workload Manager uses a command that is made available by the nPartition Provider, which is typically in every version of HP-UX, to determine system capabilities.

You can also use the /opt/vse/bin/vseassist command to diagnose the issue.

Install the latest nPartition software, even if you are not using nPartitions.

For HP-UX 11i v1, use version B.11.11.01.03.01.01 or later.

For HP-UX 11i v2 on HP 9000 servers, use version B.11.23.01.03.01.01 or later.

For HP-UX 11i v2 on HP Integrity servers, use version B.11.23.01.04 or later.

You can find the nPartition Provider at the following locations:

Modifying Java While gWLM is Running  gWLM does not support any actions (including the use of update-ux) that remove, overwrite, or otherwise modify the version of Java that gWLM is using in a managed node or CMS that is part of a deployed SRD.

Undeploy an SRD before taking any actions that affect the version of Java that gWLM is using on systems that are part of the SRD. If you used update-ux, be sure to:

Missing or Unexpected Historical Data (System Clocks Differ)   You might have no historical data available for graphing, even though you are certain an SRD was deployed for the time period in question.

A related issue occurs when you select a time period where you expect high system activity, but the graph shows limited activity. Similarly, you might expect very little activity for a time period, but the graph shows lots of activity.

Check that the system clocks on the CMS and on all the systems in the SRD are synchronized. If the clocks differ significantly, gWLM might not be able to match the data from the managed nodes with the time period you are trying to graph.

Workload with Fixed Policy Gets More Resources Than Requested   In an SRD with nested partitions, assigning fixed policies where the sum of the fixed values is less than the minimum of the parent compartment can result in workloads getting more resources than specified in the fixed policies.

Set up the fixed policies so that the number of CPUs requested is greater than or equal to the minimum number of CPUs required by the parent compartment.

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.

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:

You need to configure gWLM to work with hosts on multiple LANs.

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.

To correct this problem, 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.

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:

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.

To maintain the process placements across redeploys, use gWLM's application records or user records when creating or editing your workload definitions in gWLM.

Sizes/Allocations Less Than Policy Minimums for Virtual Machines   The sizes or allocations for virtual machines in a deployed SRD can appear to be less than their policy minimums.

Wait a few minutes, since it can take several minutes for gWLM to recognize a virtual machine transition between the states of off and on.