Virtualization
Operating systems present a more-or-less standardized interface to programs that run on them, so that those programs need not worry about grisly hardware details. The ideal situation allows an unchanged program to run on different hardware mediated through the OS. In practice, it never works quite that well, but the notion of an abstract hardware interface is well ingrained these days.
Virtualization takes this to the limit by emulating the underlying hardware, with the result that a program written for one hardware architecture can run on an entirely different system. Aficionados of old video games can run the original, unchanged code on emulators that simulate the CPU and its peripheral devices with sufficient speed that the programs actually run faster than on the original game box.
Performance gains like that aren't generally the case, particularly when emulating hardware that's roughly as complex as the actual CPU running the emulator. For example, an 8-bit Z80 microcontroller emulator runs at blistering speed on any current x86 CPU, but trying to emulate, say, a 32-bit Blackfin DSP just isn't a productive use of anyone's time.
The Intel 80286 CPU introduced a "Virtual 8086" mode that could run unmodified 8086 programs at essentially full speed. The trick was to run nearly all instructions on the actual hardware, with a supervisor program gaining control on hardware interrupts and system calls. Because the existing 8086 instruction set was a proper subset of the new 80286 architecture, that approach worked surprisingly well.
Several talks described the Xen hypervisor, which emulates an x86 CPU using a technique called "paravirtualization" to create a virtual machine (VM) that looks precisely like the underlying hardware. The operating system within that VM must be aware of (and cooperate with) the hypervisor, but user programs run at essentially full speed because those instructions execute without software intervention. The net performance hit seems to be a few percent at worst, far better than a pure software emulator that must grind out the results of every instruction.
The hypervisor gains control on timer ticks, hardware interrupts, and some system calls, handles the situation, and returns control back to the VM. If this sounds like a rudimentary operating system, that's precisely what it is, except that it's maintaining the state of a simulated hardware environment rather than controlling user programs.
Of course, after you get one virtual machine running, the hypervisor can juggle several VMs on the same CPU hardware by time-sharing the hardware, handling global memory allocation, and enforcing isolation. I/O passes through the hypervisor, which must present the dual illusions that the VMs are in control of the I/O and that the I/O goes directly to the VMs.
Suppose you start with four blades running single applications at 20 percent utilization. Set up a hypervisor on one blade, create four VMs that timeshare the underlying hardware, and suddenly you have one blade running at 80+ percent utilization and three idle blades.
Shazam! Dispose of 75 percent of your hardware or find something remunerative with all that spare capacity.
VMs do not come up smelling entirely of roses. Funneling sufficient I/O through a single hardware server, providing enough physical memory, and sysadmin duties on the OS image within each VM can be a challenge. However, the economics seem to be compelling enough to attract plenty of high-level attention.
Hold the thought of an entire OS running within a VM for a moment.
