Virtualización con Xen 3.0.3 en Debian Etch con kernel a medida para 32 y 64 bits

Por Jaume Sabater, publicado el 29 de agosto de 2006.

Artículo distribuido bajo licencia Creative Commons by-nc-sa.

Índice

  1. Introducción
  2. Descripción, historia y características de Xen Hypervisor
  3. Estructura de un sistema basado en Xen
  4. Estado actual de Xen
  5. Instalación de Xen
  6. Configuración de Xen usando un puente
  7. Configuración de Xen usando NAT
  8. Interfaces de red virtuales en un sistema Xen
  9. Puentes de red en un sistema Xen
    1. Flujo de paquetes en el puente
    2. El script network-bridge
    3. El script vif-bridge
  10. Utilidades de gestión
    1. ConVirt
    2. Enomalism
  11. Bibliografía
  12. Historial de revisiones

Introducción

Los ordenadores actuales tienen las suficientes prestaciones como para usar la virtualización con el fin de crear la representación de muchas máquinas virtuales menos capaces, cada una ejecutando una instancia independiente de un sistema operativo. El adecuado particionamiento de una máquina para que soporte la ejecución concurrente de múltiples sistemas operativos supone bastantes retos. Primero, las máquinas virtuales deben estar aisladas las unas de las otras: no es aceptable que la ejecución de una afecte adversamente el rendimiento de otra. Esto es particularmente cierto cuando las diferentes máquinas virtuales pertenecen a diferentes usuarios. Segundo, es preciso dar soporte al máximo número de sistemas operativos existentes a fin de dar salida a la heterogeneidad de las aplicaciones más comunes. Tercero, la sobrecarga introducida por la virtualización debe ser pequeña.

Descripción, historia y características de Xen Hypervisor

Xen es un hipervisor (del inglés, más que un supervisor) de código abierto que permite una mejor utilización de los servidores y la consolidación de los mismos al posibilitar que múltiples imágenes de sistemas operativos se ejecuten simultáneamente en una único servidor físico. Xen proporciona garantías sobre los recursos a los servidores virtuales para asegurar que los niveles de servicio de cada aplicación se respeten, incluyendo CPU, memoria y entrada/salida. Xen es la infraestructura de virtualización por software más rápida y segura existente, y ha sido adoptada por los principales fabricantes y distribuidores, incluyendo a Intel, AMD, Dell, Hewlett-Packard, IBM, Novell, Red Hat o Sun Microsystems. Xen se distribuye bajo la licencia General Public License de GNU y puede descargarse gratuitamente.

Un servidor virtual es simplemente una instancia de un sistema operativo y su carga de trabajo, ejecutándose bajo el paraguas del hipervisor Xen. En lugar de controlar el hardware directamente, las instancias de sistemas operativos acceden al hardware a través del hipervisor, el cuál además tiene la capacidad de compartir los recursos con otras aplicaciones e instancias de sistemas operativos virtualizadas.

Xen fue creado en el año 2003 en el laboratorio de computación de la Universidad de Cambridge bajo lo que se conoce como el proyecto Xen Hypervisor liderado por Ian Pratt. Algunos de los miembros más destacados del proyecto son Keir Fraser, Steven Hand y Christian Limpach. Este mismo equipo fundó XenSource conjuntamente con Nick Gault y Simon Crosby, que aportaron su experiencia como empresarios en Silicon Valley.

Xen cada vez se usa más en centros de datos con el objetivo de incrementar la utilización de servidores y mejorar el coste total de propiedad (del inglés, Total Cost of Ownership). Xen es ámpliamente utilizado en proveedores de servicios de aplicaciones y compañías de hospedaje porque ofrece un control preciso de los recursos del sistema y permite a los usuarios hospedar más servidores virtuales por máquina física. Xen también se usa en el desarrollo y verificación del funcionamiento de aplicaciones, pues la virtualización permite a los desarrolladores de aplicaciones multihilo hospedar múltiples máquinas virtuales y comprobar su correcto funcionamiento, ahorrando costes en infraestructuras. Más aún, el hardware de pruebas puede ser readaptado instantáneamente para otros usos simplemente instanciando servidores virtuales con las imágenes deseadas. Finalmente, las aplicaciones que han sido verificadas pueden ser puestas en producción directamente desde el entorno de pruebas basado en Xen simplemente migrando la máquina virtual pertinenete.

En resumen, los tres principales beneficios para las empresas que Xen supone son:

Xen se diferencia de otras técnicas de virtualización en varios puntos:

