Before a VM can be used, it must first be initialized in VM2000. This first stage of operation is known as initializing a VM. A VM is initialized by means of /CREATE-VM (VM2000 administrator). This requires that no VM or VM definition has been configured with the specified VM name. The VM administrator is allowed to terminate but not to initialize a VM.
/ACTIVATE-VM-DEFINITION and possibly restarted if a corresponding persistent VM definition exists for this purpose. Further information on VM definitions is provided in the section "Working with VM definitions".During the initialization process, attributes and resources are assigned to the VM:
VM index and VM name (identification of the VM)
Main memory size of the VM
Minimum and maximum main memory size of the VM for main memory reconfiguration
Location of the VM in the main memory of VM2000
CPU quota and maximum CPU utilization of the VM
Maximum I/O utilization of the VM
Adding of the VM to a VM group
Assignment of the VM to a CPU pool
Multiprocessor level of the VM
Password for dialog access
Range of commands available to VM2000 and VM administrators
Privileges of the VM
Settings for control over the real CPU
PERSISTENT attribute
After the successful initialization, the VM has the status INIT-ONLY.
 | On SU x86, a VM’s firmware component is started when the VM is initialized. Despite the INIT-ONLY status, the VM already utilizes a minimal CPU capacity. |
The maximum number of VMs which can be initialized depends on the architecture of the Server Unit, see "CREATE-VM (Initialize a VM)". It is also displayed when /SHOW-VM-RESOURCES INFORMATION=*CONFIGURATION is used.
Identification of the VM
The identification VM-ID identifies the VM in the VM2000 commands. The VM-ID can be the VM index or the VM name. VM index and VM name are assigned to a VM during initialization. These identify a VM unambiguously and can no longer be changed following initialization of the VM.
The VM index is an integer n from 1 to 99 (the upper limit depends on the architecture of the Server Unit) and identifies the VM (VM1 to VMn). The VM2000 administrator can predefine the VM index explicitly. If no VM index is specified (default), VM2000 selects the next free index. The VM index is used to manage a VM internally within VM2000.
The VM name is assigned explicitly by the VM2000 administrator (default). The name should reflect the user or the usage mode of the VM. It should be specified explicitly to avoid standard names which are not very meaningful.
If no VM name is specified, VM2000 assigns the standard name VM00nn, where nn is the VM index (nn=01..99). Initialization of the VM is rejected if a specified VM name corresponds to the standard name of another VM (e.g. VM-INDEX=5, VM-NAME=VM0002) or has already been assigned.
Recommendations for the definition and use of VM names
The VM administrator should use the VM name as the VM-ID in procedures. The VM index should be avoided in procedures, as it may change in every session.
The VM name should be unique within a VM2000 installation.
 | The default name of the monitor VM on SU x86 is MONITOR.When a VM is configured on SU x86, the VM name is used as the domain name. |
The name ranges for VMs, VM groups and CPU pools should be disjunctive.
/MODIFY-VM-ATTRIBUTES and specifying the previous VM name. In such a case VM2000 writes BS2000 accounting records for the relevant VM and for devices assigned to it (see "Accounting in VM2000").Size of VM main memory
This attribute determines the main memory size for the VM (see section "Managing main memory"). The maximum main memory size under VM2000 is 1 Tbyte (terabyte; 1 Tbyte = 1024 Gbytes = 1 048 576 Mbytes).
 | On SU /390, a main memory area begins on a 1-Mbyte boundary and its size is a multiple of 1 Mbyte. |
 | On SU x86, the size of a main memory area is a multiple of 2 Mbytes. In addition to the main memory for a BS2000 guest system, a small amount of a VM’s main memory is required for the firmware component. The main memory of a VM on SU x86 must therefore be at least 1024 Mbytes in size. |
Minimum size of VM main memory
The minimum main memory size should only be specified for a VM if the size of the main memory of the VM is to be reduced while the guest system is active (see "Reconfiguring main memory").
The minimum main memory size can be increased with /EXTEND-VM-MEMORY. On SU /390 it can be decreased (implicitly) with /REDUCE-VM-MEMORY (see "REDUCE-VM-MEMORY (Reduce main memory for a VM)").
Note on dimensioning the minimum main memory size
The minimum size of the main memory selected for a VM must be at least large enough to permit the resident memory requirements in the guest system to be satisfied. The resident memory requirement depends on whether the software product DAB is used.
The current utilization of resident memory can be determined by openSM2 from the values of the MEMORY report group (see the “openSM2” manual [9]): Resident Memory = TOTAL - Pageable Frames .
 | On SU x86, the minimum size of a VM’s main memory must be at least 1024 Mbytes, see above. |
If the main memory of a VM is reduced to the minimum size, the load on the guest system must be reduced accordingly.
Maximum size of the VM’s main memory (SU x86)
The maximum size of the main memory should be defined for a VM only when the main memory of the VM is to be extended while the guest system is active (see "Reconfiguring main memory").
If the VM’s main memory is not to be extended during ongoing operation, the same value for the main memory should be selected for the maximum size (MAX-MEMORY-SIZE) as for the VM’s main memory (MEMORY-SIZE).
The default value of the maximum size of the main memory is twice the size of the main memory for the VM concerned which is specified by MEMORY-SIZE. The maximum size of the VM’s main memory is limited by the main memory which is available (output line TOTAL REAL MEMORY SIZE in /SHOW-VM-RESOURCES INFORMATION=*CONFIGURATION).
A VM can (without a message being issued) also be assigned a smaller main memory size than requested when:
the requested value (specified explicitly or implicitly by means of the default value) is greater than the main memory which is available
the minimum size of the VM is too small for the implicit default value (double the size of the VM’s main memory)
However, when the value of the maximum size in the latter case is specified explicitly, such a memory value combination is rejected (VMS4093).
 | On SU /390, the maximum size of a VM's main memory is ignored. A VM can always be extended to the start of the next VM or to the end of the main memory. |
Location of the VM in VM2000 main memory
 | On SU /390, this attribute determines the location of the VM in the main memory of VM2000 (see "Main memory management and reconfiguration"). The address must be a multiple of 1 Mbyte. If the location is not specified, VM2000 selects a suitable area. The location of the VM in main memory can subsequently be modified by means of /MOVE-VM. |
 | On SU x86, the location of a VM cannot be determined. Thus only the default value can be specified for this attribute (*ANY, the location of the VM in the main memory is not predefined). |
CPU quota and maximum CPU utilization of the VM
These parameters determine the longterm distribution of the avaiable CPU capacity on the VMs.
 | On SU /390, the CPU quota determines for a VM which does not belong to a VM group, the VM’s share of the CPU capacity of the CPU pool in comparison to the VM groups and the other VMs which do not belong to a VM group. In the case of a VM which belongs to a VM group, the member CPU quota determines this VM’s share of the CPU capacity of the CPU pool in comparison with the VMs of the same VM group. The CPU share of a VM can be restricted by the maximum CPU utilization of the VM or VM group. |
 | On SU x86, the VM’s CPU quota determines the VM’s share of the CPU capacity of the CPU pool in comparison to the other VMs. The CPU share of a VM can be restricted by the maximum CPU utilization of the VM. |
Further details can be found in the section "Planning distribution of the CPU capacity to the VMs".
The CPU quota and maximum CPU utilization can be modified by means of /MODIFY-VM-ATTRIBUTES.
Maximum I/O utilization of the VM
The I/O utilization of a VM can be limited by the maximum I/O utilization of the VM.
 | On SU /390, the BS2000 subsystem IORM monitors the maximum I/O utilization in the IOLVM function, see "Use of IORM in VM2000 operation". |
 | On SU x86, only the default value (100, unlimited utilization) can be used for this attribute. |
The maximum I/O utilization can be changed using /MODIFY-VM-ATTRIBUTES.
Adding the VM to a VM group
A VM can be operated as a VM that does not belong to a VM group or as a member of a VM group.
 | On SU /390, the VM can be added to a VM group when it is created using the CPU-QUOTA=*BY-VM-GROUP(...) operand. In this event it is assigned a member CPU quota. |
 | VM groups are not available on SU x86. |
Assigning the VM to a CPU pool
Every VM is always assigned to precisely one CPU pool.
If the VM does not belong to a VM group, the CPU pool can be freely selected. By default (CPU-POOL-NAME=*STD operand) the VM is assigned to the standard CPU pool when it is created. The assignment of the VM to a CPU pool can be changed using /ASSIGN-VM-TO-CPU-POOL.
If the VM is added to a VM group, (SU /390, CPU-QUOTA=*BY-VM-GROUP(...) operand), it is automatically assigned to the VM group’s CPU pool (CPU-POOL-NAME=*STD operand). The assignment of the VM group to a CPU pool can be changed using /ASSIGN-VM-GROUP-TO-CPU-POOL.
Further information on CPU pools is provided in the section "Managing CPU pools".
Multiprocessor level of the VM
This attribute defines the number of CPUs on which a VM is to run simultaneously. The following multiprocessor levels are supported by VM2000 (implementation limit):
1 | (MONO) | one processor (virtual CPU 0) |
2 | (BI) | two processors (virtual CPUs 0 and 1) |
3 | (TRIPLE) | three processors (virtual CPUs 0, 1 and 2) |
4 | (QUADRO) | four processors (virtual CPUs 0 through 3) |
5 | (5-Way) | five processors (virtual CPUs 0 through 4) |
6 | (6-Way) | six processors (virtual CPUs 0 through 5) |
7 | (7-Way) | seven processors (virtual CPUs 0 through 6) |
8 | (OCTO) | eight processors (virtual CPUs 0 through 7) |
9 | (9-Way) | nine processors (virtual CPUs 0 through 8) |
. . . | . . . | |
32 | (32-Way) | 32 processors (virtual CPUs 0 through 31) |
On SU /390, the maximum multiprocessor level is 16.
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 in the section "Increasing capacity with extra CPUs".
The virtual CPUs of the VMs that result from this are started up on the available real CPUs, see section "Scheduling procedure".
The multiprocessor level of a VM constitutes the upper limit for the maximum CPU utilization, see "CPU quota and maximum CPU utilization of the VM". For example, a biprocessor-VM can accommodate the CPU capacity of up to two real CPUs.
The multiprocessor level of the monitor VM is set when VM2000 is installed (see chapter "Installing VM2000").
Once a VM has been created, its multiprocessor level can no longer be modified.
Password for administration and operation
This attribute defines a password which must be specified by the VM administrator (in the ADMIN dialog) and the guest system operator (in the VC dialog) when a dialog is opened with /BEGIN-VM-DIALOG. If no password is specified, no password is required for /BEGIN-VM-DIALOG. The password can subsequently be modified by means of /MODIFY-VM-ATTRIBUTES. There are other protective features for operation using a BS2000 console.
Range of commands available to VM2000 and VM administrators
This attribute defines the range of commands available to VM2000 and VM administrators. The range of commands can be restricted (for VM2000 administrators) or extended (for VM administrators); see "Extending and restricting the range of commands/functions".
The range of commands can subsequently be modified by means of /MODIFY-VM-ATTRIBUTES.
Privileges of the VM
IO-RESET privilege
The I/O RESET operation is an extreme measure to overcome problems in the input/output configuration. To do this, the VM must be assigned the privilege IO-RESET=*YES (when initializing the VM or /MODIFY-VM-ATTRIBUTES).
 | On SU /390, it is recommended that a VM be set up without a privilege (i.e. with IO-RESET=*NO) and that the privilege should only be assigned using /MODIFY-VM-ATTRIBUTES when required. |
 | On SU x86, only the default value (*NO, no problem correction with IO-RESET) can be used for this attribute. |
