Various mechanisms exist for managing virtual machines in a virtualization platform. One management technique is to deploy a virtual machine monitor (VMM) on the system. There are two common architectures for virtual machine monitors. The first is a hypervisor architecture, in which a privileged hypervisor (virtual machine monitor) controls all other software in a system. The hypervisor must contain native drivers and models for all devices which it wishes to provide to software running in virtual machines (VMs) (referred to herein as guest VMs). This necessity has been a problem with this architecture of VMM. In the hypervisor architecture, the VMM has full control over the underlying platform, and may limit guest VM access to the platform hardware. The hypervisor has access to all of the hardware. A guest VM may directly access the hardware only if the hypervisor permits it. A hypervisor system may prevent guest VMs from accessing the hardware directly, if designed to do so. When the hypervisor is implemented, device drivers for each physical device must also be implemented. If the physical device changes (e.g., it is replaced by a different version of the device) then a new or replacement device driver must be present in the hypervisor. Typically, all operating systems run in VMs. The VMs may be privileged in different ways. For example, VM1 may have access to device #1 while VM2 has access to device #2.
The second common architecture for a VMM is a hosted VMM. In this architecture, the VMM is tied intimately to a hosting operating system (OS) and uses the services provided by the hosting OS to perform its virtualization functions. In this architecture, the hosting OS has full control over the platform; the VMM component has control of the platform's guest VMs. In other words, the VMM component does not directly control the underlying hardware. The VMM accesses the underlying hardware using the services provided by the hosting OS. The stability of the VMM is only as good as that of the hosting OS. The hosting OS contains all of the necessary device drivers. The VMM must implement models for all devices presented to the guest VMs. VMMs implemented with this high-level architecture suffer portability constraints because of their reliance on a particular hosting OS. Additionally, there is a reliance on the hosting OS to perform scheduling. The VMM controls scheduling of the guest VMs, but it does not control how much time it is given by the hosting OS. For instance, it may not be possible to request that the hosting OS awaken the VMM every millisecond.
Some virtualization products exist today. For instance, a hypervisor-based architecture, ESX Server, is available from VMware®, Inc. Microsoft® and VMware®, Inc. both provide host-based architecture software: Microsoft offers VirtualPC and VirtualServer, and VMWare® offers VMWorkstation and GSX Server. Currently, these software systems may be loaded on a server or personal computer (PC) that does not have hardware virtualization support.