Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
 HP VSE Management Software 4.1 Update 1 Release Notes for HP-UX > Chapter 3 Known Issues

Global Workload Manager
» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Index

spacerspacerspacer
spacer
spacer
  		 
 

For additional information not included in the online help and documentation for Global Workload Manager, see VSE Management Software 4.1 Update 1 Documentation Addendum.

Limitations

The following are limitations for Global Workload Manager.

Exception upon Modification of SRD after Securing gWLM Communications

A “NullPointerException” might be received upon modifying an already-deployed SRD after securing gWLM communications.

Workaround  Reattempt the modification.

iCAP Compliance Warning

gWLM may give the following warning:

  Warning: gwlmagent cimserver error, icapd down, or icap out of
  compliance. First restart cimserver. Make sure icapd is running. If
  this error happens again, consult gwlmagent man page for steps to
  return to compliance.

Workaround  Verify that no partition changes (parmodify) are pending. If partition changes are pending, please restart the system. Then either consult iCAP documentation or contact HP to return the iCAP system back to compliance.

Upgrade of Partition-Based SRDs Requires Rediscovery

If you are using gWLM and you have either of the following types of partition-based SRDs, and you have upgraded the gWLM agents in the partitions from gWLM A.01.x to gWLM 4.1, you cannot add other partitions in the same complex to the SRD:

  • A vPars-based SRD inside an nPartition

  • An nPartition-based SRD using iCAP

Workaround   Use the following procedure on the CMS to reestablish the SRD:

  1. With the SRD deployed, rediscover the SRD. For a vPars-based SRD, enter the following command: 

    # gwlm discover --type=vpar \
 --file=/tmp/myfile.xml hosts

    For an nPartition-based SRD, enter the following command: 

    # gwlm discover --type=npar \
 --file=/tmp/myfile.xml hosts

    In these commands, replace hosts with a space-separated list of the partitions in the SRD.

  2. Make the following adjustments to the /tmp/myfile.xml file, as explained in gwlmxml(4):

    • Ensure that the mode attribute for the sharedResourceDomain element is set to the desired value (Managed or Advisory): 

      mode="Managed"

    • Ensure that the interval attribute for the sharedResourceDomain element is set to the desired value: 

      interval="x"

    • Ensure that the ticapMode attribute for the sharedResourceDomain element is set to all if you want gWLM to allocate TiCAP when needed: 

      ticapMode="all"

    • Ensure that the workloadReference entries in the compartment definitions are correct, and adjust the names in the workload definitions themselves. For example, you might have host.OTHER.2 instead of host.OTHER.

  3. Import the file to re-create the SRD: 

    # gwlm import --file=/tmp/myfile.xml --clobber

    Because the SRD was already deployed, the new SRD definition is deployed on import, taking the place of the original SRD.

Known Incompatibility with OVPA dsilog v4.7

Inability to extract data using gwlmreport OVPA feature with OVPA version v4.7.

Workaround  Use another version of OVPA.

Constant Use of TiCAP

Global Workload Manager can activate TiCAP if needed to satisfy SRD policies. To avoid unnecessary consumption of TiCAP, you must have a sufficient number of CPUs with permanent licenses available. If your SRD is larger than this amount, TiCAP is consumed to meet the needs of the SRD.

Workaround   Deactivate TiCAP resources prior to creating an SRD. Any TiCAP resources that are active at this time are included in the SRD and, therefore, are consumed whenever the SRD is deployed.

Real-Time Data is Currently Loading

You might see the following message when trying to view real-time reports:

Real-time data is currently loading, please wait... You might also verify that the remote node is running and SRDs have been deployed.

Workaround   Normally, this condition is only temporary. If it persists, check that the gwlmagent daemon is running on the remote nodes. If it is running, stop and restart it. If the condition still persists, undeploy and redeploy the SRD.

Major Issues

The following is a major issue for Global Workload Manager.

Global Workload Manager Attempts to Allocate Cores Assigned to vPars not Managed by gWLM

In limited cases, gWLM might attempt to allocate cores assigned to virtual partitions that are not managed by gWLM on a fully owned system.

Workaround  VSE 4.1 Update 1 resolves this issue by ensuring that gWLM allocates only cores assigned to partitions managed by gWLM. (An alternate workaround is to manage all virtual partitions on an nPartition in the same shared resource domain.) See “Downloading HP-UX Agent Updates” for instructions.

Minor Issues

