Commercial grade virtualization technology was developed by IBM in the mid-1960’s to allow the System/360 Model 67 hardware to support multiple, concurrent guest virtual machines, each able to run a single-user operating system. IBM did this by developing two individual operating systems, Virtual Machine (VM) and Conversational Monitor System (CMS), commonly referred to as VM/CMS. VM created and controlled virtual machines and CMS, a single-user operating system, ran inside the virtual machine, delivering to each user access to underlying system resources.
More recently, virtualization technology research and product development has resurged with a focus on the x86 (32-bit and 64-bit) platform. In the last few months, both Intel and AMD released x86 processor revisions with new instructions and extensions specifically targeted to enable hardware-assisted virtualization. Although differing in implementation details, Intel Virtualization Technology (VT) and AMD Virtualization (AMD-V) provide hardware virtualization features that can be leveraged by software vendors to extend their virtualization solution architectures.
Software Virtualization
Software virtualization includes various techniques to enable multiple secure, isolated partitions to be hosted on a single physical system, sharing resources. Different approaches provide different levels of partition density, scalability, performance, and breadth of operating system flavors that can be concurrently supported on a given platform.
Machine-Level Virtualization
At the foundation of a machine level virtualization solution is a “virtual machine monitor” (VMM) responsible for the creation, isolation, and preservation of virtual machine state, as well as orchestration of access to system resources. VMM design is usually tied to a specific processor architecture, so while it allows running various and unmodified operating systems inside a virtual machine, you are usually limited to operating systems that can natively run on the physical system processor.
There are variations of VMM implementations. Some VMMs runs above a host operating system like the Java VM. Other VMMs run as a peer to the host operating system like Microsoft Virtual Server or VMWare GSX Server. Most vendors are now implementing VMMs that run directly above the hardware, below all virtual machine partitions. These are more commonly referred to as "hypervisors". Examples are Microsoft Windows Server Virtualization and VMWare ESX Server.
In terms of performance, the hypervisor is capable of achieving higher levels of efficiency and, therefore, greater virtual machine density because it has direct access to the hardware.
Full Virtualization
Using full virtualization, a complete virtual system is created and maintained by the VMM to abstract the real hardware from the virtual machine. This allows an operating system to execute in a virtual machine without any modification. Virtual Server 2005 R2 uses this technique along with binary translation, a process that allows the VMM to handle non-virtualizable x86 instructions, to provide system virtualization on the pre- Intel VT and AMD-V x86 processor architectures.
A benefit of full virtualization and the approach of decoupling the physical hardware from the virtual machine is the ability to easily move virtual machines between servers with different physical configurations. This flexibility comes with a performance hit due to overhead associated with the maintenance of each virtual machine state, and latency introduced with binary translation.
Native Virtualization
Native virtualization depends on a virtualizable processor architecture, such as is available with the x86 Intel-VT and AMD-V series. These processors implement new execution modes, instructions, and data constructs in hardware that are designed to reduce the complexity of the VMM.
With native virtualization, the VMM is no longer required to maintain virtual machine resource characteristics and state in software; these functions now belong to the processor hardware and logic. Just as in the case of full virtualization, operating systems can run unmodified inside the virtual machines. Windows Server Virtualization will use this method to run legacy operating systems.
This type of implementation has many potential benefits ranging from the simplification of the VMM architecture to significant performance improvements due to reduction of software-based overhead. By lowering the virtualization overhead, a greater partition density can be achieved on any single system.
Paravirtualization
Paravirtualization was developed as an alternative to using binary translation to handle x86 non-virtualizable instructions. In this approach, guest operating systems require modification to enable “hypercalls” from the virtual machine to the hypervisor. Instead of the hypervisor (or VMM) having to translate a potentially unsafe instruction from a guest operating system to guarantee system state integrity, a structured hypercall is made from the guest to the hypervisor to manage the system state changes. A strict paravirtualization implementation offers greater performance on standard x86 hardware by eliminating the need for costly operations incurred using full virtualization and binary translation. However, it does so at the cost of limiting unmodified guest operating system support and migration of virtual machines back to a physical server. Recognizing these limitations, newer virtualization solutions based on paravirtualization implementations usually leverage hardware virtualization to host unmodified operating systems. This allows a broader range of support, extending to legacy operating systems that are unlikely to be modified, while allowing newer operating systems to be updated, taking advantage of enhancements and performance gains offered through paravirtualization.
Operating System-Level Virtualization
Operating system-level virtualization is based on abstraction of the operating system layer to support multiple, isolated partitions, or virtual environments (VE) on a single instance host operating system. The virtualization is accomplished by multiplexing access to the kernel while ensuring that no single VE is able to take down the system.
This technique results in very low virtualization overhead and can yield high partition density. However, there are two major drawbacks with this type of solution. The first drawback is the inability to run a heterogeneous operating system mix on a given server because all partitions share a single operating system kernel. The second big drawback, also caused by the shared kernel model, is the lack of support for running a mixed 32-bit and 64-bit workload. In addition, any operating system kernel patch affects all virtual environments. For these reasons, operating system-level virtualization tends to work best for largely homogeneous workload environments.
Application-Level Virtualization
Application-level virtualization is a technology that is geared towards partitioning and isolating client side applications running on the local operating system. Applications are isolated in a virtual environment layered between the operating system and application stack. The virtual environment loads prior to the application, isolates the application from other applications and the operating system, and prevents the application from modifying local resources such as files and registry settings. Applications can read information from the local system registry and files, but writeable versions of these resources are maintained inside the virtual environment. In fact, the application may never be locally installed on the desktop; instead the code bits can be dynamically streamed and cached in the virtual environment as new portions of the application are needed.
There are several benefits provided by application-level virtualization. Of most importance are increased stability of the local desktop, simple application removal without changes to the local environment that could negatively affect other applications, and seamless, conflict-free, side-by-side execution of multiple instances of an application. One or more additional servers may be required to maintain application distributions, application streaming to the desktop, and other enterprise-wide functions.