La paravirtualización es la clave del éxito de Xen, pues permite obtener un rendimiento drásticamente mayor que los acercamientos alternativos existentes en el mercado. La paravirtualización supone hacer que el sistema operativo del servidor virtual sea consciente de que está siendo virtualizado para permitir una colaboración entre ambas partes que facilite el rendimiento más óptimo. En Linux, BSD y Solaris, los hosts paravirtualizados ven a Xen como una capa de hardware idealizada. De hecho, Xen es simplemente una arquitectura de hardware idealizada del kernel de Linux. Intel ha realizado diversas contribuciones a Xen que han permitido añadir soporte para sus extensiones de arquitectura VT-X Vanderpool. Esta tecnología permite que sistemas operativos sin modificar actúen como hosts dentro de las máquinas virtuales de Xen, siempre y cuando el servidor físico soporte las extensiones VT de Intel o Pacifica de AMD. Para Microsoft Windows y otros hosts que no están al tanto de la existencia de Xen, la capa de virtualización VT de Intel, combinada con la paravirtualización de los controladores de Windows, permiten a Xen conseguir el mismo nivel de rendimiento que los hosts Linux virtualizados.

Debido al pequeño tamaño del código necesario para ejecutar el hipervisor, la sobrecarga en el rendimiento típicamente se encuentra entre el 0,1% y el 3,5% (datos tomados con los benchmarks estándar del mercado). Además, la técnica de paravirtualización le permite a Xen beneficiarse de todos los controladores nativos de Linux y, por lo tanto, soportar una gran cantidad de dispositivos. Los controladores paravirtualizados de Xen se ejecutan fuera del núcleo del hipervisor, donde se implementa una política de compartición de recursos entre las diversas máquinas virtuales, proporcionando así un particionamiento muy eficiente de los recursos de E/S entre los servidores virtuales. Otro beneficio de este acercamiento es que los controladores se ejecutan en un nivel de protección más bajo que Xen, manteniendo al hipervisor a salvo de errores en los controladores.

En términos de seguridad, Xen soporta un aislamiento absoluto de los recursos entre dominios, lo que significa que tiene el nivel más alto posible de separación y seguridad en un hardware de tipo i386. No es posible, por ejemplo, usar tcpdump en un host virtual para ver el tráfico de los demás hosts virtuales. Además, el código fuente base de Xen es muy pequeño (el núcleo del hipervisor tiene menos de 40.000 líneas), lo que permite realizar auditorías de seguridad en el código más fácilmente. Más importante aún, Xen puede usar las características de seguridad del hardware, como los Trusted Platform Modules (TPM), para construir una capa de monitorización del uso del hardware a través del software. En el Intel Developer Forum de agosto del 2005, XenSource demostró una solución de hipervisor seguro al integrar Xen con el sistema de detección de intrusos Snort, aplicación de código abierto líder del mercado. De este modo los usuarios reciben una nueva y potente posibilidad para implementar las mismas políticas de seguridad en los servidores virtuales, independientemente del sistema operativo. Más aún, el hipervisor puede incluso asegurar que hosts que no han sido parcheados serán protegidos. Xen puede también impedir que un servidor virtual comprometido se use para atacar a otros servidores virtuales o físicos bloqueando su tráfico.

Las máquinas virtuales de Xen pueden migrarse en caliente entre hosts físicos sin necesidad de detenerlos. Durante este proceso, la memoria de la máquina virtual se copia iterativamente al destino sin parar su ejecución. Una pequeña pausa de entre 60 y 300 milisegundos es necesaria para llevar a cabo la sincronización final antes de que la máquina virtual empiece a ejecutarse en su nuevo destinatario, proporcionando así la apariencia de una migración sin parones. Una tecnología similar se usa para suspender a disco una máquina virtual en ejecución, cambiar a otra máquina virtual y recuperar más tarde la primera máquina virtual.

Estado actual de Xen

Actualmente, Xen corre sobre arquitecturas x86, con procesadores Pentium 4 o más modernos, x86_64 (AMD64 y EM64T), IA-64 y POWER de IBM. Ports para otras plataformas son técnicamente posibles y puede que estén disponibles en el futuro. La última versión de Xen, Xen 3.0.4, extiende el liderazgo en características y funcionalidad requerida para virtualizar los servidores que hoy en día se encuentran en los centros de datos de las empresas, incluyendo:

En Debian Etch, la versión disponible de Xen es la 3.0.3, que es la que usaremos en este artículo.

Estructura de un sistema basado en Xen

Un sistema Xen tiene múltiples capas, de las cuales la inferior y la que cuenta con más privilegios es el propio Xen.