The following are minor issues for Global Workload Manager.

  • gWLM Leaves TiCAP on When Moving SRD to Advisory Mode  gWLM will leave iCAP cores activated with TiCAP on if the mode for an SRD is changed from “managed” to “advisory.”

    Workaround  Turn TiCAP management of the SRD and any policies associated with the workload off before changing the SRD to “advisory” mode.

  • Starting Management of Monitored Workloads with pset Compartments   If you attempt to manage a set of monitored workloads by applying a policy and managing them with pset compartments, you may get the following error: 

    The value '0' specified for 'Total Size' must be a positive integer value.

    when attempting to complete the Workload & Policies step of the Manage Systems & Workloads Wizard.

    This message is displayed when you attempt to manage a set of pset compartments that require more cores than are available on the managed node. A pset has a minimum size of one core, so you need at least as many cores as workloads you are attempting to manage. The Total Size field cannot be calculated when there are not enough resources on the system to manage the set of monitored workloads in pset compartments.

    Workaround   You can manage the workloads using compartments based on fss groups (which have a smaller minimum size) or add resources to the partition or SRD to enable the pset minimum size requirements to be met.

  • Unable to Remove Workload from Nested Partitions SRD   When attempting to remove the last (default) fss group from an SRD with nested partitions, you might encounter a message that includes the following text:

    Unable to remove workload workload_name: Attempting to remove a compartment with an unachievably low Fixed policy size. Increase the Fixed policy resource amount and try again.

    Workaround   Undeploy the SRD and delete it. Then create a new SRD without the fss group that you were trying to remove.

  • 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.

  • Configuration of Agent and CMS Not Synchronized   Occasionally, a gWLM agent and the gWLM CMS disagree on whether an SRD is actually deployed. This can occur when you use Ctrl-C to interrupt a gwlm deploy or undeploy command. It can also occur if there are errors saving a gWLM configuration: the configuration is deployed and then saved to the gWLM configuration repository. If the deploy occurs but the save fails, the gWLM agent sees the SRD as deployed while the CMS sees it as undeployed.

    Workaround   Use the --force option with gwlm deploy or gwlm undeploy to synchronize the agent and the CMS.

    For example, run the following command to force both the agent and the CMS to consider the SRD as deployed, substituting the name of your SRD for SRD: 

    # gwlm deploy --srd=SRD --force

    For more information about the gwlm command, see gwlm(1M).

    The agents should be restarted to clear their configuration. Following steps should be performed on all agents.

    # gwlmagent --stop
# rm /etc/opt/gwlm/deployed.config
# rm /var/opt/gwlm/RPmap  (If it exists.)
# gwlmagent

  • Missing Historical Data (gWLM CMS Daemon/Service Restarted)  You may have blank sections of a historic report for a workload, or you may see the following error message when displaying historic data for a workload: 

    There is no gWLM historical data for the workload MyWorkload.wkld. The
workload has never been managed by gWLM, or the historical data has been
removed.

    Because of caching of gWLM historic data in HP SIM, if the gWLM CMS daemon/service is restarted after initially viewing historic data, the interface incorrectly reports that there is no data available to view or fails to load portions of the data.

    Workaround  

    1. Log out of HP SIM

    2. Log in to HP SIM again

    3. Generate the historic report again

  • Data Missing in Real-time Monitoring   Global Workload Manager might not display monitoring updates for an SRD on the command line or through the graphical interface in HP SIM. This can be caused by attempts to reform an SRD timing out, leaving the SRD in a state where the agent on each of its managed nodes must be restarted. It can also be caused by a managed node being down, having its gwlmagent not running, or being hung.

    If the managed node is down or gwlmagent is not running, you will see the following message:

    The gWLM agent process on the host is not running -- start the agent and retry.

    If the managed node is hung, or the SRD needs all its agents to be restarted, symptoms can include:

    • Output from the gwlm monitor command omitting data for some SRDs

    • The Shared Resource Domain View in HP SIM showing multiple SRDs with the critical error "SRD data is currently stale".

    Workaround   If an SRD does not provide real-time monitoring over a sustained period of time, restart the gWLM agent on each managed node in the SRD.

    In the case of a hung SRD member, while real-time monitoring of that SRD is blocked, the other SRDs continue to manage resources. However, the real-time monitoring of other SRDs may be blocked due to the hung SRD member. To restore monitoring of the other SRDs:

    1. Undeploy the SRD containing the hung member. This may required using the --force option to the gwlm undeploy command.

    2. Restart gwlmcmsd to clear the blocked monitoring, using the following commands on the CMS: 

       # gwlmcmsd --stop
 # gwlmcmsd

    3. Create a new SRD to replace the undeployed one, leaving out the hung SRD member.

    4. Once the hung SRD member has been restored to normal operation, undeploy the replacement SRD and re-deploy the original SRD to return to the original state.

  • Error Using The Secure gWLM Communications Tool  When using the Secure gWLM Communications tool in the HP SIM interface to gWLM, you may get the following error messages: 

    ERROR: gwlmimportkey failed to import key for
