The other application domain VM is used for is the guest environment, both for production and test/development guest systems. Some industry think-tanks claim that LPAR and MDF (Amdahl) hardware partitioning make VM's guest capabilities unnecessary. These facilities can displace VM in some sites that have no need for VM beyond its guest capabilities, but VM's guest environment still provides flexibility and hardware savings not possible with either LPAR or MDF.
VM's Multiple High Performance Guest facility, using the PR/SM hardware, provides performance equivalent to LPAR or MDF logical partitioning. V=R and V=F guests run as well as they would if running without VM. The days in which VM could not easily run production MVS systems are gone. Unlike LPAR and MDF, VM allows an arbitrary number of guests running in pageable mode. This is perfectly adequate for most test and some production MVS systems, and works very well with other guests like VSE.
LPAR and MDF incur hardware costs that VM avoids. They require that channels be dedicated to a given partition or domain, unless ESCON's EMIF is available, while VM allows I/O attachment on a device-by-device basis. Additional channels may have to be purchased and cabled to control units. It also frequently means that all the channel adapters on a control unit become used up. In order to provide device connectivity to a partition or domain, it may be necessary to purchase additional control units or to run system images with fewer paths. Additional control units are always required for the system consoles, since 3174 control units have only one channel connection. None of these drawbacks occur when VM is used.
At my own site, we have quad-pathed DASD, but the MVS systems running under LPAR get no more than two paths per image, while VM applications, including MVS guests, get the improved performance and availability possible with four paths. VM is still a better production environment for multiple images on the same CPU complex than LPAR and MDF.
VM also provides facilities that do not exist in hardware based partitioning. VM's guests are insulated from IOCPs, device address changes, and CPU serial numbers changes (within a model type). CP's ability to virtualize the amount of storage and number of CPUs or vector facilities in a complex are also outside the reach of hardware partitioning.
Virtual 3088 emulation makes it possible to provide inter-system communication that would normally require real hardware. Virtual 3088s cost less, and take up less power and floor space than the real ones! Also, DIAL and spooled devices replace real, dedicated devices and control units.
IBM continues to add VM-only support for guest systems that exceed hardware partitioning capabilities. VM/ESA provides virtual disks (VDISK), simulated FBA-format DASD that reside in pageable memory and can be shared between virtual machines with much higher I/O rates and shorter latency than real DASD devices. VDISK is intended for transient, frequently accessed disk files, such as VSE lock files, and lets guest VSE systems significantly outperform VSE running on native hardware, without expensive semiconductor DASD. When we moved VSE guests to VDISK lockfiles, we achieved a 25% improvement for our production batch cycle, even though the lock file had previously been running on electronic DASD! With VM/ESA 2.2 and later, minidisk cache can now be used for non-CMS disk formats like VSAM, permitting higher performance for guests. These enhancements keep VM the preferred environment for running multiple system images on the same hardware.
[ Prior page | Next page | Top page ]