Xen puede hospedar múltiples sistemas operativos huéspedes, cada uno de los cuales es ejecutado dentro de una máquina virtual segura. En terminología Xen, un dominio. Los dominios son gestionados por Xen de forma que se usen las CPUs físicas de la manera más efectiva. Cada sistema operativo huésped gestiona sus propias aplicaciones. Esta gestión incluye la responsabilidad de ofrecer servicio a cada aplicación dentro de la franja de tiempo dada por Xen a cada máquina virtual.

El primer dominio, o dominio 0 (dom0), se crea automáticamente cuando el sistema arranca y tiene unos permisos de gestión especiales. El dominio 0 crea los demás dominios y gestiona sus dispositivos virtuales. También realiza tareas administrativas como suspender, reanudar y migrar otras máquinas virtuales.

Dentro del dominio 0 se ejecuta un proceso llamado xend, que gestiona el sistema. Xend es responsable de la gestión de las máquinas virtuales (o domU's) y proporciona acceso a sus consolas. Xend puede recibir comandos a través de una interfaz HTTP o via una utilidad de línea de comandos.

Instalación en Debian Etch

Las siguientes instrucciones toman como punto de partida un sistema Debian Etch funcional, con un kernel compilado a medida mediante las herramientas del paquete kernel-package, sin módulos y con una única interfaz de red. Por supuesto, puede servir como base para que el lector las adapte a sus necesidades. Todas las sentencias deben ejecutarse como usuario root o con permisos de root. El primer paso será instalar los paquetes Debian necesarios:

apt-get install xen-docs-3.0 xen-tools xen-utils-3.0.3-1 bridge-utils iproute sysfsutils debootstrap udev

Para 32 bits habrá que añadir libc6-xen y xen-hypervisor-3.0.3-1-i386 a la lista. Para 64 bits deberemos añadir xen-hypervisor-3.0.3-1-amd64 a la lista. En 32 bits, si tenemos más de 4 GB de RAM, deberemos instalar xen-hypervisor-3.0.3-1-i386-pae, pues trae habilitado el modo PAE (Physical Addressing Extensions). El siguiente paso será descargar y descomprimir la versión 2.6.18 del kernel:

cd /usr/src/
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.18.tar.bz2
tar -xjf linux-2.6.18.tar.bz2

Acto seguido necesitaremos descargar y descomprimir el parche 2.6.18.8 del kernel:

wget http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.18.8.bz2
bunzip2 patch-2.6.18.8.bz2

Finalmente, descargaremos el paquete de parches aplicados al kernel de Debian, que incluye el parche de Xen:

apt-get install linux-patch-debian-2.6.18

Ésto nos dejará el parche fedora-2.6.18-36186.patch.bz2 en la ruta /usr/src/kernel-patches/all/2.6.18/debian/features/all/xen.

Renombramos el directorio del núcleo y lo parcheamos:

mv linux-2.6.18 linux-2.6.18.8-xen
mv patch-2.6.18.8 linux-2.6.18.8-xen/
bunzip2 /usr/src/kernel-patches/all/2.6.18/debian/features/all/xen/fedora-2.6.18-36186.patch.bz2
cp /usr/src/kernel-patches/all/2.6.18/debian/features/all/xen/fedora-2.6.18-36186.patch linux-2.6.18.8-xen/
cd linux-2.6.18.8-xen/
patch -s -p1 < patch-2.6.18.8
patch -s -p1 < fedora-2.6.18-36186.patch

En este artículo se asume que el lector desea crearse su propio kernel a medida en lugar de usar el que viene precompilado con la distribución de Debian, y que quiere hacerlo sin usar módulos (con todos los controladores compilados dentro del kernel). Para ello usaremos la configuración existente del kernel en ejecución (el cuál se considera que cumple las condiciones mencionadas) y lo adaptaremos a los cambios que introduce Xen. Luego deberemos copiar la configuración actual dentro del nuevo árbol del kernel (se supone la existencia de un enlace débil /usr/src/linux que apunta al árbol actual del kernel, /usr/src/linux-2.6.18.8 en mi sistema en el momento de escribir este artículo):

cp /usr/src/linux/.config /usr/src/linux-2.6.18.8-xen/

Configuramos el nuevo kernel:

make menuconfig

Al menos deberán seleccionarse las siguientes opciones (dependiendo de la configuración previa que se tuviera, éstas opciones pueden variar):

Arquitectura de 32 bits:

Processor type and features ---> Subarchitecture Type (Xen-compatible)

Arquitectura de 64 bits:

Processor type and features ---> Enable Xen compatible kernel

Ambas arquitecturas (32 and 64 bits):

Xen --->
	Privileged Guest (domain 0)
	Backend driver support
		Block-device backend driver
		Block-device tap backend driver
		Network-device backend driver
			Network-device loopback driver
	PCI device backend driver
		PCI Backend Mode (Virtual PCI)
	Block-device frontend driver
	Network-device frontend driver
	Scrub memory before freeing it to Xen
	Disable serial port drivers
	Export Xen attributes in sysfs
	Xen version compatibility (3.0.2 and later)

Networking ---> 
	Networking Options --->
		802.1d Ethernet Bridging
		Network packet filtering (replaces ipchains)  --->
			Bridged IP/ARP packets filtering
			Bridge: Netfilter Configuration  --->
				Ethernet Bridge tables (ebtables) support
				ebt: broute table support
				ebt: filter table support
				ebt: nat table support
				ebt: 802.3 filter support
				ebt: among filter support
				ebt: ARP filter support
				ebt: IP filter support
				ebt: limit match support
				ebt: mark filter support
				ebt: packet type filter support
				ebt: STP filter support
				ebt: 802.1Q VLAN filter support
				ebt: arp reply target support
				ebt: dnat target support
				ebt: mark target support
				ebt: redirect target support
				ebt: snat target support
				ebt: log support

También será necesario tener soporte para los sistemas de ficheros que se quieran usar en las imágenes de Xen (Second Extended con journaling, también conocido como ext3, es el valor por defecto). Compilamos el nuevo kernel:

make-kpkg --append-to-version -xen kernel-image

Instalamos el nuevo kernel:

Arquitectura de 32 bits:

dpkg --install /usr/src/linux-xen0-2.6.18.8-xen_2.6.18.8-xen-10.00.Custom_i386.deb

Arquitectura de 64 bits:

dpkg --install /usr/src/linux-xen0-2.6.18.8-xen_2.6.18.8-xen-10.00.Custom_amd64.deb

Es muy recomendable arrancar un kernel con Xen mediante GRUB (del inglés, GRand Unified Bootloader), por lo que deberemos instalar el paquete Debian correspondiente:

apt-get install grub

El comando anterior nos dejará GRUB instalado en el sitema, pero no configurado. En el documento /usr/share/doc/grub/README.Debian.gz pueden hallarse instrucciones sobre cómo realizar dicha configuración:

  1. Crear el subdirectorio /boot/grub con mkdir /boot/grub.
  2. Utilizar el script de instalación de GRUB que viene con Debian: /usr/sbin/grub-install "(hd0)".
  3. Crear el fichero /boot/grub/menu.lst con los kernels disponibles mediante el comando /usr/sbin/update-grub

En mi caso, teniendo el sistema de ficheros XFS en la partición raíz del disco primario (existen ciertas incompatibilidades entre GRUB y XFS), el script /usr/sbin/grub-install no pudo finalizar la ejecución, así es que tuve que abortarlo mediante Ctrl+C, luego ejecutar /usr/sbin/update-grub y usar la consola de GRUB para teclear en ella los siguientes comandos:

grub
grub> root (hd0,0)
grub> setup (hd0)
grub> quit

Donde root (hd0,0) le indica a GRUB dónde se encuentran los ficheros que hay en /boot/grub. En este caso, en el disco primario (hd0), en la primera partición (la 0). Luego setup (hd0) le indica a GRUB en el MBR de qué disco tiene que instalar el cargador, en este caso hd0. Este suele ser el caso más habitual, donde hay un único disco duro (o raid de discos) con Linux. Haciendo pruebas en casa para escribir este artículo, me encontré con un caso un poco más difícil y que ilustra muy bien el funcionamiento de GRUB:

  1. Dos discos duros: disco primario (hd0) con Windows y disco secundario (hd1) con Linux.
  2. En el disco secundario, la primera partición era de swap, la segunda de root y la tercera de home.
  3. El comando root tuve que parametrizarlo tal que: root (hd1,1).
  4. El comando setup fue el mismo, pues siempre es deseable instalar GRUB en el MBR del disco principal: setup (hd0)

En el caso de que ocurran problemas al tratar de escribir GRUB en el MBR, arrancar la máquina en modo monousuario o pasar a modo init 1 puede ayudar, pues es muy recomendable no tener ningún proceso escribiendo en el disco en el mismo momento en el que GRUB está intentando modificar el Master Boot Record.

Una vez instalado GRUB en el MBR (del inglés, Master Boot Record), deberemos configurar las entradas que queremos que aparezcan. Debido a que update-grub no nos detectará el kernel compilado manualmente con Xen, deberemos editar el fichero /boot/grub/menu.lst manualmente:

Arquitectura de 32 bits:

title           Xen 3.0.3, Debian GNU/Linux, kernel 2.6.18.8
root            (hd0,0)
kernel          /boot/xen-3.0.3-1-i386.gz noreboot
module          /boot/xen0-linux-2.6.18.8-xen root=/dev/sda1 ro console=tty0
savedefault
boot

Arquitectura de 64 bits:

title           Xen 3.0.3, Debian GNU/Linux, kernel 2.6.18.8
root            (hd0,0)
kernel          /boot/xen-3.0.3-1-amd64.gz noreboot
module          /boot/xen0-linux-2.6.18.8-xen root=/dev/sda1 ro console=tty0
savedefault
boot

GRUB dispone de las directivas xenhopt y xenkopt en el fichero /boot/grub/menu.lst para configurar, respectivamente, las opciones de arranque del hipervisor y del kernel. Pero, debido a que el script update-grub no detecta nuestro kernel, no podemos usarlas.

Cuando se necesiten más de 4 máquinas virtuales, será necesario añadir el parámetro max_loop=X tras console=tty0, donde X será el número de máquinas virtuales que se desean ejecutar multiplicado por 2. Más allá de la octava máquina virtual, será necesario crear los dispositivos /dev/loop8, /dev/loop9, etc. (hasta el número que nos haga falta). Para ello, el siguiente script podrá sernos útil (sustituir el valor del segundo parámetro en la llamada al comando seq -15 en el ejemplo- por el valor máximo menos uno de dispositivos loopback que se vayan a necesitar):

for i in $(seq 8 15)
do
	mknod /dev/loop$i b 7 $i
done
chmod 660 /dev/loop*
chown 0.disk /dev/loop*

Una vez terminada la configuración del kernel y de GRUB, el siguiente paso será configurar el fichero /etc/xen/xend-config.sxp según nuestras necesidades.

Configuración de Xen usando un puente

Nos interesa crear un puente ethernet que estará formado por una interfaz ethernet falsa para cada máquina virtual y todas ellas unidas a la verdadera conexión ethernet. Si contamos con una única interfaz la configuración es muy sencilla. En el caso de tener más de una, el propio script viene repleto de comentarios que nos ayudarán a ajustar la configuración a nuestra medida.

Para ello, comentaremos la directiva (network-script network-dummy) y descomentaremos la directiva (network-script network-bridge). También nos hará falta la directiva (vif-script vif-bridge), pero ésta ya viene descomentada por defecto.

Si nos interesa agrupar todas nuestras máquinas virtuales en una red diferente, por ejemplo 192.168.0.x para dom0 y las demás máquinas físicas de la red y 10.0.0.x para las máquinas virtuales, y luego usar DNAT con iptables para enrutar el tráfico, necesitaremos usar las directivas (network-script network-nat) y (vif-script vif-nat). En el caso de un servidor con una interfaz de red, es más conveniente usar puentes. Asignaríamos diversas direcciones IP a dicha interfaz, bien públicas en el caso de un servidor de producción, bien privadas en el caso de un servidor de desarrollo tras un proxy. En el caso de tener más de una interfaz con direcciones IP de diferentes tipos, por ejemplo una local y otra pública, será más conveniente usar la solución con NAT, donde al final tendríamos un rango de direcciones IP locales para la subred tras el proxy-cache, y otro rango de direcciones IP locales para las máquinas virtuales, y todas ellas saldrían a Internet por la dirección IP pública de la máquina.

Ya estamos listos para reiniciar la máquina:

reboot

Una vez el nuevo sistema haya terminado de cargar, deberíamos ver el puente creado mediante el comando ifconfig. Deberíamos ver las interfaces peth0 (physical interface) y vif0.0 (virtual interface). Acto seguido, editaremos el fichero /etc/xen-tools/xen-tools.conf según nos convenga. Por ejemplo, supongamos que tenemos una máquina con una interfaz de red, dirección IP 192.168.0.2, máscara de 24 bits y puerta de enlace 192.168.0.1. Entonces, configuraríamos el fichero tal que así:

dir         = /home/xen
debootstrap = 1
size        = 1Gb
memory      = 256Mb
swap        = 512Mb
fs          = ext3
dist        = etch
image       = sparse
gateway     = 192.168.0.1
netmask     = 255.255.255.0
passwd      = 1
kernel      = /boot/xen0-linux-2.6.18.8-xen
initrd      =
mirror      = http://ftp.es.debian.org/debian/

Notas:

Ahora crearemos el directorio que contendrá las imágenes de los sistemas huéspedes:

mkdir /home/xen

Debido a que xen-tools utiliza toda la caché disponible en /var/cache/apt/archives y lo allí acumulado podría sobrepasar el tamaño de la imagen, es conveniente vaciarla:

apt-get clean

Con lo que ya estaremos listos para crear nuestra primera imagen de sistema virtual mediante la utilidad xen-create-image del paquete xen-tools. Le daremos al huésped la dirección IP 192.68.0.3 y el nombre xen01:

xen-create-image --hostname=xen01 --ip=192.168.0.3

Este script creará la imagen de la memoria de intercambio o swap y la imagen del disco, a la cuál dará luego formato en el sistema de ficheros que hayamos elegido y, por último, instalará el nuevo sistema mediante debootstrap usando el mirror seleccionado. Finalmente, creará un fichero de configuración de la máquina virtual en /etc/xen/xen01.cfg y nos pedirá que introduzcamos una clave de root. Una vez se hayan completado todos estos pasos, podremos arrancar la nueva imagen:

xm create xen01.cfg -c

Una vez haya arrancado la máquina virtual, podremos validarnos en el sistema como root y cambiar la clave si nos apetece. Luego deberemos comprobar que la red está correctamente configurada mediante algunos pings a hosts cuya dirección IP conozcamos, por ejemplo 192.168.0.2 (dom0) o cualquier otra máquina de nuestra red local. No tenemos nameservers configurados en estos momentos, así es que no funcionará la resolución de nombres. Una vez hayamos terminado, pulsaremos Ctrl + ] (Ctrl + AltGr + <signo de suma> en los teclados españoles) para salir de la consola virtual y trataremos de conectarnos a la máquina virtual mediante SSH:

