Funcionamiento de Xen

Arquitectura

Figura 2.4: Arquitectura de xen

Es preciso aclarar la nomenclatura que utiliza Xen para los sistemas ejecutados: la maquina virtual anfitrión VM0 se suele notar como dominio 0 y las demás como dominio U.

En la máquina anfitrión el kernel se ejecuta en el nivel del microprocesador 0 así como el monitor o hypervisor. El resto de máquinas virtuales se ejecutan en el nivel 1. Las aplicaciones del todas las máquinas virtuales se ejecutan en nivel 3 el nivel con menores privilegios.

En paravirtualización todas las máquinas virtuales usan el procesador directamente haciendo el hypervisor de planificador del tiempo de ejecución de tal manera que las maquinas corran de forma nativa.

Cuando las máquinas virtuales acceden a un dispositivo este acceso pasa por el dominio 0 proporcionando el aislamiento necesario. De esta forma los controladores de los dispositivos de las máquinas virtuales no son más que una API que se comunica con el anfitrión, este posee la implementación de los controladores de los dispositivos virtuales que no son más que unas traducciones hacia los controladores nativos, realiza la operación, accediendo al dispositivo y devuelve el resultado a la máquina invitada.

Uno de los puntos más conflictivos de que se ejecuten las instrucciones de las máquinas virtuales nativamente sobre el procesador son las interrupciones por falta de página. Para esto el hypervisor genera una CPU virtual y una unidad de gestión de memoria (MMU) virtual, pudiendo así correr las máquinas con más o con menos procesadores que los reales.

Las aplicaciones que hacen uso de muchas interrupciones hardware provocan una caída de rendimiento debido a la intercesión del hypervisor entre el hardware real y el virtual, así que Xen intenta minimizar al máximo estas actuaciones.

Como también se puede ver en la figura 2.4, Xen permite la ejecución de sistemas operativos sin modificación, hasta hace poco esto no era posible debido a la necesidad de que el kernel de estos se ejecutase a nivel de privilegio del procesador 1 en vez de 0, pero desde la salida de los últimos microprocesadores esto ya es posible por la inclusión de unas nuevas instrucciones al procesador, VT en el caso de Intel y Pacifica en el caso de AMD, que crean un nuevo nivel de privilegios por debajo del nivel 0 denominado root-mode, a partir de este nivel ya se pueden ejecutar cualquier sistema operativo sin modificación.

A continuación se describirá el modo de operación de Xen.

Interfaz de la máquina virtual

Los temas a tratar por el hypervisor son los siguientes:

• Gestión de memoria:
  • Segmentación: No se pueden usar descriptores de segmentos con todos los privilegios y tampoco se pueden superponer los segmentos con el final del espacio de direcciones.
  • Paginación: El sistema operativo invitado tiene acceso directo a las tablas de paginación (TLB) pero para actualizarla debe validarlo el hypervisor.
• CPU:
  • Protección: El sistema operativo invitado debe correr en un nivel de privilegios menor que el hypervisor.
  • Excepciones: El SO invitado debe registrar una tabla de manejadores de excepciones en Xen, de tal manera que, por ejemplo, las faltas de página las ejecute el hypervisor.
  • Llamadas al sistema: Las llamadas al sistema se ejecutan directamente, para esto previamente se deben validar, de tal manera que se mantenga el aislamiento entre máquinas virtuales.
  • Interrupciones: las interrupciones se remplazan por eventos del sistema.
  • Tiempo: Cada máquina virtual tiene una interfaz de tiempo, para mantener la diferencia entre el tiempo real y el tiempo virtual.
• Dispositivos de entrada y salida: para los dispositivos virtuales se capturan sus interrupciones hardware y se sustituyen por un mecanismo de eventos.

Gestión de memoria

Virtualizar la memoria es la parte mas difícil, requiere la intervención del hypervisor además de la modificación de cada sistema operativo invitado. El primer problema es la virtualización de la TLB, en otras arquitecturas se puede manejar por software, de tal manera que puedan coexistir diferentes TLBs de un modo eficiente, pero la arquitectura x86 no lo permite, lo que conlleva que para cada modificación en esta deba de ser capturada y validada.

