Normally the number of attached real CPUs in a CPU pool is less than the sum of the attached virtual CPUs of all active VMs (state RUNNING) which are assigned to this CPU pool. In this case the hypervisor starts a virtual CPU on a real CPU from the pool using time slicing.
In the VM2000 information commands this scheduling procedure is identified with TS (time slicing).
This CPU assignment makes optimum use of the real CPUs available if direct CPU assignment is not possible.
Operable virtual CPUs of all VMs of the same CPU pool wait for CPU assignment by the VM2000 hypervisor.
If the number of attached real CPUs compared to the number of virtual CPUs increases to the required number (e.g. through reconfiguration or shutdown of a VM), VM2000 automatically switches to the procedure for fixed CPU assignment.
In time slicing, CPUs are assigned in two stages:
Selection of the VM group or of the VM that does not belong to a VM group
Selection of the virtual CPU (of a VM of this VM group or of the VM that does not belong to a VM group) that is to run on a free real CPU of the assigned CPU pool
The VM group or the VM that does not belong to a VM group is selected according to the following criteria (see also the section "Planning distribution of the CPU capacity to the VMs"):
CPU quota (
CPU-QUOTA)
The greater the CPU quota, the sooner the VM group/VM that does not belong to a VM group will be selected.CPU time consumed in the recent past (CPU intensity)
It is not the absolute CPU time after the guest systems were started which is evaluated, but the CPU time consumed within a limited period. This CPU intensity of a VM group or a VM that does not belong to a VM group is calculated by the hypervisor and is periodically aged. The CPU intensity depends on the load of the VM group or a VM that does not belong to a VM group.Maximum CPU utilization (
MAX-CPU-UTILIZATION)
When the upper limit for CPU utilization by the VM group/VM that does not belong to a VM group is reached, the virtual CPUs of the VM group/VM that does not belong to a VM group are not started until this upper limit is no longer exceeded (through aging of the CPU intensity).The VM group is regarded as a unit
If a VM in the VM group does not use up the CPU share intended for it, the other VMs of this VM group are automatically given preference over VMs which do not belong to this VM group with regard to CPU assignment. In this case the CPU intensity of the VM group is of greater significance than the CPU intensity of the member VM (“load balancing within a VM group”).
CPU affinity
With time slicing, VM2000 uses scheduling to ensure that a virtual CPU runs on the same real CPU when the next scheduling operation takes place. This procedure is known as “CPU affinity of the virtual CPU to a real CPU”. It improves the performance of the Server Unit under VM2000 during peak operation.
However, the primary goal is still to optimize the response time, i.e.:
no IDLE state for a real CPU while a virtual CPU of a VM in the CPU pool is ready
orderly distribution of the CPU capacity of the real CPUs in the CPU pools to the virtual CPUs.
Size of the time slice
The size of the time slice for each VM of VM2000 is defined dynamically in the range 0.1 through 8.0 milliseconds. VMs with a “very small” CPU quota are then also assigned a smaller time slice.
The size of the time slice is recalculated when the VM’s effective CPU share is modified (EFF-Q, see "Planning distribution of the CPU capacity to the VMs").
Example
Time slice size for a bi-VM with EFF-Q=0.5 on a Server Unit with 4 CPUs:
0,5 * 4 (real CPUs) / 2 (virtual CPUs) = 1,0 ms
As of EFF-Q=4,0 the VM would have the existing time slice of 8 ms.
For EFF-Q < 0,05 scheduling every 100 ms is no longer guaranteed.
/SHOW-VM-STATUS INFORMATION=*SCHEDULE outputs the size of the time slice which is currently set for the VM in the VM-specific information block, output field TIME SLICE DEF, see "SHOW-VM-STATUS (Output VM2000 monitored data)".
It is the task of the VM2000 administrator to ensure that the effective (EFF-Q) and consequently the current (CUR-Q) CPU share of the VM is large enough to permit the VM to obtain control of the CPU sufficiently frequently, generally once a second (see "Planning distribution of the CPU capacity to the VMs").