In previous articles, we examined virtualization from the standpoint of an entire machine, running an unmodified guest operating system. This time, we’ll explore virtualization options that don’t necessarily virtualize the entire machine. Rather, we’ll begin considering applications as increasingly more abstract collections of resources, and we’ll begin to look at how you can re-factor your workload into logical components and concentrate on consolidating and virtualizing those, rather than physical components of your computing infrastructure.
Paravirtualization, usually in the context of Xen, is a hot topic in the x86 and x86_64 world. Paravirtualization is much like full-instance virtualization, except that the guest operating system is fully aware it’s running in a virtual environment and can exploit that relationship.
The gap between full-instance virtualization and paravirtualization is closing fast. Xen, for instance, required a modified Windows or Linux kernel to run, up until processors with Intel’s VT (or Amd’s Amd-V) extensions became widely available. however, if Xen is running on a processor with these extensions, it can exploit hardware features for virtualization, and perform what is, for all intents and purposes, full-instance virtualization.
on the other hand, almost all successful full-instance virtualization solutions provide for some measure of paravirtualization as well, if we mean simply the ability to detect that the “hardware” is a virtualized container of some sort and to exploit it. In z/Vm, for instance, CmS—the interface by which users typically interact with the system— is a single-user operating system that can only run via paravirtualization: Its I/o operations depend on Vm-specific dIAGnoSE codes. In Vmware, although it’s possible to run with no paravirtualization at all, common guest operating systems have the Vmware tools package available to them, which provides accelerated video and network functions and makes the system more responsive to the user and less hungry for host resources.
The distinction is muddied still further by the inclusion of a generic hypervisor layer into the Linux kernel (as of 2.6.20 and 2.6.21), which is intended to provide support services for a broad range of hypervisor technologies. Recent builds of Linux using these kernels display a “steal percentage,” which represents hypervisor overhead. Linux users in the x86 world are finally coming to see what we in the System z world have known for years: Tuning guests in a hypervisor environment can be counterintuitive to those used to the operating system actually owning the hardware on which it’s running. The addition of a kernel-level Application Program Interface (API) layer to Linux ought to enable much more virtualization-friendly applications on Linux, regardless of architecture.
Paravirtualization and the advent of virtualization extensions in current Intel and Amd chipsets promise to make the next year quite exciting for sites doing virtualization in the x86 and x86_64 world. Vmware may not lose its position as the clear market leader, but expect products built on top of Xen or QEmU, exploiting VT or Amd-V, to pose a serious challenge to it for the first time.
To this point, we’ve been considering virtualization as a way to present an entire machine. now we’re going to consider virtualization as a more abstract way to present not entire computers, but generic computing resources. This is a big conceptual step, and it requires a change in viewpoint. Perhaps the easiest way to illustrate this changed viewpoint is through a simple, common example: virtualized storage. We’ll begin in the System z world and then extend it to the open systems world.
Disk and Network Virtualization