Virtual CPUs

The number of CPUs for a VM (virtual CPUs) is defined by specifying a multiprocessor level when a VM is created (in /CREATE-VM by means of the PROCESSOR operand). A VM can be set up with the multiprocessor levels 1 through 32 (depending on the architecture of the Server Unit), in other words with a maximum of 32 virtual CPUs (CPU 00 through CPU 1F), see "Initializing a VM".
The multiprocessor level of a VM must be less than or equal to the number of real normal CPUs which can be available for VM2000 operation.
Exception: see the note on the PROCESSOR=*EXTRA-AND-NORMAL operand on "Increasing capacity with extra CPUs".

The multiprocessor level for a VM can also be entered in the VM definition with /CREATE- or /MODIFY-VM-DEFINITION. Detailed information can be found in the section "Working with VM definitions".

Once a VM has been initialized, it is no longer possible to modify its multiprocessor level.

Depending on the expected load on the guest system, the multiprocessor level of a VM should be set as low as possible.

The multiprocessor level selected for a VM should also be less than or equal to the number of attached real CPUs in the CPU pool to which the VM is assigned (see "Managing CPU pools").

However, a guest system can also run if its multiprocessor level exceeds the number of attached real CPUs (overdimensioned VM).

Example

Biprocessor VM which is assigned to a CPU pool with two real CPUs; one of these real CPUs is detached. The resulting performance loss, e.g. through CPU locks of the virtual CPUs, must be taken into consideration.

Note on the terms used

In order to distinguish them clearly from virtual spare CPUs, the virtual CPUs described here, where necessary, are referred to as virtual normal CPUs.

The multiprocessor level of the monitor VM is set when VM2000 is installed (see "Configuration using the SE Manager (SU x86)").

If hot spare CPUs are available on SU /390, each VM is assigned not only virtual normal CPUs but also virtual spare CPUs, see "High availability with hot spare CPUs (SU /390)".

 

Virtual CPUs are assigned one of the following states:

RUN	The CPU can run. This status is attained after successful startup of the guest system successful /ATTACH-DEVICE the CPU pool of an active VM has been switched with automatic attachment of virtual CPUs (/ASSIGN-VM-TO-CPU-POOL ...,ATTACHED-VM-CPUS=*ADJUST-NUMBER) the CPU pool has been extended with automatic attachment of virtual CPUs (/SWITCH-VM-CPU ...,TARGET-CPU-POOL=*ADJUST-NUMBER) Migration of a VM with virtual CPUs in BLOCK state to the target SU, on which the corresponding CPU pool has more real CPUs attached than the CPU pool on the source SU (/MIGRATE-VM)
IDLE	The CPU is in the interruptible wait state.
INIT	The CPU is initialized (VM in INIT-ONLY state or (on SU x86) the state of a virtual CPU up to the automatic attachment when starting up in the BS2000 guest system).
WAIT	The CPU has been stopped by VM2000 (VM in IN HOLD(WAIT) state).
HALT	The CPU has been halted by X2000 (short-term transitional state or error).
STOP	The CPU has been stopped (stop by the hardware). This state is attained after successful /DETACH-DEVICE (VM not overdimensioned, see "Number of attached real and virtual CPUs in the CPU pool") the CPU pool of an active VM has been switched without automatic attachment of virtual CPUs (for CPUs in BLOCK state) (/ASSIGN-VM-TO-CPU-POOL ...,ATTACHED-VM-CPUS=*CHECK-NUMBER) the CPU pool has been extended without automatic attachment of virtual CPUs (for CPUs in BLOCK state) (/SWITCH-VM-CPU ...,TARGET-CPU-POOL=*NONE)  (machine check) error In these cases the CPU can be attached again during ongoing operation.
BLOCK	The CPU is “blocked” by VM2000. This state is reached after the following actions (in all cases the VM was overdimensioned beforehand, see "Number of attached real and virtual CPUs in the CPU pool"): Startup of the guest system successful /DETACH-DEVICE the CPU pool of an active VM has been switched with automatic detachment of virtual CPUs (/ASSIGN-VM-TO-CPU-POOL ...,ATTACHED-VM-CPUS=*ADJUST-NUMBER) the CPU pool has been reduced with automatic detachment of virtual CPUs (/SWITCH-VM-CPU ...,SOURCE-CPU-POOL=*ADJUST-NUMBER) the CPU pool of an active VM has been switched with preparatory detachment of virtual CPUs the CPU pool of an active VM has been reduced with preparatory detachment of virtual CPUs to the target SU on which the corresponding CPU pool has less real CPUs attached than the CPU pool on the source SU. Because of this, some virtual CPUs of the migrated VM have to be automatically detached (/MIGRATE-VM). In these cases the CPU in the guest system cannot be attached again.
SLEEP	The hot spare CPU is ready but sleeping.             This VM currently contains only one attached normal virtual CPU. This state can also occur temporarily during a CPU reconfiguration.
OFF	The CPU is not ready (offline). This state is attained: for a hot spare CPU if there are several attached virtual normal CPUs in this VM after a CPU error (MCK, MFA) if the CPU can only be used again after the next startup of the guest system

The VM2000 administrator can use /SHOW-VM-RESOURCES and the INFORMATION=*CPU,VM-IDENTIFICATION=... operand to obtain information on the state of the specified VMs' virtual CPUs.

The VM administrator can use /SHOW-VM-ATTRIBUTES and the INFORMATION=*CPU operand to obtain information on the state of the virtual CPUs of his/her VM.

Running virtual CPUs on real CPUs

When scheduling takes place, at runtime a decision is taken regarding the assignment of an operable virtual CPU to a free real CPU from the CPU pool to which the VM belongs (see "Scheduling procedure"). The virtual CPU selected is then started up on the real CPU.

	On SU /390, scheduling is implemented by the VM2000 hypervisor.
	On SU x86, scheduling is implemented by the Xen hypervisor.