This article can also be found in the Premium Editorial Download "Virtual Data Center: Wanted: Well-rounded IT professionals."
Download it now to read this article plus other related content.
Virtualization doesn't require a hypervisor. Imagine a virtualization infrastructure completely devoid of a hypervisor. Having no hypervisor eliminates the need for driver emulation. Getting rid of driver emulation means faster performance. Faster performance means more virtual machines that can be run simultaneously. And more simultaneous virtual machines nets you higher density, all of which means more bang for your virtualization dollar.
This may sound like fantasy, but all virtualization solutions don't always follow the traditional hypervisor-based architecture. One class of virtualization architectures, OS virtualization, operates in exactly this way. To quote from my recent e-book,
The Shortcut Guide to Selecting the Right Virtualization Solution, OS virtualization leverages "a host OS and residing virtual machines [that] are completely and wholly segregated from each other. What's different [with OS Virtualization] is that the host's OS becomes the base OS from which all its hosted virtual machines start their existence. Each hosted virtual machine is almost like a virtual snapshot of the software that makes up the host."
Deltas, VEs and containers
One example of software that leverages this architecture is Parallels Virtuozzo Containers. This software enables the creation of virtual environments (VEs), each of which is operationally similar to what we commonly think of as a virtual machine.
Each VE running atop a virtual host is made up of the files, registry keys and other configurations of its host plus the "deltas" that make that VE unique. This layering effect of VEs atop virtual hosts means that the size of individual VEs are dramatically smaller when compared with virtual servers created through other virtualization software.
Consider the typical Windows server: A freshly-built Windows Server instance can consume upwards of four gigabytes of space after installation to store its needed files and other configuration elements. This is the case whether that server is encapsulated into a virtual machine or is installed directly to physical hardware. Every additional Windows server consumes yet another four gigabytes. But think about the individual differences between two freshly-installed Windows servers. Other than their names, some SID information and a few other characteristics, the vast majority of each server's four gigabytes is replicated from server instance to server instance.
Using OS Virtualization, the process to create a new server starts by creating a type of change database, called a container, on the host. Within this container are stored the differences between the host OS and whatever individual configurations are late made to the VE. Because only changes are logged, the differences between individual VEs residing atop a virtual host can be measured in megabytes rather than gigabytes. Once created, the VE is run by the host as a fully-independent operating system instance.
Benefits of OS virtualization
This type of delta-based architecture has its own benefits. First and foremost, the sheer amount of storage space required to host a given number of VEs can be significantly smaller than what is required for hypervisor-based virtual servers. In the hypervisor-based virtualization environment, each new virtual server requires the same four gigabytes of space. Thus, bringing ten virtual servers on-line requires 40 gigabytes of space, plus the storage space required for the host itself. With OS virtualization, each freshly-built VE can take only about 200 megabytes. Thus, to bring ten VEs online requires only about two gigabytes of storage space. This twenty-fold savings in disk space is particularly effective when considered with the high-end, high-availability and high-cost storage usually recommended for virtualization environments.
Another benefit to OS virtualization is that it doesn't use driver emulation as with some hypervisor-based virtualization products. Individual virtual machines must have a set of tools installed into the virtual machine with driver emulation. These tools update the drivers for common hardware components to work within the virtualization environment. With hypervisor-based virtualization, all drivers are exactly the same across all virtual machines, but the internal translation of instructions required to convert requests from the virtual driver to the real driver on the physical machine involves a processing overhead. Using OS Virtualization, the drivers that make up each VE are the exact same drivers used by the host. Since there is no requirement for driver translation, the overall performance for all hosted VEs is comparatively improved.
Last but not least are the benefits to management. Because residing VEs are components of the host, changes to the host can be automatically and immediately manifested into each residing VE. One example of this has to do with the monthly Windows patching process. With virtual machines, the patching process treats each virtual machine like a physical machine, updating each independently of each other. Using VEs, once the host has been patched, those updates are immediately seen within each VE. Thus, the number of administration touch points is significantly reduced.
There are a few examples of how OS virtualization can be a useful addition to the IT environment. In my next article, I'll talk about some of the specific areas where this alternative to hypervisor-based virtualization can fit particularly well into your environment.
ABOUT THE AUTHOR:Greg Shields, MVP, is a co-founder and IT guru with Concentrated Technology (www.concentratedtechnology.com) with nearly 15 years of IT architecture and enterprise administration experience. He is an IT trainer and speaker on such IT topics as Microsoft administration, systems management and monitoring, and virtualization. His recent book Windows Server 2008: What's New/What's Changed is available from SAPIEN Press.
This was first published in June 2008