The z/VM product has its roots in an IBM product named VM/370, released in August 1972. VM/370 grew from earlier unsold versions of virtual machine technology dating back to 1967. This article explores some of the current product’s constructs and concepts. Let’s start with the basics.
The IBM System z processors operate according to a data processing machine architecture defined in z/Architecture Principles of Operation. This book explains the machine’s instruction set, its I/O processing rules, and how it runs programs. Engineers implement z/Architecture in IBM System z machines such as those in the IBM z9 family.
The role of many operating system kernels is to create well-defined program execution contexts in which applications can run concurrently without interfering with one another. For z/VM, these execution contexts are called virtual machines. Where an ordinary operating system might create execution contexts for application programs, z/VM creates execution contexts for System z operating systems. In other words, z/VM’s task is to create virtual machines adhering to z/Architecture. z/VM can create nearly any virtual configuration that could legitimately exist in the real hardware. Further, z/VM lets many such virtual machines exist and operate simultaneously on one instance of real hardware; in fact, in the most interesting cases, z/VM overcommits the real hardware. A virtual machine also is often known as a VM user ID, a VM logon, a VM guest, or a virtual server.
Just as a real System z machine consists of real processors, real memory, and real I/O devices, a virtual machine consists of virtual processors, virtual memory, and virtual I/O devices. For example, z/VM might equip a virtual machine with two virtual processors, 1GB of virtual memory, a virtual Ethernet card, and a virtual 3270 terminal device. Because of the histories of z/VM and its guests, some of the virtual devices found in a typical virtual machine’s configuration correspond to real devices IBM no longer manufactures. For example, each virtual machine will typically have a virtual card reader, virtual card punch, and virtual printer. Many guests still effectively use these antiquated virtual devices even today.
Various System z operating systems can run in virtual machines. One, Conversational Monitor System (CMS), is sold as part of z/VM. CMS is an interactive, single-user operating system meant to run in a virtual machine. Though for many years CMS and its applications were a mainstay of IBM’s offerings in interactive general-purpose computing, CMS recently has found its niche in supporting applications meant to help manage the z/VM system. The z/VM TCP/IP stack, for example, runs in a CMS virtual machine. CMS isn’t the only System z operating system that can run virtually. Other System z operating systems, such as z/OS, z/VSE, z/TPF, and Linux for System z, can all run in virtual machines on z/VM.
The heart of z/VM is a multi-programming, multi-processing operating system kernel known as the Control Program (CP). (Be careful when using the term “CP,” for in some communities, “CP” means “central processor.”) CP is the component of z/VM that creates and dispatches virtual machines on the real System z hardware.
CP supports hundreds of commands. Some control the configuration of the virtual machine. For example, the CP DEFINE command lets a customer create a virtual device and add it to a virtual machine’s configuration. Though CP lets customers change virtual machine configurations nearly at will, customers usually define their virtual machines ahead of time in a user enrollment and definition file called the CP directory. The CP directory describes virtual machines and sets attributes for each one, such as number of virtual processors, amount of virtual memory, and complement of disk devices.
Because of the nesting capabilities of IBM’s System z virtualization technology, the System z computer on which z/VM perceives it’s running might itself be mythical. A commonly seen nesting situation is the one where z/VM runs in a Logical Partition (LPAR) of a System z computer. A System z hardware facility called the LPAR hypervisor creates and manages logical partitions in much the same way that z/VM creates and manages virtual machines. System z machines contain special hardware that lets this commonly found two-level nesting arrangement run with almost no performance penalty.
Virtualization of Processors