ssh -l root 192.168.0.3

Una vez validados en el sistema, añadiremos nuestros servidores de nombres al fichero /etc/resolv.conf y nuestra nueva máquina virtual ya estará disponible para su uso.

Algunas herramientas y comandos de interés que pueden sernos muy útiles durante la configuración son las siguientes:

Configuración de Xen usando NAT

Si nuestro equipo tiene más de una tarjeta de red y, por ejemplo, está actuando como router a Internet de una red local, posiblemente nos convenga más usar la configuración de red con NAT que soporta Xen. Para ello, usaremos las directivas (network-script network-nat) y (vif-script vif-nat) en el fichero de configuración /etc/xen/xend-config.sxp.

Al arrancar, Xen nos creará por defecto las rutas necesarias para habilitar el tráfico entre los hosts virtuales y la interfaz del dom0 elegida en /etc/xen/xend-config.sxp (por defecto eth0), por lo que deberemos asegurarnos de que cualquier script de reglas de iptables que usemos no borre las reglas existentes (es decir, que no use acciones como --flush, --delete-chain o --zero).

También deberemos asegurarnos de que nuestro firewall permite el tráfico de ida y de vuelta entre las tres interfaces y, si está actuando como router, que no sólo está actuando como tal para la interfaz de red interna (práctica muy habitual a la hora de establecer una regla NAT en iptables). Suponiendo que eth0 sea la interfaz de red conectada a la red local (LAN) y eth1 la interfaz de red conectada a la red pública (WAN), es habitual tener una regla como la siguiente antes de instalar Xen:

iptables --table nat --append POSTROUTING --in-interface eth0 \
         --out-interface eth1 --jump MASQUERADE

En lugar de user --in-interface y --out-interface también es común usar --source y --destination, sobre todo si tenemos una VPN. Si vamos a instalar Xen, será necesario tener dos reglas. Suponiendo que la red local de Xen sea 10.0.0.0 con máscara de 24 bits (255.255.255.0) y la red local de PCs sea 192.168.0.0, también con máscara de 24 bits, deberían quedarnos dos reglas similares a las siguientes:

iptables --table nat --append POSTROUTING --source 192.168.0.0/24 \
         --out-interface eth1 --jump MASQUERADE
iptables --table nat --append POSTROUTING --source 10.0.0.0/24 \
         --out-interface eth1 --jump MASQUERADE

Por supuesto, en cada instalación la configuración del firewall puede ser muy diferente, y es posible que se vea afectada por otros factores, como redes privadas virtuales (del inglés, Virtual Private Network o VPN), balanceo de carga entre dos o más líneas, proxy-caché transparente, etc. Estos escenarios más complejos quedan más allá del alcance de este artículo, pero quisiera destacar que lo más importante es tener clara la ruta que sigue (o debe seguir) el tráfico y empezar con un cortafuegos sencillo para ir complicándolo paso a paso.

