Patches and fixes in this version

wlmcert does not truncate an existing certificate file when a new certificate with the same name is installed

In previous versions of WLM, if a new certificate is installed where an existing certificate of the same name exists, wlmcert fails to truncate the existing certificate file as it should when that file is bigger than the new one. For example, assume the certificate named host1.pem is already installed at the following location:

/var/opt/wlm/certstore/truststore/host1.pem

If you install a new certificate for host1 and the new certificate file host1.pem is shorter than the existing one, wlmcert does not truncate the old file, leaving remnants of the old file in the new file.

This problem has been fixed so that the certificate file is truncated properly.

This fix addresses CR# JAGag04768.

CPU usage might increase significantly when using sg_pkg_active script with Serviceguard 11.16 or earlier

In previous releases of WLM, using the WLM sg_pkg_active script with versions of Serviceguard earlier than 11.17 could result with relatively high CPU usage in complexes that include a high number of Serviceguard packages.

This problem has been fixed.

WLM Temporary Instant Capacity 15-day threshold too limiting

Temporary Instant Capacity (TiCAP) activates capacity in a temporary “calling-card fashion” such as in 30-day increments (where a day equals 24 hours for one core). With Temporary Instant Capacity on the system, any number of Instant Capacity cores can be activated as long as your prepaid temporary capacity time has not expired. With earlier versions of WLM, if fewer than 15 processing days of temporary capacity are available, WLM stops activating Temporary Instant Capacity resources. This threshold can be too limiting for certain environments.

Beginning with this release of WLM, a new global arbiter configuration keyword (utility_reserve_threshold) enables you to increase or decrease this threshold. The default is 15 days. The following example shows the threshold set to 5 days, causing WLM to continue allocating temporary capacity until 5 or fewer days of temporary capacity resources are available:

par { 
           utility_reserve_threshold = 5; 
}

You can set the keyword to 0 to cause WLM to always activate temporary capacity resources as long as any number of temporary capacity resources are available. Note that it is recommended that some quantity of temporary capacity always be kept in reserve. Having a buffer of temporary capacity allows you to avoid delays activating additional cores when a purchase of additional capacity is necessary. For more information, see the HP-UX Workload Manager User’s Guide or wlmparconf(4). For information on additional restrictions involving activation of temporary capacity resources, see the Instant Capacity (iCAP) documentation.

This fix addresses CR# JAGaf97368.

prmmonitor does not display memory “Upper Bound” for WLM groups

In a WLM configuration that includes workload groups for which gminmem, gmaxmem, and memweight are specified, the prmmonitor MEM command fails to display the current PRM memory cap in the “Upper Bound” column. This problem occurs when using prmmonitor to check the memory entitlement and usage for each group.

A new “MB Max” column has been added to the prmmonitor MRG command display, showing the maximum amount of memory available to the group. Because this enhancement is introduced in PRM C.03.02, that version of PRM (or later) must be installed on your system in order to get the new prmmonitor MRG display.

Note that starting with WLM A.03.02, the wlminfo group command has been enhanced to display memory utilization of all groups in the current deployed configuration, and used with the -v option, displays each group’s gmincpu, gmaxcpu, gminmem, and gmaxmem values, if they are available. The new -v option is ignored if live data is not being displayed (for example, when the -o option is being used). If memory management is not being used, a dash (-) instead of a zero is displayed in the ‘Mem Shares’ column. If a group’s gmincpu, gmaxcpu, gminmem, or gmaxmem value is not assigned in the current configuration, a dash (-) is displayed in the corresponding column.

This enhancement addresses CR# JAGaf86413.

If WLM cannot increase a partition’s CPU resources, the wlminfo par command displays the wrong CPU (core) count

If WLM is not able to increase a partition’s CPU resources (number of cores), the wlminfo par command erroneously displays the same value for both the intended and actual core count. For example, if WLM fails to raise the count on a partition from 2 to 3, wlminfo par should display the intended core count as 3 and the actual core count as 2; however, the command displays both the intended and actual count as 3.

The wlminfo par command has been fixed to display the intended and actual core counts correctly.

This fix addresses CR# JAGaf88801.

WLM issues vparstatus failure warnings that can be ignored

If the vparstatus command is used immediately after you use the vparmodify command, the vparstatus command might fail. The failure occurs because the virtual partition database is still locked by the virtual partition monitor. As a result, WLM issues the following warning:

vPar command failures seen while gathering partition status information.

This message can be ignored unless any of the following conditions occur:

Beginning with WLM A.03.02, WLM is less likely to issue the command failure warning, as it now ignores vparstatus failures up until the last vparstatus call during modification of a virtual partition.

This fix addresses CR# JAGaf86468.

wlmpard ignores Temporary Instant Capacity (TiCAP) capacity changes

Starting with WLM A.03.00, when utilitypri is enabled (in the global arbiter configuration file), wlmpard fails to notice temporary capacity changes once all hosts have connected. It only detects changes when a new host connects. As a result, when the amount of reserve capacity falls below the threshold (15 processing days by default, or the number of days specified with the utility_reserve_threshold keyword), wlmpard might continue to activate temporary capacity.

Beginning with WLM A.03.02, wlmpard will detect such changes and stop allocating reserve capacity after the threshold is reached.

This fix addresses CR# JAGag06301.

wlmprmconf might generate invalid configurations

The script for converting PRM configuration files to WLM configuration files, wlmprmconf, might create configurations with invalid syntax when the PRM configuration file involves the PRM_SYS group and secure compartment records. Error messages indicate that unexpected syntax is found in various user and secure compartment statements in the prm structure.

Beginning with WLM A.03.02, wlmprmconf now creates valid WLM configuration files under these circumstances.

This fix addresses CR# JAGag03890.

WLM daemon (wlmd) memory consumption increases continually

Memory use of wlmd might increase over time, especially when PRM API errors are being logged in the WLM message log.

Beginning with WLM A.03.02, this memory leak has been corrected.

This fix addresses CR# JAGag06034.

WLM configuration wizard does not allow primary_host with PSET-based workloads

When using the WLM configuration wizard (wlmcw) to create a configuration that includes PSET-based workloads and specifies the primary_host keyword for partition management, the wizard generates an error message.

As of WLM A.03.01, partition management is supported with configurations that include PSET-based workloads. The configuration wizard has been fixed to allow such configurations.

This fix addresses CR# JAGag07511.