Xen Project: История и Архитектура Гипервизора

the virtualization software
Type 1 hypervisor

Xen Project runs in a more privileged CPU state than any other software on the machine, except for firmware. Responsibilities of the hypervisor include memory management and CPU scheduling of all virtual machines ("domains"), and for launching the most privileged domain ("dom0") the only virtual machine which by default has direct access to hardware. From the dom0 the hypervisor can be managed and unprivileged domains ("domU") can be launched. The dom0 domain is typically a version of Linux or BSD. User domains may either be traditional operating systems, such as Microsoft Windows under which privileged instructions are provided by hardware virtualization instructions (if the host processor supports x86 virtualization, e. g., Intel VT x and AMD V), or paravirtualized operating systems whereby the operating system is aware that it is running inside a virtual machine, and so makes hypercalls directly, rather than issuing privileged instructions. Xen Project boots from a bootloader such as GNU GRUB, and then usually loads a paravirtualized host operating system into the host domain (dom0).

Xen originated as a research project at the University of Cambridge led by Ian Pratt, a senior lecturer in the Computer Laboratory, and his PhD student Keir Fraser. The first public release of Xen was made in 2003, with v1.0 following in 2004. Soon after, Pratt and Fraser along with other Cambridge alumni including Simon Crosby and founding CEO Nick Gault created XenSource Inc. to turn Xen into a competitive enterprise product. To support embedded systems such as smartphone/ IoT with relatively scarce hardware computing resources, the Secure Xen ARM architecture on an ARM CPU was exhibited at Xen Summit on April 17, 2007, held in IBM TJ Watson. The first public release of Secure Xen ARM source code was made at Xen Summit on June 24, 2008 by Sang bum Suh, a Cambridge alumnus, in Samsung Electronics. On October 22, 2007, Citrix Systems completed its acquisition of XenSource, and the Xen Project moved to the xen. org domain. This move had started some time previously, and made public the existence of the Xen Project Advisory Board (Xen AB), which had members from Citrix, IBM, Intel, Hewlett Packard, Novell, Red Hat, Sun Microsystems and Oracle. The Xen Advisory Board advises the Xen Project leader and is responsible for the Xen trademark, which Citrix has freely licensed to all vendors and projects that implement the Xen hypervisor. Citrix also used the Xen brand itself for some proprietary products unrelated to Xen, including XenApp and XenDesktop. On April 15, 2013, it was announced that the Xen Project was moved under the auspices of the Linux Foundation as a Collaborative Project. The Linux Foundation launched a new trademark for "Xen Project" to differentiate the project from any commercial use of the older "Xen" trademark. A new community website was launched at xenproject. org as part of the transfer. Project members at the time of the announcement included: Amazon, AMD, Bromium, CA Technologies, Calxeda, Cisco, Citrix, Google, Intel, Oracle, Samsung, and Verizon. The Xen project itself is self governing. Since version 3.0 of the Linux kernel, Xen support for dom0 and domU exists in the mainline kernel.

Version Release date Notes 1.0 2003 10 02 2.0 2004 11 05 Live migration of PV guests. 3.0 2005 12 05 Supports the Intel VT technology for HVM guests. Support for the Intel IA 64 architecture. The releases up to 3.0.4 also added:
Support for the AMD SVM virtualization extensions. Support for the PowerPC architecture. Graphical framebuffer support for paravirtualized guests. 3.1 2007 05 18 Live migration for HVM guests, XenAPI 3.2 2008 01 17 PCI passthrough and ACPI S3 standby mode for the host system. 3.3 2008 08 24 Improvements for the PCI passthrough and the power management. Xen ARM hypervisor source code released for ARM CPU support 3.4 2009 05 18 Contains a first version of the "Xen Client Initiative", shortly XCI. 4.0 2010 04 07 Makes it possible to use a dom0 Linux kernel, which has been implemented by using PVOps. A Linux kernel of version 2.6.31 has been modified for this purpose, because the official Linux kernel actually does not support the usage as dom0 kernel (date July 2010). 4.1 2011 03 25 Some of the improvements: Support for more than 255 processors, better stability. Linux kernel v2.6.37 and onward support usage as dom0 kernel. 4.2 2012 09 08 XL became the default toolstack. Support for up to 4095 host processors and up to 512 guest processors. 4.3 2013 07 09 Experimental ARM support. NUMA aware scheduling. Support for Open vSwitch. 4.4 2014 03 10 Solid libvirt support for libxl, new scalable event channel interface, hypervisor ABI for ARM declared stable, Nested Virtualization on Intel hardware. 4.5 2015 01 17 With 43 major new features, 4.5 includes the most updates in the project's history. Improved: security, live migrations, performances and workload. Hardware support (ARM and Intel Xeon).4.8.1April 12, 20174.9June 28, 2017Xen Project 4.9 Release Notes4.10December 12, 2017Xen Project 4.10 Release Notes4.11July 10, 2018Xen Project 4.11 Release Notes4.12April 2, 2019Xen Project 4.12 Release Notes4.13December 18, 2019Xen Project 4.13 Release Notes4.14July 24, 2020Xen Project 4.14 Release Notes4.15April 8, 2021Xen Project 4.15 Release Notes4.16December 2, 2021Xen Project 4.16 Release Notes4.17December 14, 2022Xen Project 4.17 Release Notes4.18November 23, 2023Xen Project 4.18 Release Notes

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, "freezing" their running state for resumption at a later date. Xen can scale to 4095 physical CPUs, 256 VCPUs per HVM guest, 512 VCPUs per PV guest, 16 TB of RAM per host, and up to 1 TB of RAM per HVM guest or 512 GB of RAM per PV guest.