Sabiendo esto la solución a la que se ha llegado consta de dos puntos:

1. El sistema operativo invitado es responsable de manejar y alojar las tablas de paginación, con la intervención de Xen para asegurar el aislamiento y la seguridad.
2. Xen residirá en los últimos 64 MB del espacio de direcciones de cada máquina virtual para que la intervención en la TLB no conlleve un cambio de contexto hacia el hypervisor.

Cada vez que el sistema operativo invitado requiera alojar una nueva página en memoria esta se registrará en Xen, lo que quiere decir que el sistema invitado debe renunciar a escribir directamente en la tabla de paginación, lo que conlleva una modificación del sistema operativo.

La segmentación se gestiona de un modo similar, las únicas restricciones que se imponen a los descriptores de segmento del sistema operativo invitado son que: deben tener menor privilegio que Xen y que no se debe permitir ningún acceso a la porción de memoria reservada por este.

CPU

La virtualización de la CPU tiene importantes connotaciones, la primera es que Xen debe correr en un nivel de privilegios mayor que los sistemas operativos, lo que viola la suposición de que el sistema operativo debe ser la entidad con mayores privilegios en la máquina.

Así dado que la arquitectura x86 consta de cuatro niveles de privilegios (o rings), el hypervisor se situaría en el nivel 0, el de mayores privilegios, los sistemas operativos invitados en el nivel 1 y las aplicaciones que corran sobre estos en el nivel 3, el de menores privilegios. El uso de los tres niveles de privilegios permite garantizar la seguridad de que ni las aplicaciones podrán ejecutar instrucciones en el modo kernel del sistema operativo ni el sistema operativo podrá ejecutar las instrucciones privilegiadas del hypervisor, proporcionando un nivel de seguridad entre las distintas máquinas virtuales y el hypervisor. El problema para usar esta técnica en otras arquitecturas, es que algunas solo poseen dos niveles de privilegios, lo que provoca que el sistema operativo corra al mismo nivel que las aplicaciones, es decir, que se pierda el aislamiento entre el kernel del sistema operativo y las aplicaciones.

Las instrucciones que solo podría ejecutar Xen serían las relacionadas con las tablas de páginas y otras como halt que sirve para detener el procesador.

Las excepciones son tratadas de un modo bastante sencillo, una tabla contiene los punteros a las rutinas de cada excepción, esta tablas la registra Xen tras validarla. Esto es posible debido a que la gran mayoría de las rutinas son idénticas a las que se usarían directamente sin virtualización. Las rutinas que no son iguales son las que se han explicado antes, las relacionadas con memoria, para asegurar el aislamiento. Cuando se intenta ejecutar una instrucción fuera del nivel 0 la rutina de Xen crea una copia del marco de pila de esta en el sistema operativo invitado y le pasa el control a la excepción registrada por Xen.

Normalmente solo hay dos tipos de excepciones que puedan afectar notablemente el rendimiento del sistema por su frecuencia, las llamadas al sistema y las faltas de página. La solución que se utiliza en el caso de las llamadas al sistema es simplemente revisarlas para que se puedan ejecutar a nivel de privilegios 1 y dejar que se ejecuten directamente. Las faltas de página son un caso distinto ya que solo se pueden ejecutar en nivel 0 lo que implica que siempre las deba procesar Xen. El proceso de ejecución de estas es el siguiente: Desde el sistema operativo anfitrión se mira el fallo de página, se mira que el segmento al que pertenezca la página este cargado y que la carga de esta página no afecte a los segmentos marcados como estáticos por Xen, si el segmento no está en memoria se sale de la subrutina con iret, con lo que en el sistema invitado se detectaría una doble falta, y lanzaría la interrupción correspondiente.

Dispositivos de entrada y salida

En la virtualización completa se emulan completamente los comportamientos de los dispositivos de la máquina virtual, en la paravirtualización únicamente se crea una capa de abstracción sobre los dispositivos reales. Así Xen provee una interfaz de dispositivos genéricos con los que se interactúa. Cuando una máquina virtual utiliza un dispositivo la orden val al controlador de esta máquina virtual que no es más que una interfaz del controlador real que está en el sistema operativo anfitrión, aquí se traduce la petición al los drivers nativos de los dispositivos físicos y se ejecuta la orden.