For a VM with IO-RESET=*YES, VM2000 takes the following actions on SU /390:
When
/START-VMis issued (or when the guest system is restarted), a system reset is carried out, similarly to a firmware IPL. In this case, all channels of this VM are reset in the hardware where at least one disk is assigned to the VM (eitherEXCL(exclusive) orSH(D)(SHARED, direct I/O)).When resetting a channel via the guest system on the VM (e.g. in the case of local channel reconfiguration), the channel is reset in the hardware.
If
/REMOVE-VM-DEVICESis specified withFORCE=*YES(called explicitly or executed during/DELETE-VM) all channels to which the device is connected are reset in the hardware as necessary.
For a VM with IO-RESET=*NO, resetting channels is emulated by the VM2000 hypervisor for the VM, and no action is taken in the hardware.
- Effects on other VMs:
In the three cases listed above, all executing input/output tasks of other guest systems on these channels are terminated. Further execution of this guest system depends on the relevant error recovery routine in the guest system. IO-RESETin the monitor VM:
Measure 2 is always carried out for the monitor VM.
Measure 1 is carried out when the monitor system is restarted ifIO-RESET=*YESwas specified for the monitor VM during its initialization or with/MODIFY-VM-ATTRIBUTES.
IO-PRIORITY privilege
Under VM2000, a VM that goes into the wait state (IDLE) after an input/output has started, for example, transfers the real CPU to another VM that is ready for operation. The input/output that has been started can be terminated in the case of fast cache media, for example, before the VM starts running again on a real CPU. The VM waits until it starts running again on a real CPU as a result of scheduling (see "Scheduling procedure"). It can then process the result of the input/output.
A VM or guest system that is slowed down in this way can counter this effect by means of the IO-PRIORITY=*YES privilege.
On SU /390 a VM in the wait state with this privilege is put into operation again on a real CPU immediately on completion of the pending input/output. The guest system can then immediately process the result of the input/output.
The IO-PRIORITY=*YES privilege can be assigned when the VM is initialized or with /MODIFY-VM-ATTRIBUTES. It applies to all virtual CPUs of the VM.
 | On SU /390, it is recommended that a VM be set up without a privilege (i.e. with IO-PRIORITY=*NO) and that the privilege should only be assigned using /MODIFY-VM-ATTRIBUTES when required. |
 | On SU x86, only the default value (*NO, no I/O prioritization) can be used for this privilege. |
The sum of the virtual CPUs of all VMs with the IO-PRIORITY=*YES privilege must not be greater than the number of real normal CPUs of the Server Unit.
AUTO-SNAP-ASSIGNMENT privilege
This privilege permits the guest system on a VM to assign itself snap units of a Snapset implicitly without the VM and device being assigned the ASSIGN-BY-GUEST privilege or attribute.
ASSIGN-BY-GUEST privilege
This privilege determines whether the operating can implicitly assign devices of particular assignment sets to the own VM himself/herself (e.g. with /ATTACH-DEVICE), see "Assignment sets, implicit device assignment and release".
To permit implicit device assignment, the VM must have the ASSIGN-BY-GUEST privilege for the required assignment sets (when the VM is initialized or later with /MODIFY-VM-ATTRIBUTES).
Each device that is to be implicitly assigned must also have the attribute ASSIGN-BY-GUEST (see /MODIFY-VM-DEVICE-ATTRIBUTES). The device is also assigned to the required assignment set here.
Settings for control over the real CPU
On SU /390 this attribute determines whether, in the event of fixed CPU assignment (dedicated CPUs), a VM still retains control over a real CPU if the VM’s virtual CPU which runs on this is inactive (interruptible wait state IDLE).
On SU x86, only the default value (*NO) can be used for this attribute.
When VM-ACTIVE-IDLE=*NO (on SU /390), the VM leaves control over the real CPU if the VM’s virtual CPU which runs on this becomes inactive (interruptible wait state IDLE).
When VM-ACTIVE-IDLE=*AT-DEDICATED-CPUS, the VM retains control over the real CPU assigned even if the VM’s virtual CPU which runs on this becomes inactive (interruptible wait state IDLE).
In this case, additional performance is achieved because no change of context takes place. However, this idle time is then indicated in the VM2000 accounting records, with /SHOW-VM-STATUS (VM-ACTIVE output column) and in the VM2000 report of openSM2 as a time in which the VM actively uses the real CPU.
This setting provides no additional performance if a large number of I/Os are to be expected for shared disks or on a virtual console.
VM-ACTIVE-IDLE=*AT-DEDICATED-CPUS is only effective if the VM’s maximum CPU utilization (see "CPU quota and maximum CPU utilization of the VM") is not restricted.The setting can also be modified later using /MODIFY-VM-ATTRIBUTES.
PERSISTENT attribute
The PERSISTENT attribute defines whether a persistent VM is created (PERSISTENT=*YES). A persistent VM is assigned a persistent VM definition.
The PERSISTENT attribute cannot be set for the monitor VM.
A persistent VM definition is also available to a Server Unit after a reboot. With its help a persistent VM is set up again and restarted immediately when the corresponding specification is provided in the AUTO-IPL parameter. A persistent VM definition is not deleted with /DELETE-VM.
A VM without the PERSISTENT attribute is assigned a non-persistent VM definition. This is deleted with /DELETE-VM.
Further information on VM definitions is provided in the section "Working with VM definitions".