Under VM2000, the real CPUs of a server which are available for VM2000 operation can be split into different, disjunctive CPU pools. This strategy enables greater hardware efficiency and CPU affinity to be achieved for servers with a large number of CPUs. A VM is assigned to precisely one CPU pool.
VM2000 attempts to assign the CPU performance of the real CPUs in a CPU pool to the individual guest systems assigned to a CPU pool in proportion to the CPU quotas. An upper limit results from the maximum CPU utilization of a VM.
The following characteristics of CPU pools have an influence on the server’s performance:
CPU pools reduce the VM2000 overhead especially with a larger number of real CPUs
CPU pools permit a targeted but strictly limited performance (service level) for a set of VMs (“restricted VM group”) with a further reduction in VM2000 overhead
CPU pools on /390 servers enable a permanent CPU assignment (dedicated CPUs) to be created for critical productive systems.
Criteria for establishing CPU pools:
The size of the CPU pools (the number of real CPUs assigned to a CPU pool) should be planned to ensure that the CPU performance made available corresponds to the sum of the planned share of performance for the VMs assigned to the CPU pool. As with the CPU utilization of the entire server, the CPU utilization of the individual CPU pools in OLTP mode should not be greater than 75%.
The utilization of the server’s real CPUs should be as even as possible. Consequently the utilization of the CPU pools should be as even as possible.
In the case of CPU pools with just one real CPU it is to be expected that the dilation of the hardware service time (see "Peripherals") is greater than with pools containing multiple real CPUs.
If the performance requirement of the guest systems changes in the course of a session, /SWITCH-VM-CPU can be used to add/remove CPUs to/from the CPU pool dynamically.
Criteria for assigning VMs to the CPU pools:
In the case of guest systems with applications whose response time behavior is heavily dependent on the duration of the I/O operations, the contending VMs or guest systems in the same pool should be selected carefully so that the increase in the hardware service time does not have an unfavorable effect. For example, you should prevent a large number of CPU-intensive guest systems from being assigned to one CPU pool.
In the case of guest systems with particularly high performance requirements the CPU pool can be equipped with enough real CPUs to ensure that a real CPU is available for each active virtual CPU. With respect to scheduling, VM2000 then works with a permanent CPU assignment on /390 servers.
The VM-ACTIVE-IDLE=*AT-DEDICATED-CPUS parameter (/390 server) enables a VM with fixed CPU assignment to still retain control over a real CPU if the VM’s virtual CPU which is running on it is inactive (interruptible wait state, "idle").
This also prevents the changes of context when the guest system is in the wait state (idle). On /390 servers this allows a performance to be achieved which is almost equal to that in native mode.No evaluation of the VM-ACTIVE times (/SHOW-VM-STATUS or VM report of openSM2) is possible for VMs with VM-ACTIVE-IDLE.
When required, individual VMs or entire VM groups can be assigned dynamically to other CPU pools using /ASSIGN-VM(-GROUP)-TO-CPU-POOL.