Interfaces de red virtuales en un sistema Xen

Xen crea, por defecto, siete pares de interfaces ethernet virtuales interconectadas para que dom0 las utilice. Podríamos concebirlas como dos interfaces ethernet conectadas 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. El siguiente diagrama muestra las tarjetas de red físicas y lógicas:

Tarjetas de red físicas y lógicas
Tarjetas de red físicas y lógicas

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 siguiente figura muestra las tarjetas de red lógicas conectadas entre el dom0 y dom1:

Tarjetas de red lógicas conectadas entre dom0 y dom1

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. Si se va a hacer un uso extensivo de iptables, por ejemplo para un cortafuegos, podría verse afectado el puente pues los paquetes transferidos por el puente pasan a través de las cadenas PREROUTING, FORWARD y POSTROUTING. Esto supone que los paquetes que viajan entre los dominios huésped y la red exterior deberán de tener permiso para poder pasar por esas cadenas. El problema más probable es que la cadena FORWARD esté configurada para descartar (DROP) o rechazar (REJECT) paquetes.

Para evitar que dom0 actúe como un enrutador IP podemos usar el siguiente comando:

echo 0 > /proc/sys/net/ipv4/ip_forward

Un método ligeramente más seguro consistiría en permitir el reenvío de paquetes (FORWARD) a nivel de iptables entre la interfaz física externa y las interfaces virtuales vif's de los huéspedes. En una máquina con una única interfaz deberíamos usar las siguientes reglas:

iptables --append FORWARD --match physdev --physdev-in eth0 --physdev-out '!' eth0  --jump ACCEPT
iptables --append FORWARD --match physdev --physdev-out eth0 --physdev-in '!' eth0  --jump ACCEPT

(será preciso que el kernel sea compilado con soporte para ipt_physdev, que es posible que aparezca como xt_physdev)

Flujo de paquetes en el puente

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). Filtrar a este nivel sería posible mediante ebtables. 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:

Es conveniente tener la intefaz 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 domU's (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:

Utilidades de gestión

Diversas herramientas de gestión (del inglés, Xen Management Consoles) han sido desarrolladas por terceras partes para facilitar las tareas más comunes de gestión de una máquina con Xen, como configurar, arrancar, monitorizar y para huéspedes Xen. Algunas de estas herramientas son las siguientes:

ConVirt

El proyecto ConVirt (del inglés, Controlling Virtual Systems), anteriormente conocido como XenMan es un proyecto de código abierto (con licencia GPL) concebido con el objetivo de abordar los retos de gestión y administración que representa la adopción de las plataformas de virtualización para un centro de datos tradicional. La consola de administración XenMan supone el primer producto dentro del proyecto ConVirt.

XenMan es una herramienta gráfica intuitiva orientada a la gestión operativa del ciclo de vida de de una plataforma de virtualización Xen. XenMan ha sido construido con la firme filosofía de diseño de que la facilidad de uso y la sofisticación puede, y deben, coexistir en una misma herramienta de gestión. Por eso, XenMan debería demostrarse útil tanto para el administrador experto de Xen como para aquel que está tratando de introducirse en el mundo de la virtualización Xen.

Gracias a las prestaciones de XenMan, los administradores pueden centralizar la gestión de todo su entorno desde una única consola y de forma segura. Las tareas más comunes como arrancar, detener o monitorizar máquinas virtuales típicamente no suponen más que unos pocos clicks de ratón con XenMan; del mismo modo que otras operaciones de gestión como comprobar las configuraciones de sistemas operativos o acceder a los servidores de manera individual para tareas de mantenimiento.

Fácil acceso a las operaciones más frecuentes

Estas son, de forma resumida, algunas de sus características:

Para comenzar a disfrutar de XenMan, tan sólo deberemos instalar el paquete Debian correspondiente, que ya nos instalará todas las dependencias necesarias (la última versión es la 0.6, pero el paquete Debian es de la 0.5, por lo que el lector deberá evaluar si las nuevas características de la versión 0.6 le son necesarias o no). XenMan debe instalarse en la máquina desde la cual queramos gestionar nuestros servidores con Xen, típicamente un PC cliente, que deberá tener instalado el servidor X. No es necesario instalar el servidor X ni tampoco XenMan en el propio servidor:

apt-get install xenman

Si estamos probando Xen en un entorno local, no será necesario realizar ningún ajuste de configuración adicional, sino que tan sólo deberemos ejecutar XenMan como root mediante sudo, tal que:

/usr/bin/sudo /usr/sbin/xenman

Si únicamente tenemos pensado administrar servidores remotos, podemos arrancar XenMan como usuario no root.

Configuración de una máquina virtual

En el directorio /usr/share/doc/xenman podemos encontrar el fichero README.gz, que nos ayudará a configurar el fichero de configuración /etc/xenman.conf según nuestras necesidades. La documentación en línea de ConVirt es muy completa y con toda seguridad nos será muy útil.