hostname-certificate-file on hostname: keytool error: 
java.lang.Exception:
Input not an X.509 certificate
unable to correctly import the server key

ERROR: Task 'Secure gWLM Communications' terminating.

    This message is displayed when a communications certificate file hostname-certificate-file has been corrupted or is not valid.

    Workaround  

    1. Delete the hostname-certificate-file specified in the error message from the following location on the CMS:

      • HP-UX:

        /etc/opt/gwlm/certs/hostname-certificate-file

      • Windows:

        C:\Program Files\HP\Virtual Server Environment\conf\certs\hostname-certificate-file (although a different path may have been selected at installation)

    2. Run the Secure gWLM Communications tool again.

  • Unable to Remove Abandoned fss Groups   fss groups created by gWLM can become abandoned and cannot be easily removed. This situation can occur for various reasons. For example, when managing an SRD based on fss groups, a second CMS is used — perhaps because the original CMS went down. This can leave the SRD with fss groups that you cannot remove.

    Workaround  Using the HP SIM interface, you can create a new SRD that automatically integrates the existing fss groups.

    Alternatively, you can remove the fss groups, in which case you have several options. If you have PRM installed, enter the following command: 

    # /opt/prm/bin/prmconfig -r

    If you do not have PRM installed, use the following procedure:

    1. Run discovery: 

      # /opt/gwlm/bin/gwlm discover host --file=myfile.xml \
 --type=fss

      where host is the system with the fss groups.

    2. Import myfile.xml into the configuration repository: 

      # /opt/gwlm/bin/gwlm import --file=myfile.xml

    3. Determine the SRD name by running the following command and checking the output for names that include host: 

      # /opt/gwlm/bin/gwlm list

      For example, the name might be host.fss.xyz, where xyz are numbers 0-9.

    4. Deploy the SRD: 

      # /opt/gwlm/bin/gwlm deploy --srd=host.fss.xyz

    5. Undeploy the SRD: 

      # /opt/gwlm/bin/gwlm undeploy --srd=host.fss.xyz

      The fss groups should now be gone from the system. However, their workload definitions are still in the gWLM configuration repository. You can remove those definitions and the SRD definition by using the gWLM interface in HP SIM. Select Tools->VSE Management, then click the Shared Resource Domain tab. Select the SRD with the fss groups, and then select Delete->Shared Resource Domain.

  • Negative Current Size for NONVM   If the CPUs on a VM Host are oversubscribed when you deploy an SRD on that host, gWLM shows current size for NONVM as a negative value.

    Workaround   Two options are available:

    • Adjust the entitlements of those virtual machines that are on so that the CPUs are not oversubscribed.

    • Stop one or more virtual machines until those still on do not oversubscribe the CPUs.

  • Unmanaging a Virtual Machine That Is On Leaves SRD Undeployed   When attempting to unmanage a virtual machine that is started, the SRD can be undeployed, even though the following message is displayed:

    The virtual machine VM_name on host hostname is on but does not have an associated gWLM policy. Please turn the virtual machine off, or apply a gWLM policy to provide the necessary resources.

    Workaround   Turn off the virtual machine and redeploy the SRD that contained it.

  • Advanced Reports Cannot Process Workloads with Spaces at Start/End of Name  Starting with gWLM A.03.00.00, workload names could contain spaces. However, the gwlmreport utility, which generates advanced reports, cannot process workload names that start or end with spaces.

    Workaround  Rename your workloads to not start or end with spaces.

  • gwlmreport ovpafeed --dataversion Problems  Running either of the following commands:

    • gwlmreport ovpafeed

    • gwlmreport ovpafeed --dataversion=4.0

    results in an error.

    Workaround  Use the following commands to set up the feed and extract data:

    • gwlmreport ovpafeed --setup --dataversion=3.0

    • gwlmreport ovpafeed --dataversion=3.0

  • Error When Securing Communications   You may see a message similar to the following one when attempting to secure gWLM communications: 

    	keytool error: java.lang.Exception: Key password must be at least 6 characters
	unable to create keystore /etc/opt/gwlm/certstor/gwlm.keystore
	unable to create the gwlm keystore at /opt/gwlm/bin/gwlmsslconfig line 184.

    Workaround   Try securing communications again.



Capacity Advisor
  		 


HP Integrity VM Manager  
Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 2007–2009 Hewlett-Packard Development Company, L.P.