Esto aunque parezca que es lo mismo que en otras plataformas de virtualización completa como VMware Workstation, no es así, por ejemplo, en el caso del disco duro puede ser una partición real o por LVM, en la virtualización completa el disco duro no es más que un archivo de nuestro sistema de ficheros.

Otro ejemplo de esto sería la tarjeta gráfica, mientras que en la virtualización completa es impensable ejecutar juegos en 3D, la tarjeta gráfica virtual de Xen es una S3 Savage con soporte completo OpenGL que se ejecuta a la velocidad de la tarjeta real, habiéndose hecho pruebas de rendimiento con una perdida menor del 10

Interfaces de red virtuales en un sistema Xen

Xen crea, por defecto, siete pares de interfaces ethernet virtuales interconectadas para que dom0 las utilice. Se pueden concebir como dos interfaces ethernet conectados por un cable ethernet cruzado interno. Veth0 está conectada a vif0.0, veth1 está conectada a vif0.1, y así sucesivamente hasta veth7, que está conectada a vif0.7. Pueden accederse o usarse configurando una dirección IP y una MAC en el costado de la veth# y luego enlazando el extremo vif0.# al puente. La figura 2.5, muestra esta configuración.

Figura 2.5: Interfaces de red virtuales en Xen

Cada vez que se crea una instancia domU, ésta recibe un identificador numérico (asignado automáticamente y sin la posibilidad de que el usuario lo elija). El primer domU será el número 1, el segundo el número 2, incluso aunque el número 1 ya no se esté ejecutando, etc.

Para cada nuevo domU, Xen crea un nuevo par de interfaces ethernet virtuales conectados, con un extremo de cada par dentro del domU y el otro en el dom0. Si el domU usa Linux, el nombre de dispositivo se mostrará como eht0. El otro extremo de ese par de interfaces ethernet virtuales aparecerá dentro del dom0 como interfaz vif#.0. Por ejemplo, la interfaz eth0 del domU número 5 está conectada a vif5.0. Si se crean múltiples interfaces de red dentro de un domU, sus extremos se verán como eth0, eth1, etc, mientras que dentro de dom0 aparecerán como vif#.0, vif#.1, etc. La figura 2.6, muestra las tarjetas de red lógicas conectadas entre el dom0 y dom1.

Figura 2.6: Tarjetas de red virtuales entre dominios Xen

Cuando un domU se detiene (usando el comando xm shutdown domId, por ejemplo), los interfaces ethernet virtuales que se crearon son eliminados.

Puentes de red en un sistema Xen

La configuración por defecto de Xen crea puentes de red (del inglés, bridges o bridging) dentro de dom0 para permitir que todos los dominios aparezcan en la red como hosts independientes.

Cuando un paquete llega al hardware, el controlador ehternet del dominio 0 lo gestiona y aparece en la interfaz peth0. Peth0 está ligado al puente, por lo que es transferido al puente desde ahí. Este paso se ejecuta a nivel ethernet (no hay ninguna dirección IP establecida en la peth0 o en el puente).

Acto seguido el puente distribuye el paquete del mismo modo que lo haría un concentrador (del inglés, switch). Luego, de entre las interfaces vifX.Y conectadas al puente se decide a dónde mandar el paquete basándose en la dirección MAC del receptor.

La interfaz vif pasa el paquete a Xen, el cuál a continuación lo envía de vuelta al dominio al cuál la vif apunta (también se hace así para el dom0, pues vif0.0 está conectada a veth0). Finalmente, el dispositivo destinatario del dom0/domU tiene una dirección IP, por lo que se puede aplicar iptables aquí.

El script network-bridge

Cuando Xen arranca, ejecuta el script /etc/xen/scripts/network-bridge, el cuál lleva a cabo las siguientes tareas:

• Crea un nuevo puente llamado xenbr0.
• Desactiva la interfaz ethernet real eht0.
• Copia las direcciones MAC e IP de la eth0 a la interfaz virtual de red veth0.
• Renombra la interfaz real eth0 a peth0.
• Renombra la interfaz virtual veth0 a eth0.
• Conecta peth0 y vif0.0 al puente xenbr0.
• Activa el puente, peth0, eth0 y vif0.0.

