Tuesday, 5 June 2012

Virtualization- With a slight 'XEN' to it

Virtualization- With a slight 'XEN' to it

The Xen hypervisor is the basic abstraction layer of software that sits directly on the hardware below any operating systems. It is responsible for CPU scheduling and memory partitioning of the various virtual machines running on the hardware device. The hypervisor not only abstracts the hardware for the virtual machines but also controls the execution of virtual machines as they share the common processing environment. It has no knowledge of networking, external storage devices, video, or any other common I/O functions found on a computing system.


Xen originated as a research project at the University of Cambridge, led by Ian Pratt, senior lecturer at Cambridge and founder of XenSource, Inc. This company now supports the development of the free software project and also sells enterprise versions of the software. The first public release of Xen occurred in 2003. Citrix Systems acquired XenSource, Inc in October 2007 and subsequently renamed Xensource's products under the Citrix brand:
  • XenExpress became "XenServer Express Edition" and "XenServer OEM Edition" (embedded hypervisor)
  • XenServer became "XenServer Standard Edition"
  • XenEnterprise became "XenServer Enterprise Edition"
Subsequently the product lines have been renamed XenServer (Free), Essentials for XenServer Enterprise, and Essentials for XenServer Platinum.

Types of virtualization

  • Paravirtualization, requiring porting of guest systems

On most CPUs, Xen uses a form of virtualization known as paravirtualization, meaning that guests run a modified operating system using a special hypercall ABI instead of certain architectural features. Through paravirtualization, Xen can achieve high performance even on its host architecture (x86) which has a reputation for non-cooperation with traditional virtualization techniques.
On x86, the Xen host kernel code runs in Ring 0, while the hosted domains run in Ring 1 or in Ring 3.
  • Hardware-assisted virtualization, allowing for unmodified guests

Both Intel and AMD have contributed modifications to Xen to support their respective Intel VT-x and AMD-V architecture extensions. Though these technologies differ quite substantially in their implementation and instruction sets, Xen manages them via a common abstraction layer, enabling unmodified guest operating systems to run within Xen virtual machines, starting with Xen 3.0.
This development allows the virtualization of proprietary operating systems (such as Microsoft Windows), since the guest system's kernel does not require modification when the host runs on Intel VT-x or AMD-V hardware.

Hardware-assisted virtualization (HVM) offers new instructions to support direct calls by a paravirtualized guest/driver into the hypervisor, typically used for I/O or other so-called hypercalls. It also provides additional execution modes: "root mode" and "non-root mode". Both of these modes have Rings 0-3; the Xen host operates in root mode and has access to the real hardware, while the unmodified guest operates in Rings 0-3 of non-root mode, with its "hardware" accesses under complete control of the hypervisor.
Xen-HVM has device emulation based on the QEMU project to provide I/O virtualization to the virtual machines. The system emulates hardware via a patched QEMU "device manager" (qemu-dm) daemon running as a backend in dom0. This means that the virtualized machines see as hardware: a PIIX3 IDE (with some rudimentary PIIX4 capabilities), Cirrus Logic or vanilla VGA emulated video, RTL8139 or NE2000 network emulation, PAE, and somewhat limited ACPI and APIC support and no SCSI emulation.

Virtual machine migration

Administrators can "live migrate" Xen virtual machines between physical hosts across a LAN without loss of availability.

During this procedure, the LAN iteratively copies the memory of the virtual machine to the destination without stopping its execution. The process requires a stoppage of around 60–300 ms to perform final synchronization before the virtual machine begins executing at its final destination, providing an illusion of seamless migration. Similar technology can serve to suspend running virtual machines to disk and switch to another virtual machine, resuming the first virtual machine at a later date.