VMware white paper
Table of Contents
Introduction........................................................................................................................................... 3 Architectural.Considerations................................................................................................................ 3 CPU.virtualization.................................................................................................................................. 4 Memory.Management........................................................................................................................... 5 I/O.Virtualization.................................................................................................................................... 6 A.Note.on.Performance......................................................................................................................... 7 Consolidation.ratio.and.server.utilization.......................................................................................... 9 Quality.of.Service.for.Individual.Virtual.Machines............................................................................ 9 Workload.Suitability.............................................................................................................................. 9 Operating.System.Support................................................................................................................... 10 Virtual.Hardware.Features.................................................................................................................... 11 Application-Specific.Performance.Tuning.......................................................................................... 11 ISV.Support............................................................................................................................................. 11 Rapid.Restart.and.Provisioning........................................................................................................... 12 Enterprise.Readiness............................................................................................................................. 12 Certification............................................................................................................................................ 12 Operational.Fit....................................................................................................................................... 13 Management.and.the.Market............................................................................................................... 13 Conclusion.............................................................................................................................................. 13
VMware white paper
Virtualization: architectural Considerations and Other evaluation Criteria
Introduction
Of the many approaches to x86 systems virtualization available in the market today, the hypervisor architecture--in which virtual machines are managed by a software layer that is installed on bare metal--has gained the greatest market acceptance. This fact has translated into rapid growth and a large and expanding customer base for VMware, which pioneered x86 hypervisors in 001 with the launch of VMware® ESX Server. It is no wonder, then, that the hypervisor market has attracted attention recently from Microsoft1 and the usual assortment of venture-funded startups, including the recently created XenSource. Competitive marketing notwithstanding, the facts in this market are as follows: · The VMware product architecture is rooted in its experience in solving real-world customer problems.. The choices VMware has made in its hypervisor-based ESX Server reflect the practical focus on offering the highest levels of performance, reliability and compatibility. In contrast, both XenSource and Microsoft have chosen architectural paths that allow them to get products to market more quickly. These products may satisfy a limited set of use cases, but have yet to grapple with the architectural issues of building an enterprise-class hypervisor. As they attempt to broaden their applicability, they will encounter the same real-world issues that VMware did when it first entered the market. The difference, of course, is that VMware solved these problems long ago. · VMware offers a wide range of production-tested solutions, and provides a comprehensive set of innovative technologies to augment the basic partitioning functions of its hypervisor. While an architectural comparison is of interest to those trying to predict the long-term direction of virtualization technology, what ultimately matters to users are the solutions that they deploy based on virtualization. Today VMware offers products that customers are actively using in production deployments to meet their business demands. · VMware is the only enterprise-ready hypervisor available.. Product features aside, vendors must answer questions such as: How well will the products work with what the customer already has? How well supported is it? And how manageable is it? Users rightfully demand a certain level of enterprise readiness before they broadly deploy a technology in production. As with solutions, enterprise readiness is a function of product maturity. VMware has customer references that attest to the maturity of VMware based solutions. · This paper examines these issues--architecture, solution support and enterprise readiness--in greater detail.. Comparisons focus primarily on XenSource. Microsoft has not released their hypervisor product and therefore can not be compared at this time.
architectural Considerations
The x86 architecture was never designed for virtualization. Consequently, high-performance virtualization is difficult to achieve. There are three ways to address the problem of virtualizing the x86 architecture: · Transparent virtualization allows operating systems, or particular components of the operating system, to run inside virtual machines without modification. · Paravirtualization requires the operating system to be modified before it can run inside the virtual machine. Depending on the part of the operating system being changed, the modification may be expected and supported by the operating system vendor (e.g., new drivers) or not (e.g., changes to the kernel). · Hardware can provide explicit support for virtualization. To date such support is comparatively rare, but as virtualization has become a standard layer inside enterprise data centers, hardware vendors have responded with roadmaps promising such support. These methods are not mutually exclusive. In fact, it is a combination of all three, applied to the basic elements of the hypervisor--CPU, memory management and I/O--that will ultimately provide the greatest performance, reliability and compatibility to the end user.
1
In fact, in an unusual move for the industry giant, Microsoft has gone so far as to virtually abandon its existing non-hypervisor product, Virtual Server.
VMware white paper
CPU virtualization
The CPU virtualization used by VMware employs direct execution.and binary translation. These transparent virtualization techniques ensure that the vast majority of CPU instructions are executed directly, with zero or low performance overhead. This use of transparent virtualization also ensures that the guest operating systems are run without modification, resulting in a high degree of operating system compatibility. XenSource's kernel-based paravirtualization helps to reduce the overhead that comes from virtualizing certain privileged CPU instructions, by modifying the operating system internals to avoid them altogether. Currently the industry is working on but have not shipped Linux distributions that support paravirtualization. When these are released customers will have to retest and requalify their solutions on these new distributions. Although hardware support in the form of Intel's Virtualization Technology (VT) and AMD's Pacifica hold the promise of hardware assist for CPU virtualization, it remains to be seen whether the silicon delivered can provide the same optimized performance that software already provides. In other words, although XenSource has announced plans to rely on hardware
assistance to run Windows (as there is no paravirtualized version of Windows), it is unlikely to match the performance of the transparent CPU virtualization used by VMware for some years. As previously noted, transparent virtualization, paravirtualization and hardware assist are not mutually exclusive. VMware has already announced its planned support for Intel's VT and AMD's Pacifica, and was in fact the first vendor to provide a working demonstration using VT at the Intel Developer Forum in April 005. VMware has also announced its intent to support paravirtualized operating systems when they are available from RedHat, Novell/Suse, and, eventually, Microsoft. Doing so ensures that VMware customers gain the performance benefits of paravirtualized operating systems like RHEL 5 and SLES 10 (both targeted in mid- to late 006), all without sacrificing the stability and performance of the ESX Server platform.
Figure 1: Virtualization Infrastructure Architecture
For the class of privileged CPU instructions that cannot be directly executed, VMware employs a form of binary translation that is small, compact, and serves a well-defined purpose.
This simplicity can be contrasted with the complexity of `optimized binary translators', such as the Dynamo system or the Transmeta processor.
For a vendor that uses transparent virtualization, these paravirtualized operating systems merely represent additional guest OSes that need to be supported. VMware's long tradition of heterogeneous operating system support ensures that adding this support will be straightforward.
VMware white paper
Memory Management
As with the CPU, the fundamental question in virtualization of memory is the extent to which the operating system needs to be changed to account for the fact that it is being virtualized, and the extent to which hardware support is required. The approach used by VMware makes use of shadow page tables, which provide a map between the guest operating system's virtual memory pages and the underlying physical machine pages. The shadow page tables are maintained by ESX Server and are used to efficiently virtualize memory access. As a result, neither operating system modification nor hardware support is a requirement, although the latter has some potential for performance enhancement. The implementation of shadow page table used by VMware optimizes caching of guest virtual address translations so that expensive hardware faults resulting from memory access are minimized. Dynamic binary translation is also used to keep the cost of MMU-related operations low. With shadow page tables, the virtual machine's linear addresses can be mapped directly to the real machine addresses, and accesses to memory can occur at native hardware speed. Shadow page tables also provide another important benefit. Because they insulate guest operating systems from their dependence on specific machine memory, they allow the hypervisor to optimize the use of that memory far beyond what an individual operating system is capable of doing. This "memory overcommitment" is not required for static partitioning, but is a key enabler for all other virtualization-based solutions. (See below for more details.) The XenSource approach does not use shadow page tables, except on a temporary basis when executing their version of VMotion, the ability to migrate a running virtual machine from one physical host to another without downtime. Instead, it provides partial access for the guest operating system directly to physical memory page tables, through kernel modifications. XenSource claims to have chosen this paravirtualized approach for performance reasons. The reality is probably somewhat different: without either binary translation or hardware virtualization assist, it is not possible to implement shadow page tables in a high-performance manner. As already noted, XenSource has not announced plans to provide binary translation, and neither Intel nor AMD have announced plans for the necessary type of hardware assist.
It is possible, of course, to implement shadow page tables in a low performance manner without binary translation or hardware assist.
5
