Paravirtualization

Share on Facebook Share on Twitter Email
Top

The modification of the source code of an operating system in order to run as a guest operating system in a specific virtual machine environment. Calls to the hardware from the guest OS are replaced with calls to the virtual machine monitor (VMM). For example, several operating systems, such as Linux, OpenBSD, FreeBSD and OpenSolaris, have been paravirtualized for the Xen virtual machine monitor.

Paravirtualization Vs. Emulation

The guest OS can run as is without modification if the VMM emulates the hardware. In this case, the calls from the guest OS drivers to the hardware are intercepted and managed by the VMM, which redirects them to the real drivers. In addition, calls from the guest OS to the virtual memory page tables are intercepted and managed by the VMM. Emulation enables any guest OS to run intact, but emulation is slower than if the guest OS were paravirtualized.

Paravirtualization may be an option. If support for virtual machines is present in the CPU hardware, the guest OS may not need modification. For example, prior to the virtualization circuits built into x86 CPUs, the Xen VMM required the guest OS to be modified. If Xen runs in later Intel VT or AMD-V CPUs, a guest OS can run as is. See virtual machine monitor, virtual machine, hardware virtualization and Xen.

Emulated Hardware
Just like running in a non-virtualized computer, a non-paravirtualized guest OS communicates with the hardware as usual. The VMM presents a "device model" to the guest OS, which emulates the hardware. In these illustrations and the one following, the emphasis is on the device drivers. Paravirtualization also refers to modifying the calls to the virtual memory tables.

Paravirtualized Guests
In a paravirtualized OS, the drivers are replaced with calls to the VMM interface. This example shows one VMM model. For more VMM architectures, see virtual machine monitor.

Download Computer Desktop Encyclopedia to your PC, iPhone or Android.

Wikipedia on Answers.com:

Paravirtualization

Top

In computing, paravirtualization is a virtualization technique that presents a software interface to virtual machines that is similar but not identical to that of the underlying hardware.

The intent of the modified interface is to reduce the portion of the guest's execution time spent performing operations which are substantially more difficult to run in a virtual environment compared to a non-virtualized environment. The paravirtualization provides specially defined 'hooks' to allow the guest(s) and host to request and acknowledge these tasks, which would otherwise be executed in the virtual domain (where execution performance is worse). A successful paravirtualized platform may allow the virtual machine monitor (VMM) to be simpler (by relocating execution of critical tasks from the virtual domain to the host domain), and/or reduce the overall performance degradation of machine-execution inside the virtual-guest.

Paravirtualization requires the guest operating system to be explicitly ported for the para-API — a conventional OS distribution which is not paravirtualization-aware cannot be run on top of a paravirtualizing VMM. However, even in cases where the operating system cannot be modified, still components may be available that enable many of the significant performance advantages of paravirtualization; for example, the XenWindowsGplPv project provides a kit of paravirtualization-aware device drivers, licensed under the terms of the GPL, that are intended to be installed into a Microsoft Windows virtual-guest running on the Xen hypervisor.[1]

Contents

History

Paravirtualization is a new term for an old idea. IBM's VM operating system has offered such a facility since 1972[2] (and earlier as CP-67). In the VM world, this is referred to as a "DIAGNOSE code", because it uses an instruction code used normally only by hardware maintenance software and thus undefined.

The Parallels Workstation operating system calls its equivalent a "hypercall". All are the same thing: a system call to the hypervisor below. Such calls require support in the "guest" operating system, which has to have hypervisor-specific code to make such calls.

The term "paravirtualization" was first used in the research literature in association with the Denali Virtual Machine Manager.[3] The term is also used to describe the Xen, L4, TRANGO, VMware, Wind River and XtratuM hypervisors. All these projects use or can use paravirtualization techniques to support high performance virtual machines on x86 hardware by implementing a virtual machine that does not implement the hard-to-virtualize parts of the actual x86 instruction set[citation needed].

A hypervisor provides the virtualization abstraction of the underlying computer system. In full virtualization, a guest operating system runs unmodified on a hypervisor. However, improved performance and efficiency is achieved by having the guest operating system communicate with the hypervisor. By allowing the guest operating system to indicate its intent to the hypervisor, each can cooperate to obtain better performance when running in a virtual machine. This type of communication is referred to as paravirtualization.

In 2005, VMware proposed a paravirtualization interface, the Virtual Machine Interface (VMI), as a communication mechanism between the guest operating system and the hypervisor. This interface enabled transparent paravirtualization in which a single binary version of the operating system can run either on native hardware or on a hypervisor in paravirtualized mode. In September 2009, VMWare announced that VMI would be retired from future products.[4]

Linux paravirtualization support

At the USENIX conference in 2006, a number of Linux development vendors (including IBM, VMware, Xen, and RedHat) collaborated on an alternative form of paravirtualization, initially developed by the Xen group, called "paravirt-ops".[5] The paravirt-ops code (often shortened to pv-ops) was included in the mainline Linux kernel as of the 2.6.23 version, and provides a hypervisor-agnostic interface between the hypervisor and guest kernels. Distribution support for pv-ops guest kernels appeared starting with Ubuntu 7.04 and RedHat 9. Xen hypervisors based on any 2.6.24 or later kernel support pv-ops guests, as does VMware's Workstation product beginning with version 6.[6]

See also

References

  1. ^ "XenWindowsGplPv". Xen Wiki. http://wiki.xensource.com/xenwiki/XenWindowsGplPv. Retrieved 2010-02-03. "These drivers allow Windows to make use of the network and block backend drivers in Dom0, instead of the virtual PCI devices provided by QEMU. This gives Windows (in theory) a substantial performance boost, and most of the testing that has been done confirms that." 
  2. ^ "VM History and Heritage". IBM. http://www.vm.ibm.com/history/. Retrieved 2007-10-10. 
  3. ^ A. Whitaker, M. Shaw, and S. D. Gribble, "Denali: Lightweight Virtual Machines for Distributed and Networked Applications", Univ. of Washington Technical Report 02-02-01, (2002). (Available from Denali publications, technical reports, and talks)
  4. ^ Update: Support for guest OS paravirtualization using VMware VMI to be retired from new products in 2010-2011 http://blogs.vmware.com/guestosguide/2009/09/vmi-retirement.html
  5. ^ http://wiki.xensource.com/xenwiki/XenParavirtOps
  6. ^ http://www.vmware.com/company/news/releases/050907PV.html

External links


Post a question - any question - to the WikiAnswers community:

Copyrights:

Mentioned in

full virtualization (technology)
Hyper-V (technology)
paravirtualization (technology)
Xen (technology)
virtual (technology)