Virtualization Architecture and strategies
60 U41855-J-Z125-3-76
In the case of reduced or abnormal operation the basic system automatically reacts with the
following step-by-step measures to rectify the lack of CPUs:
1. The (free) CPUs not used so far are used
2. Step-by-step reduction of the Linux/Windows pool to 2 CPUs
3. The BS2000 CoD CPUs are omitted
4. Alternating omission of one CPU of the BS2000 pool down to 2 CPUs
5. Pool 0 is reduced to 1 CPU
6. The last but one CPU of the Linux/Windows pool and of the BS2000 pool is omitted
7. Cancelation of the Linux/Windows pool
The SE Manager displays an overview over the available BS2000 CPU pools (including
empty pools) and an overview over the BS2000 VMs to which a CPU pool is currently
allocated under Systems
→ [<se server>(SE<model>) →] <su-name> (model) → Vir tual
machines [
→ BS2000] → VM resources.
For information on BS2000 and BS2000 VMs, see also section “Working in Native BS2000
mode” on page 115 and section “Working in VM2000 mode” on page 118, and for
information on XenVMs, see also section “Working in XenVM mode (on Server Unit x86)”
on page 130.
2.7.2.2 Main memory management
Around 30 %, but at most 16 GB, of the existing main memory is reserved for the X2000
basic system.
BS2000 can use the remaining 70% on the Native system or on the BS2000 VMs. In
optional XenVM operation the XenVM systems also use this main memory share.
The main memory cannot be reserved in advance for a particular type of virtual machine
(BS2000 VMs or XenVMs). It is only ever assigned to the guest system concerned when a
virtual machine is started (created/activated in case of BS2000 VM) if the amount of free
main memory requested is available.
2.7.2.3 BS2000 devices
The real devices of the periphery are not directly visible to BS2000 (Native BS2000 and
BS2000 VMs). Only the devices emulated in the X2000 basic system are visible. See also
section “Managing BS2000 devices” on page 166.
To Next Page
Loading...
Need help?
General