Es conveniente tener la interfaz física y la interfaz del dom0 separadas, pues así es posible crear un cortafuegos en el dom0 que no afecte al tráfico de los dominios domU (que proteja únicamente el dom0).

El script vif-bridge

Cuando arranca un domU, xend, que se está ejecutando en dom0, lanza el script vif-bridge, el cuál lleva a cabo las siguientes tareas:

• Enlaza la interfaz vif#.0 al puente xenbr0.
• Levanta la interfaz vif#.0.

Xen 3

La última versión lanzada de Xen es la 3, que incluye las siguientes mejoras:

• Soporte para máquinas SMP virtuales: aunque Xen ha tenido soporte para múltiples procesadores desde hace tiempo, los dominios estaban restringidos a una única CPU. La versión 3 modifica esto. Se puede incluso cambiar el número de CPUs virtuales en tiempo de ejecución.
• Soporte ACPI: en Xen 2, el hypervisor tan sólo disponía de un soporte rudimentario de ACPI (aunque esto era suficiente para manejar la mayoría de las tablas de rutinas de las IRQ). En Xen 3 el dominio 0 tiene acceso a la mayoría de las funciones ACPI.
• Soporte de hardware mejorado: algunos problemas específicamente con el soporte AGP y DRM (gráficos 3D) de Linux fueron eliminados de las versiones anteriores 2.0.x y 3.0 developer.
• Soporte PAE36: Xen 2 estaba restringido al espacio de direcciones normal de 32 bits (4GB) en máquinas x86. La extensión PAE36 permite ahora que Xen pueda acceder a 64GB; desde luego, suponiendo que tanto Xen como el kernel han sido compilados con el soporte PAE incluido.
• Soporte x86/64: la variante de 64 bits de la arquitectura x86 elimina todas las restricciones asociadas con el espacio de direcciones de 32 bits y añade diversas optimizaciones. Xen 3 soporta ahora sistemas operativos de 64bits.
• Múltiples arquitecturas: el soporte para IA64 (Itanium) está integrado en Xen 3, con soporte para la arquitectura Power.
• Uso de las nuevas tecnologías de CPU: Intel dispone de una nueva generación de CPUs con la extensión especial conocida como Tecnología Vanderpool. Por otro lado AMD dispone de la tecnología AMD-V en sus últimos procesadores. Estas extensiones facilitan y aceleran la implementación de una virtualización completa.

Conclusiones

Xen es un producto probado, utilizado y listo para usar en producción. El hecho de que esté licenciado bajo GPL no solo baja mucho los costos, sino que también le da mucha flexibilidad y proyección a futuro (en la vida del proyecto). Este producto combinado con sistemas de almacenamiento propietarios o libres (utilizando LVM -Logical Volumen Manager, Mdadm -manejo de RAID por software para Linux-, IET -iSCSI Enterprise Target- y GFS -Global FileSystem-) puede dar excelentes resultados, alta disponibilidad y una escalabilidad sorprendente. Las ventajas son las siguientes:

• Independencia entre los sistemas virtualizados. Se pueden reiniciar, borrar y crear independientemente.
• Mejor aprovechamiento del hardware de la maquina: balanceo de recursos. Un sistema virtual puede recibir más recursos si los necesita y los demás sistemas no los necesitan.
• Facilidad para realizar copias de seguridad, solo es necesario copiar la máquina virtual permitiendo posteriormente que sea arrancada en un nuevo servidor. Xen incluso permite la migración en caliente, dando flexibilidad y escaso o nulo tiempo de recuperación ante un incidente.
• Se pueden modificar parámetros como la memoria RAM, el número de CPUs, espacio en disco... para ajustarlos a las necesidades de la máquina virtual.
• Se pueden crear máquinas de pruebas similares a las definitivas sin necesidad de adquirir hardware adicional.

Por otro lado tiene las siguientes desventajas:

• No soporta drivers propietarios de algunas tarjetas gráficas en el dom0, aunque se han publicado algunos parches para tener soporte a las distintas versiones del driver propietario de nVidia.
• Las versiones de pago son aquellas que implementan interfaces de usuario más intuitivos.