Si es preciso utilizar la versión 0.6, deberemos realizar los siguientes pasos como root:

Bajar el tarball de fuentes de la página de descargas de ConVirt. Con wget podemos usar un enlace directo a uno de los mirrors. Desde nuestro directorio de trabajo (cd ~):

wget http://ovh.dl.sourceforge.net/sourceforge/xenman/xenman-0.6.tar.gz

Descomprimimos el tarball:

tar -xzf xenman-0.6.tar.gz

Encontraremos dentro del directorio creado, xenman-0.6, un fichero README.install con las instrucciones de instalación. Supondremos que accedemos remotamente a un servidor con Xen instalado. El siguiente paso será asegurarnos de que todas las necesidades de conectividad de XenMan están cubiertas:

A continuación creamos una copia local del almacén de imágenes (el directorio de XenMan con todas las imágenes de máquinas virtuales listas para ser instaladas):

cd xenman-0.6
sh ./mk_image_store

El almacén de imágenes se creará dentro de /var/cache/xenman, tal y como indica el mensaje de salida del script. Instalamos ahora python-paramiko, una librería de cliente SSH que XenMan utiliza para la gestión remota, en nuestro sistema:

apt-get install python-paramiko

Instalamos Xen Hypervisor en nuestro PC. Para i386 sería:

apt-get install xen-hypervisor-3.0.3-1-i386

XenMan necesitará tener acceso a las librerías de Python que Xen Hypervisor instala, pero en Debian se hallan en una ruta diferente de la que XenMan espera, por lo que deberemos usar un enlace débil para solventar el problema:

ln -s /usr/lib/xen-3.0.3-1/lib/python /usr/lib/python.

No es necesario instalar más paquetes que las dependencias que ya nos instalará el propio paquete, pues sólo actuaremos como cliente. Ya sólo nos queda lanzar la aplicación:

~/xenman-0.6/XenMan

Si arrancamos el servidor X en nuestro PC cliente mediante un gestor como KDM o GDM, deberemos usar sudo para arrancar la aplicación:

sudo ~/xenman-0.6/XenMan

A continuación se describe brevemente cómo establecer acceso al servidor por SSH mediante autenticación de clave pública/privada:

Enomalism

Enomalism es una herramienta de administración de Xen Hypervisor de código abierto, muy potente y basada en web. Ha sido desarrollada por Enomaly, una consultora de Toronto, Canada, y tiene como principales objetivos responder a las dificultades de gestión de entornos de hospedaje fragmentados. Enomalism proporciona una interfaz fácil de utilizar con la que trabajar sobre múltiples servidores independientes de forma concurrente usando el entorno Enomalism Virtualized Grid y la plataforma Elastic Computing. Así, múltiples servidores físicos pueden gestionarse como si fueran uno solo gracias a un conjunto de herramientas especializadas, tales como el asistente de creación de servidores virtuales, las plantillas que facilitan la configuración de servidores virtuales, un mecanismo de despliegue de aplicaciones, la integración con herramientas de terceros mediante Web Services y la gestión centralizada de usuarios a través de LDAP. Enomalism se distribuye bajo la licencia Lesser General Public License (LGPL).

Algunas de sus características son:

La lista completa de características de este software es enorme y puede encontrarse en la página web del mismo.

Enomalism utiliza un sistema de asignación de sistemas llamado Gold, que es de código abierto. Se trata de un sistema de contabilidad que mantiene y gestiona referencias de los recursos utilizados en servidores virtuales de alto rendimiento. Actúa de forma muy parecida a un banco, donde el dinero se depositan en cuentas con unos controles de acceso que identifican qué usuarios, proyectos y máquinas tienen acceso.

Enomalism puede descargarse desde su página en SourceForge. En la página de descargas de la web de Enomalism hay un enlace a la documentación de instalación del producto. Como podrá apreciar el lector, a diferencia de ConVirt/XenMan, Enomalism es un software diseñado para entornos muy profesionales y su complejidad es muchísimo mayor, tanto en la instalación como en la gestión. En este artículo no se profundizará más en él, pero queda como referencia para aquel lector que, tras una introducción y utilización no intensiva de Xen, quiera adentrarse en el mundo de los centros de datos de alta disponibilidad. Enomalism requiere la versión 3.0.4 de Xen para funcionar.

Vista principal del estado de los servidores

Bibliografía

Historial de revisiones

Fecha Versión Cambios
2006-08-29 1.0 Documento inicial
2007-03-23 1.5 Actualizado a kernel 2.6.18 y Xen 3.0.3. Añadida la configuración en red con NAT. Añadidas algunas utilidades de gestión.