| Xen | |
|---|---|
| Xen ejecutando NetBSD y tres distribuciones de Linux | |
| Tipo de | servidor de virtualización |
| Desarrollador | El Proyecto Xen, XenSource, Inc. |
| Escrito en | C [1] |
| Sistema operativo | Linux , OpenSolaris , BSD |
| Primera edición | 2003 |
| ultima versión |
|
| Licencia | GNU GPL 2 [3] |
| Sitio web | xenproject.org |
| Archivos multimedia en Wikimedia Commons | |
Xen (pron. / ˈzɛn / ) es un hipervisor multiplataforma desarrollado en el Laboratorio de Computación de la Universidad de Cambridge y con licencia GPL . Características principales: soporte para el modo de paravirtualización además de la virtualización de hardware, el código mínimo del propio hipervisor debido a la eliminación del máximo número de componentes fuera del hipervisor.
Xen comenzó como un proyecto de investigación en la Universidad de Cambridge dirigido por Ian Pratt , quien luego se convirtió en el fundador de XenSource. La empresa apoyó el desarrollo de una versión de código abierto (xen) y simultáneamente vendió versiones comerciales del software denominadas XenServer y XenEnterprise.
El primer lanzamiento público de Xen fue en 2003. En octubre de 2007 , Citrix compró XenSource y renombró los productos:
Más tarde se les cambió el nombre a XenServer (gratis), Essentials for XenServer Enterprise y Essentials for XenServer Platinum.
El 22 de octubre de 2007, Citrix completó la adquisición de XenSource [4] y el proyecto gratuito se trasladó a xen.org.
El 21 de octubre de 2009, Citrix anunció que las versiones comerciales de XenServer serían completamente gratuitas [5] . Simon Crosby , ingeniero principal de la división de virtualización de Citrix, afirmó: “XenServer es 100 % gratuito y pronto será completamente de código abierto. No planeamos obtener ganancias [de esto] en absoluto” [6] ). Si bien existe una versión gratuita de Citrix XenServer, XenCenter (software de administración centralizada) no tiene código fuente, aunque está disponible para su descarga gratuita.
15 de abril de 2013 Xen estuvo bajo el ala de la Fundación Linux [1] Archivado el 19 de abril de 2013 en Wayback Machine .
| Versión | Fecha de lanzamiento | notas |
|---|---|---|
| 1.0 | 2003.10.02 [7] [8] | |
| 2.0 | 2004.11.05 [9] | Migración en vivo para máquinas invitadas paravirtuales |
| 3.0 | 2005.12.05 [10] [11] |
La versión 3.0.4 también agregó: |
| 3.1 | 2007.05.18 [15] | Migración en vivo para invitados HVM, compatibilidad con XenAPI |
| 3.2 | 2008.01.17 [16] | "Reenvío" PCI, modo "dormir" ACPI S3. |
| 3.3 | 2008.08.24 [17] | Mejoras en el reenvío PCI y la administración de energía. |
| 3.4 | 2009.05.18 [18] | Contiene la primera versión de la "Iniciativa de cliente Xen" (XCI). |
| 4.0 | 2010.04.07 [19] | Permite que los kernels de Linux se utilicen como dom0 utilizando el nuevo mecanismo PVOps. [veinte] |
| 4.1 | 2011.03.25 [21] | Soporte para más de 255 procesadores, estabilidad mejorada.( [22] ). |
| 4.2 | 2012.09.17 [23] | Compatibilidad con 4095 procesadores físicos (y hasta 512 virtuales), compatibilidad con varios segmentos PCI, seguridad y documentación mejoradas ( [24] ). |
| 4.3 | 2013.07.09 [25] | Soporte experimental para ARM. Contabilización de las características de la arquitectura NUMA en el planificador. Abra el soporte de vSwitch . |
| 4.4 | 2014.03.10 [26] | El soporte ARM ahora es estable. Soporte para libxl por la biblioteca libvirt. Nueva interfaz escalable para canales de eventos. Compatibilidad con la creación de entornos virtuales anidados en hardware Intel. Se eliminó la compatibilidad con hipervisores x86 de 32 bits e ia64 (itanium). |
| 4.5 | 2015.01.15 [27] | Toolstack ahora se reescribió en C y se llama xl o libxl, reemplazando por completo el viejo toolstack xend que estaba escrito en python. |
| 4.6 | 2015.10.13 [28] | |
| 4.7 | 2016.06.24 [29] | Mejoras: seguridad, migraciones en vivo, rendimiento y carga de trabajo. Soporte de hardware (ARM e Intel Xeon). [treinta] |
| 4.8.1 | 2017.04.12 [31] | |
| 4.9 | 2017.07.28 [32] | Notas de la versión del proyecto Xen 4.9 |
| 4.10 | 2017.12.12 [33] | Notas de la versión del proyecto Xen 4.10 |
| 4.11 | 2018.07.10 [34] | Notas de la versión del proyecto Xen 4.11 |
| 4.12 | 2019.04.02 [35] | Notas de la versión del proyecto Xen 4.12 |
La tecnología de máquinas virtuales permite ampliar la funcionalidad de los equipos de las siguientes formas:
El concepto central de un hipervisor es un dominio . Una copia en ejecución de una máquina virtual se denomina dominio. Si se reinicia la máquina virtual, su dominio finaliza (en el momento del reinicio) y aparece un nuevo dominio. Además, incluso durante la migración, el contenido se copia de un dominio a otro dominio. Así, durante su vida útil, casi todas las máquinas virtuales se encuentran a su vez en diferentes dominios. Xen opera solo con el concepto de dominio, y el concepto de "máquina virtual" aparece a nivel de administración (programas de aplicación que controlan el hipervisor).
Los dominios son de varios tipos. Los más famosos son dom0 y domU . dom0 es el primer dominio Xen lanzado, por lo general se crea y carga automáticamente inmediatamente después de cargar e inicializar el hipervisor. Este dominio tiene derechos especiales para controlar el hipervisor y, de manera predeterminada, se puede acceder a todo el hardware de la computadora desde dom0. De hecho, dom0 es donde vive el software que administra Xen. dom0 siempre está solo.
domU es un dominio miembro (abreviatura de dominio de usuario) que contiene el dominio de las máquinas virtuales en ejecución. Por lo general, no tiene acceso a hardware real y es la "carga útil" del sistema de virtualización. A diferencia de dom0, domU puede ser muchos (generalmente varias docenas).
stub-domain: un dominio que ejecuta un sistema operativo muy especializado que proporciona trabajo con cualquier back-end de hardware o controlador. Es una evolución del modelo de seguridad Xen.
constructor de dominios (constructor de dominios): un programa que crea domU (carga el código necesario en él y le dice al hipervisor que se ejecute). Además de construir el dominio, generalmente se ocupa de conectar y configurar los dispositivos virtuales disponibles para la máquina virtual. También es responsable del proceso de migración de una máquina virtual de un host a otro.
La paravirtualización es la adaptación del núcleo de un sistema operativo ejecutable para trabajar en conjunto con Xen, generalmente abreviado como PV. Le permite lograr un rendimiento muy alto debido a la falta de emulación de "hardware real", la simplicidad de las interfaces y teniendo en cuenta la existencia de un hipervisor al ejecutar llamadas al sistema en el código del kernel. La ejecución de operaciones privilegiadas está prohibida, en lugar de ellas, se realizan hiperllamadas ( ing. hypercalls ): solicitudes del kernel del sistema operativo invitado al hipervisor con una solicitud para realizar ciertas operaciones. En la mayoría de los casos, los cambios al migrar un sistema operativo a Xen afectan solo al kernel del sistema operativo, aunque pueden implicar cambios menores en las bibliotecas del sistema (por ejemplo, libc). El proceso de adaptación a Xen es muy similar a la migración a una nueva plataforma, pero es mucho más simple debido a la facilidad de implementación de la parte "invitada" del controlador (los controladores en Xen constan de dos partes: una se ejecuta fuera del máquina virtual, la segunda está dentro de ella. La parte del controlador en el sistema invitado es extremadamente primitiva y solo sirve como un traductor de consultas a la segunda parte (esto se hizo intencionalmente para facilitar la migración del sistema operativo a Xen). El modo PV no admite modos de procesador "anidados", como real-86, virtual-86, cambio entre el modo de 32 bits y 64 bits, soporte para emulación de virtualización de hardware, etc. En este sentido, el modo PV-, hay ningún fragmento inicial del arranque de la computadora (con imitación del código BIOS, cargador de arranque, etc.), y el kernel del sistema invitado se inicia inmediatamente en el modo deseado, al igual que los programas regulares. En este sentido, en particular, Xen en sí mismo no puede ejecutarse en modo PV (es decir, es imposible ejecutar un hipervisor "anidado" en modo PV).
En el modo de virtualización de hardware (HVM), el sistema operativo huésped no "sabe" sobre la existencia del hipervisor. Xen, utilizando módulos de QEMU , emula hardware real y le permite iniciar el sistema operativo. Al final, para un rendimiento normal, se deben lanzar controladores PV que implementen una interfaz rápida con dispositivos virtuales, similar a cómo funciona en modo PV. Dado que se emulan la mayoría de las operaciones privilegiadas, es posible ejecutar Xen en modo HVM desde debajo de Xen. En este caso, el hipervisor anidado solo puede funcionar en modo PV.
El hipervisor Xen (para la versión 3.4) implementa un conjunto mínimo de operaciones para administrar la memoria principal, el estado del procesador, los temporizadores y contadores de reloj (TSC) en tiempo real del procesador, las interrupciones y el control de DMA. Todas las demás funciones, como la implementación de dispositivos de disco y bloque, la creación y eliminación de máquinas virtuales, su migración entre servidores, etc., se implementan en el dominio de control. Debido a esto, el tamaño del hipervisor es muy pequeño (para la versión 3.4, el tamaño del código binario de todo el hipervisor es inferior a 600 KB), así como el tamaño de su código fuente. De acuerdo con la intención de los autores, esto aumenta la estabilidad del sistema de virtualización, ya que un error en los componentes fuera del hipervisor no compromete/daña el propio hipervisor y limita el daño solo al componente fallado, sin interferir con el resto.
Todas las funciones relacionadas con el funcionamiento de la red, los dispositivos de bloque (disco), la emulación de adaptadores de video y otros dispositivos se eliminan del hipervisor. La mayoría de estos dispositivos constan de dos partes: controladores en domU y programas en dom0. El controlador (generalmente integrado en el kernel del sistema operativo o cargado como un módulo) implementa la cantidad mínima de trabajo, de hecho, traduce las solicitudes del sistema operativo al programa en dom0. El programa en dom0 hace la mayor parte del trabajo. En este caso, el programa suele ejecutarse como un proceso separado para cada dispositivo reparado. Una falla en dicho programa conduce a la falla de un solo dispositivo (bloque, red) y no afecta el funcionamiento de otras copias del programa (es decir, no afecta los dispositivos de red / bloque de otros dominios, o incluso otros dispositivos del mismo dominio).
Tradicionalmente se utiliza la siguiente terminología: frontend es la parte del módulo ubicada en domU, backend es la parte ubicada en dom0. Para algunos tipos de dispositivos, la parte de backend puede ser diferente manteniendo la misma parte de frontend. Por ejemplo, un controlador de dispositivo de bloque puede tener un back-end en forma de generador de imágenes VHD, un controlador de dispositivo de bloque, un iniciador iscsi, etc.
Xen proporciona tres mecanismos de comunicación para dominios: uno con el hipervisor (hiperllamadas) y dos entre dominios. Muy a menudo, la interacción ocurre entre dom0 y domU, aunque el modelo permite la interacción entre dos domU.
La interacción entre dominios se reduce a dos tipos: eventos (eventos) y memoria compartida (acceso a memoria compartida). La tercera opción, transferencia de página de memoria, es un caso especial de acceso a memoria compartida.
Los eventos tienen aproximadamente el mismo propósito que las interrupciones en la arquitectura x86 o las señales en Unix: transmisión rápida sincrónica o asincrónica de una señal sobre la ocurrencia de algún evento. El acceso a la memoria compartida brinda la capacidad de transferir cantidades significativas de información y los eventos brindan una tasa de transferencia.
Los eventos se pueden enmascarar o desenmascarar. Los eventos desenmascarados provocan una devolución de llamada (llamando a la función cuya dirección se pasó anteriormente) y le permiten procesar el evento inmediatamente después de que ocurra. Los eventos enmascarados solo establecen una marca de que se ha producido el evento, y el controlador comprueba periódicamente si se ha producido el evento (uno o más). El segundo método le permite no llamar a una devolución de llamada para cada evento y, en el caso de eventos frecuentes, reduce significativamente el tiempo de procesamiento. Por el contrario, la primera opción (con devolución de llamada) le permite aumentar la velocidad de procesamiento de un evento que puede no ocurrir muy a menudo, pero requiere una respuesta inmediata.
Xen (a través de la pila de administración) admite la migración de máquinas virtuales invitadas a través de la red. La migración de máquinas paravirtuales es compatible desde la versión Xen 2 y HVM, desde la versión 3. La migración puede ocurrir con el sistema invitado apagado, o justo en el proceso, la llamada migración "en vivo" ( migración en vivo en inglés ) sin pérdida de disponibilidad.
Se requiere que ambos servidores Xen físicos vean el mismo almacenamiento donde residen los datos de la máquina virtual. Esto es necesario porque al migrar una máquina virtual no se copia su sistema de archivos, ya que llevaría demasiado tiempo incluso en el caso de una red rápida. El almacenamiento compartido puede basarse en varias tecnologías SAN o NAS como Fibre Channel , iSCSI o DRBD .
Debido al hecho de que el propio hipervisor (alrededor de 500-600 KB) implementa solo el "núcleo" del sistema, todas las demás funciones se trasladan a la capa de aplicación que se ejecuta en dom0. Un conjunto de programas que implementa funcionalidades fuera de Xen se denomina inglés. pila de herramientas (no hay una traducción bien establecida, a veces se usa el término "pila de administración").
Hay dos versiones de la pila de herramientas para Xen: basada en xend (incluida en la mayoría de las distribuciones de Xen) y basada en xapi (incluida en Citrix XenServer y Xen Cloud Platform). Xend fue desarrollado al mismo tiempo que Xen, escrito en Python, y desde el principio estuvo bajo una licencia de código abierto. Xapi era propiedad de Xensource (en adelante, Citrix), pero se lanzó bajo licencia GPL en 2009. Xapi está escrito en OCaml , en el momento de escribir este artículo tenía un conjunto más pequeño de funciones, pero era más estable.
En la versión 4.5 xend escrito en python fue reemplazado por xl/libxl escrito en C.
Ambas versiones de la pila de herramientas incluyen las siguientes utilidades:
Toolstack proporciona gestión de máquinas virtuales (creación/eliminación, inicio/parada, migración, conexión de recursos, etc.). Además, el kit de herramientas brinda administración de recursos para sistemas a gran escala: crea y mantiene repositorios para almacenar imágenes de disco de máquinas virtuales (SR - repositorio de almacenamiento), admite grupos de servidores para migrar máquinas virtuales y puede administrar configuraciones de red locales complejas, incluidas aquellas con soporte VLAN . Además, se soporta la interfaz de control remoto XenApi basada en XML-RPC [36] .
Xen es compatible con más y más plataformas todos los días.
Como hipervisor híbrido de tipo 1 , Xen se ejecuta directamente en la plataforma de hardware, pero requiere un sistema operativo host en dom0 para ejecutarse. Xen soporta procesadores a partir de Pentium II , existen versiones para arquitecturas x86-64 , PowerPC , Itanium (hasta la versión 4.4) y ARM (estable desde la versión 4.4). La carga de Xen se realiza con un gestor de arranque como GRUB o similar. Inmediatamente después de la carga, Xen inicia el sistema operativo en dom0.
La mayoría de las instalaciones utilizan Linux como sistema operativo para el dominio de control dom0. Durante mucho tiempo, la compatibilidad con Xen no estaba incluida en el kernel oficial de Linux y existía como un conjunto de parches para el kernel v2.6.18. Desde v2.6.37, el mecanismo pv_ops ha aparecido en el kernel de Linux para interactuar con hipervisores [37] . Este mecanismo permite que el núcleo funcione tanto en modo paravirtual como directamente en el hardware. A partir de Xen 4.0, admite el mecanismo pv_ops para el kernel de Linux en dom0 [38] . Los kernels de Linux por encima de 3.0 también son totalmente compatibles con Xen tanto para dom0 como para domU [39] .
Además, los siguientes sistemas operativos pueden funcionar como dom0:
La mayoría de los sistemas operativos se pueden ejecutar en modo de virtualización de hardware HVM, sin embargo, la tecnología de paravirtualización se utiliza para lograr una alta velocidad de ejecución. Los siguientes sistemas operativos invitados se pueden ejecutar en modo paravirtual en domU:
Los puertos de otros sistemas operativos como Plan 9 también están en proceso. Se espera que se liberen puertos oficiales para Xen para todos estos sistemas operativos (como sucedió con NetBSD).
Los sistemas operativos de la familia Microsoft Windows pueden ejecutarse en modo de virtualización HVM completo a partir de Xen 3 en procesadores que admitan la virtualización de hardware. En este caso, los dispositivos virtuales (disco, red) se emulan mediante una versión especial de QEMU . Para acelerar Windows se pueden utilizar los llamados controladores paravirtuales . A diferencia de Linux en modo paravirtual, el kernel de Windows no se modifica y se ejecuta en modo de virtualización de hardware, pero los controladores de dispositivos acceden a Xen directamente (a través de HyperCalls), sin pasar por la capa de emulación QEMU. Hay un desarrollo de controladores de paravirtualización con licencia GPL para Windows, y los productos Citrix XenServer y Oracle VM contienen controladores de paravirtualización firmados para Windows.
Xen se utiliza ampliamente como componente de virtualización en la computación en la nube y en los servicios de servidores privados dedicados . Empresas de alojamiento como Amazon Elastic Compute Cloud , Liquid Web , Fujitsu Global Cloud Platform , [46] Linode , SparkNode [47] y Rackspace Cloud utilizan Xen como hipervisor de máquina virtual.
Corrientemente[ aclarar ] La comunidad Xen está desarrollando Xen Cloud Platform (XCP), un sistema de virtualización de servidores. XCP se origina en la versión gratuita de Citrix XenServer y se publica en su totalidad bajo la licencia GPL de GNU .
Hay varios productos comerciales de consolidación de servidores basados en Xen. En particular, se trata de productos como: