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, System Insight Manager 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.

Information error during shutdown

You might see a message similar to the following:

Information Error during shutdown. The unbinding of objects in the registry might 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

Custom metrics lost on redeploy

Custom policies use metric values that you provide via the gwlmsend command. If you redeploy an SRD that has a custom policy, the most recent value for the policy's metric is lost. In this situation, gWLM bases its allocations on the minimum request specified in the workload's policy. The workload can also receive any CPU resources that remain after all the policies have been satisfied.

Workaround

Update the metric values for all your custom policies immediately after a redeploy.

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.

Workaround

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.

Limitations 61

Page 61
Image 61
HP UX 11i Workload Management (gWLM/WLM) Software manual Information error during shutdown, Custom metrics lost on redeploy

UX 11i Workload Management (gWLM/WLM) Software specifications

HP-UX 11i Workload Management (gWLM/WLM) software is an integral component of HP's premier UNIX operating system, designed to enhance system performance and resource management across diverse workloads. This advanced tool allows system administrators to monitor, control, and allocate resources effectively to achieve optimal performance, reliability, and service levels in enterprise environments.

One of the main features of gWLM/WLM is its ability to classify workloads and manage them according to specific policies set by the administrator. By using service level objectives (SLOs), administrators can define the performance criteria for various applications and workloads. gWLM continuously tracks these workloads, ensuring that they adhere to the defined SLOs, thus maintaining a high level of application performance.

The software employs resource pools, which segment resources such as CPU, memory, and I/O bandwidth among different workloads based on predefined priorities. This capability ensures that critical applications receive the resources they require, even during peak usage periods, thereby preventing resource starvation that could lead to system slowdowns or crashes.

Another significant characteristic of gWLM/WLM is its real-time monitoring and reporting capabilities. The software provides detailed insights into resource utilization, workload performance, and system health. Administrators can access this information through a user-friendly interface, allowing for informed decision-making and proactive management.

Integration with HP Serviceguard adds another layer of functionality, enabling high availability for critical applications. gWLM can orchestrate workload migration to ensure that service levels are maintained, even in the event of hardware failures or resource contention.

The technology behind gWLM/WLM is built on advanced algorithms that leverage historical data and predictive modeling to optimize resource allocation dynamically. This means that as workloads change, the system can automatically adjust resource distribution to meet performance targets without the need for constant manual intervention.

gWLM also supports integration with various enterprise management tools, enabling administrators to implement comprehensive monitoring and management strategies across the IT infrastructure. The scalability of gWLM allows organizations of all sizes to benefit from its robust workload management features, ensuring that they can adapt to changing demands in their operational environments.

In summary, HP-UX 11i Workload Management software offers a sophisticated solution for optimizing resource utilization, managing workloads effectively, and maintaining high performance in complex enterprise environments. Its comprehensive features and technologies make it an essential tool for any organization seeking to enhance their IT operations.