z/VM setup

Edit online

All z/VM® virtual machines defined for the various servers are outlined in detail in topic Hardware and software configurations. Besides the z/VM resource allocations, the following additional configuration and tuning was applied.

Virtual Networking

The z/VM guests use a Virtual Switch (VSWITCH) configured LAN for guest-to-guest communication. A 10 GbE OSA-Express3 is connected to the VSWITCH and the guests attached to the VSWITCH reside in the same LAN as the 10GbE OSA Express®. This allows the configuration of guest IP addresses from the same network that is also used by the OSA Express card. As a virtual networking solution, the VSWITCH provides good performance and is the recommended method for internal and external z/VM network connectivity.

For more information about z/VM virtual networking and the VSWITCH refer to:

http://www.vm.ibm.com/virtualnetwork/

HyperPAV

The I/O throughput for DASDs can be improved by using parallel access volumes (PAV) or HyperPAV (see also Linux operation system setup).

For example, database servers are candidates for doing a lot of disk I/O. z/VM is set up to assign HyperPAV aliases directly to the virtual machines.

Control virtual machine CPU capacity

z/VM has the concept of shares to control the percentage of CPU power that a virtual machines receives. The CPU shares can be set with the SET SHARE command and the SHARE directory statement. It comes in two flavors as ABSOLUTE shares and RELATIVE shares.

ABSOLUTE shares allocate an absolute percentage of all available system processors to a virtual machine, and guarantee the availability of a certain percentage of processing time.

RELATIVE shares allocate a portion of the total system processors to a virtual machine, minus those processors allocated to virtual machines with an ABSOLUTE share. The range for relative shares is an integer number from 1 to 10000 (the larger the number, the higher the share). In general, you should assign a relative rather than an absolute share to typical users.

Definition of the fair share setup used for non-VMRM measurements

The default relative share for a virtual machine is 100. A common way to specify relative shares is to align them with the number of assigned virtual CPUs to the virtual machine.

For example, if virtual machines get a relative share of 100 per virtual CPU, a first virtual machine (VM1) gets a relative share of 200 for its two virtual CPUs, and a second virtual machine (VM2) gets a relative share of 400 for its four virtual CPUs. As a result, VM2 receives twice as much processing time for its four virtual CPUs as VM1. This ensures that each virtual CPU has the same weight within all virtual machines.

On the other hand, if all guests have the same relative share in a CPU constraint scenario, they get exactly the same amount of CPU capacity, independently of the amount of virtual CPUs for the guest.

QUICKDSP option

QUICKDSP is intended for selective use on virtual machines with critical response time requirements. The scheduler always moves a QUICKDSP user immediately into the dispatch list whenever it is ready to run, regardless of resource requirements and current system load. The virtual machine never waits in the eligible list, if there is one. This option is only recommended for mission critical servers.

None of the virtual machines in the SUT had QUICKDSP enabled.

z/VM Resource Manager (VMRM)

The z/VM Resource Manager (VMRM) provides functions to dynamically tune the z/VM system. Groups of virtual machines can be defined to be part of a workload. The workloads can then be managed by VMRM according to goals that are also defined. Virtual machines can be grouped into different workloads, each managed according to different goals. VMRM automatically adjusts performance parameters when there is contention between virtual machines for a resource. Therefore, VMRM has no effect in environments where resources are unconstrained and CPU resource management is not required.

VMRM uses CP monitor data to obtain regular measurements of virtual machine resource consumption. Based on the supplied definition of workloads and workload goals from a configuration file, VMRM will adjust virtual machine tuning parameters to achieve those goals.

Note:

Only the CPU management capability of VMRM was used for this project.
VMRM Cooperative Memory Management and velocity targets for DASDs were not considered.
VMRM is compatible with ILMT (IBM® License Metric Tool).
VMRM is NOT compatible with CPU pooling.

Sample VMRM configuration file

VMRMSVM is a predefined multi-configuration virtual machine that can be enabled to run the VMRM code. This user ID also maintains the VMRM configuration file on its A-disk.

ADMIN MSGUSER VMRMADMN
GOAL MAXCPU VELOCITY CPU 70
GOAL MINCPU VELOCITY CPU 25
WORKLOAD DAYTRADE USER TRDUS*
MANAGE DAYTRADE GOAL MINCPU IMPORTANCE 1
WORKLOAD COGNOS USER COGNUS*
MANAGE COGNOS GOAL MAXCPU IMPORTANCE 10

ADMIN MSGUSER: defines the user ID that will receive messages from VMRMSVM.
GOAL CPU: defines a goal that is comprised of velocity targets for CPU (1-100).
Specifies the percentage of time that the workload should receive CPU resources when it is ready to consume them. This is computed by taking the time the users are running, and divided through the sum of time the users are running or waiting for CPU.
WORKLOAD: defines a workload comprised of one or more virtual machines. Identified by a user name, account ID, or ACI group name.
MANAGE: associates a workload to a goal with the importance (1-10) of achieving this goal.

A low and a high velocity target for CPU is defined for the Cognos BI and the DayTrader workloads. The virtual machines (COGNUS*) belong to the Cognos BI Server and are grouped together with the WORKLOAD statement. Also all DayTrader virtual machines (TRDUS*) are grouped. If no ACI group is used, one can use similar user IDs with a common part and shorten the differing part with an asterisk.

The MANAGE statement associates a workload with its CPU velocity goal and goal importance.

The shown sample VMRM configuration describes the following workload constraints:

manage the Cognos BI workload with a CPU velocity target of 70 and the importance 10 (preferred workload in a CPU constraint system)
manage the DayTrader workloads with a CPU velocity target of 25 and the importance 1 (will receive less share in a CPU constraint system)

Note: The percentage of the CPU goal parameter is calculated in regard to wait times and not CPU load. When managing workloads in a prioritized way, a big advantage of using VMRM is that the CPU goals can be defined for workload groups and not only for individual guests like for the standard relative share definition. That means adding or removing guests to a workload group does not change the CPU velocity goals for the workload. In case of a manually managed share setup, where the relative shares are individually set for each system, a chance for the number of guests would require a change of the relative shares for all guests.

Interaction with the CP monitor

VMRM requires CP MONITOR SAMPLE data in order to monitor virtual machine performance. VMRM starts sample monitoring with an interval of one minute if not active. If it is already active, then VMRM does not start sample monitoring and uses whatever interval is already set.

Performance Toolkit

There is a VMRM screen in the Performance Toolkit (FCX241) that gives some information about the currently active VMRM configuration.

Refer to the z/VM V6 R3.0 Information Center:

Performance Toolkit Reference