Channels
On /390 servers the channels are available to all VMs. They are shared via the firmware. The utilization of the channels can be observed with SM2 over multiple VMs.
On x86 servers, no channels in the original sense are available. X2000 emulates devices with a virtual I/O path which is available on all VMs.
Devices
The devices which exist are determined dynamically when the monitor system and guest systems are started up. VM2000, the monitor system and all guest systems therefore know and monitor the same devices.
Peripheral devices must be assigned to the guest systems individually. There are two options:
explicitly by the VM2000 administrator with /ADD-VM-DEVICES or /SWITCH-VM-DEVICES or
implicitly by a guest system with the privilege ASSIGN-BY-GUEST=*YES(...) with /ATTACH-DEVICE. For this purpose the VM2000 administrator must permit this type of assignment for the VMs and devices concerned.
When disks are assigned implicitly, “Shared” is entered by default as the usage mode.
Peripheral devices can be assigned exclusively to a single guest system or be available to a number of guest systems as shared devices:
Exclusive assignment = The device is then permanently assigned to one guest system
I/O operations are then initiated directly as in native mode.
For guest systems in the wait state ("idle"), the VM2000 hypervisor (/390 server) monitors the receipt of I/O termination interrupts and initializes the corresponding guest system in accordance with its scheduling priority. This hypervisor overhead is minimal.
Shared assignment
= The device is assigned to several different guest systems
The type of I/O processing on /390 servers depends on the following condition:
If the device is only assigned to one guest system, the I/O operations are executed directly (direct I/O) as in the case of exclusive assignment without the involvement of the VM2000 hypervisor.
In the VM2000 information commands the device has the letters SH(D) against it.If the device is assigned to a number of guest systems, on /390 servers the VM2000 hypervisor interrupts all I/O operations of the guest system and serializes them (indirect I/O).
In the VM2000 information commands the device has the letters SH(I) against it.In the case of shared devices the CPU requirements of the VM2000 hypervisor increase with the I/O rate. The VM2000 overhead increases by roughly 0.4% for each 100 I/O operations per second.
On x86 servers disk I/O operations are executed as logical requests via the RSC interface. There is no hypervisor overhead.
Service times for devices (monitoring program SERVICETIME of SM2) can be ascertained by only one VM at any given time.
Privilege IO-PRIORITY (/390 servers)
Applications generally perform synchronous I/O operations. After it has started the task waits for the end of the I/O operation. If no further task is ready to execute, the wait state ("idle") is switched to and the real CPU is redistributed by the hypervisor. After the I/O operation has been completed the guest system must wait for a real CPU to be assigned again before it can process the end of the input/output. The delay between the actual end of the I/O operation and it being processed in the guest system is referred to as the increase in the hardware service time or IO increase.
CPU-intensive guest systems can as a result disturb the operation of I/O-intensive guest systems. Indications of this are provided by /SHOW-VM-STATUS INF=*SCHEDULE in the %RUNOUT and %WAIT output columns.
The quicker the CPU is reassigned to the guest systems, the lower the IO increase is. On /390 servers, the IO-PRIORITY=*YES privilege can be assigned to a VM for this purpose. If a virtual CPU of such a VM is in the wait state, it is activated immediately on a real CPU when an I/O termination interrupt arrives from the hypervisor in order to process the result of the input/output. The runtimes of I/O-critical jobs are considerably improved.
The positive effect is that the hardware service times obtained are as good as in native operation, but on the other hand the scheduling rate is higher. As a result, the VM2000 overhead also increases.
It is therefore advisable to set up the guest systems in the first place without the privilege (i.e. with IO-PRIORITY=*NO) and only to assign the privilege IO-PRIORITY=*YES where necessary.
The IO-PRIORITY=*YES privilege provides no benefits in the case of dedicated CPUs.
Support of the IORM utility routine (I/O Resource Manager)
The IORM utility routine (see the “Utility Routines” manual [6 (Related publications)]) is supported by VM2000. In VM2000 mode IORM should be running on the monitor system and on all guest systems.
The following IORM functions are implemented in conjunction with VM2000:
Dynamic I/O load distribution for disks on the FC channel using DPAV in VM2000 mode (/390 servers only)
Dynamic PAV (DPAV) autonomously assigns alias devices to the volumes which profit most from this. In VM2000 mode the actual switchover of alias devices is coordinated and executed by DPAV in the monitor system.
Optimized device selection in ETERNUS CS operation under VM2000 with DDAL (Dynamic Device Allocation)
As an alternative to using the devices in accordance with the way they are generated (as in the previous versions), the operating system can ensure even utilization of all the available ICPs (Integrated Channel Processors).
Under VM2000 the IORM function DDAL extends optimized (local) device selection to cover all of a server’s BS2000 guest systems.
I/O limit for VM2000 guest systems with IOLVM (I/O Limit for Virtual Machines, /390 servers)
In VM2000 mode, less important guest systems which are I/O-intensive can hinder other, more important guest systems in I/O operations.
The IOLVM function of the IORM utility routine can detect such conflict situations and specifically slows down I/O operations of the user’s own guest system if one of the I/O resources that are used jointly (channel, port, path, disk) exceeds the specific I/O limit.
The I/O limit for IOLVM is defined as the maximum I/O utilization of the VM in the MAX-IO-UTILIZATION operand in the VM2000 command /CREATE-VM or /MODIFY-VM-ATTRIBUTES.