Messages that provide information on status changes of real or virtual CPUs are sent to all VM2000 administrators as asynchronous messages and, via routing code “9”, to the authorized BS2000 consoles or applications. See also "Automating VM2000 and VM administration".
Failure of real CPUs
 | On SU /390, VM2000 responds to the failure of real CPUs. These CPUs are no longer used by VM2000, the operation continues on the remaining real CPUs. If hot spare CPUs are available, they are attached automatically by VM2000 and replace the failed CPUs, see "High availability with hot spare CPUs (SU /390)". CPUs in WFM state (SU /390 with “hot spare CPU”, see "Real CPUs") must be made available again by customer support. It is then necessary to reboot the Server Unit. If a virtual CPU was assigned to the real CPU at the time the failure occurred, VM2000 notifies the guest system of this CPU failure. The guest system then executes the requisite failure handling. |
 | On SU x86, the failure of a real CPU generally results in abnormal termination of operations (server crash (panic)). The Server Unit must be restarted (an automatic reboot can be set). Defective CPUs or CPU groups then remain detached. The static CPU pools (see "Implementation on SU x86") are configured in such a way that the standard CPU pool as far as possible contains the number of BS2000 CPUs envisaged for this Server Unit. VM2000 must be initialized again. |
Reconfiguration of real CPUs
If an attached real normal CPU or extra CPU is to be deactivated, the VM2000 administrator can detach it by means of /DETACH-VM-RESOURCES. VM2000 operation then continues on the remaining real CPUs.
CPU reconfiguration is rejected if, after the real CPU is rejected, there is not at least one real CPU available in the CPU pool. For details please also refer to the section "Number of attached real and virtual CPUs in the CPU pool".
If a detached real CPU is to be made available again, the VM2000 administrator can attach it again by means of /ATTACH-VM-RESOURCES.
Reconfiguration of virtual CPUs
Virtual CPUs are reconfigured explicitly in the guest system by means of the BS2000 commands /ATTACH-DEVICE and /DETACH-DEVICE. /ATTACH-DEVICE attaches virtual CPUs, and /DETACH-DEVICE detaches them.
Reconfiguration in the guest system makes sense in the following cases, for example:
In the event of fluctuating loads in the guest system so as only to activate the required CPUs, see also the “Performance Handbook” [18]
After reconfiguration of real CPUs by VM2000
Example
There is a biprocessor VM, but there is only one real CPU available in the CPU pool (e.g. after reconfiguration of real CPUs by VM2000). In this case, the virtual CPUs run sequentially on the available real CPU. The resulting loss in performance can either be accepted or avoided by means of reconfiguration in the guest system, i.e. in all BS2000 guest systems the multiprocessor level must be adapted by means of/DETACH-DEVICE UNIT=*CPU(...)by the same number of CPUs to suit real conditions.
Virtual CPUs are reconfigured implicitly by VM2000 in the following cases:
When the CPU pool of an active VM is switched with automatic attachment or detachment of virtual CPUs
(/ASSIGN-VM-TO-CPU-POOL ...,ATTACHED-VM-CPUS=*ADJUST-NUMBER)When the CPU pool is extended or reduced with automatic attachment or detachment of virtual CPUs
(/SWITCH-VM-CPU ...,TARGET/SOURCE-CPU-POOL=*ADJUST-NUMBER)VM Migration with automatic attachment or detachment of virtual CPUs
The reconfiguration of virtual CPUs in the guest system does not have any effect on real CPUs or on virtual CPUs of other guest systems. This also applies to reconfiguration in the monitor system.
The VM2000 commands /SHOW-VM-ATTRIBUTES and /SHOW-VM-RESOURCES and the BS2000 command /SHOW-DEVICE-CONFIGURATION (CLASS=*CPU) indicate the state of the virtual CPUs.