Seeing gWLM in Action

This section helps you see gWLM move CPU resources among vpars. You can use similar steps to see CPU resources move among npars, virtual machines, psets, or fss groups. For psets and fss groups, though, you will need to put processes in the desired pset or fss group. (Place processes by modifying the workload definition or by using the gwlmplace command.) In this example:

The gWLM agent is used on two vpars, named vpar1 and vpar2.
These vpars are idle and have a number of unbound cores that gWLM can move among them.
HP SIM and the gWLM CMS software are installed, configured, and running on a vpar called vpar3.

To see gWLM in action:




	NOTE: You must be logged in as root on the systems where you run the mxstart, gwlmcmsd, and gwlmagent commands mentioned below. In HP SIM, you must be logged in as root or have authorizations for “All Tools” or “VSE All Tools.”

Start the gWLM agent daemons on vpar1 and vpar2:
# vpar1> /opt/gwlm/bin/gwlmagent
# vpar2> /opt/gwlm/bin/gwlmagent
Alternatively, you can start the agents through HP SIM, as discussed in the VSE Management Software Installation and Update Guide.
Connect to HP SIM by pointing your web browser to:
http://hostname:280
where hostname represents the hostname of the CMS, in this case, vpar3.
Create a gWLM SRD containing the two vpars by following the steps given in “Getting Started with gWLM”.
1. For hosts, enter the names of the two vpars separated by a space in the field beneath the table.
2. Ensure when setting the SRD properties that the mode is Managed.
3. Use an OwnBorrow policy for the vpar1 workload and for the vpar2 workload.
  An OwnBorrow policy has a name of the form:
  Owns_4-Max_8
  Ideally, the sum of the cores owned by the workloads will equal the total number of cores in the SRD when using this type of policy. (You may need to edit policies to achieve this equality.)
4. Confirm and finish the SRD creation. (You are then placed on the Shared Resource Domain View, showing the newly created SRD and its workloads.)
Select the vpar1 workload.
View gWLM’s real-time reports to show CPU resource allocation for vpar1 by selecting in the VSE Management menu bar:
ReportgWLM Real-time Reports...
You can also view the reports by clicking the workload’s bar graph.
Click the Policy graph radio button to see a graph of vpar1’s CPU resource allocation.
Start a CPU resource-intensive workload in vpar1.
If you already have such a workload configured in vpar1, start it now.
If you need such a workload, the following command prints its PID (24379 in this case) and then just consumes CPU resources:
# perl -e ’print "$$\n";while (1) {};’ &
[1] 24379
This command consumes most of a single core. Start multiple copies of the command to consume additional cores.
Wait a few minutes, then look at the “Policy Request and Workload Allocation” graph from Step 6 to see how the policy for vpar1’s workload is requesting CPU resource allocations and how gWLM is granting them.
Kill the workloads you started in vpar1.
Set the Workload dropdown near the top of the screen to the vpar2 workload and repeat Step 7 through Step 9 to see gWLM move cores to vpar2.

Seeing gWLM in Action

Technical documentation

» Table of Contents

» Index