Í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:
• Incrementar la utilización de los servidores: los centros de datos pueden conseguir enormes mejoras en la utilización de sus servidores y posibilitar la fusión de los mismos, reduciendo los costes de capital y personal técnico.
• Reducir la cantidad de personal técnico necesario: al permitir la consolidación de servidores, Xen reduce el coste, la complejidad y la dedicación del personal requeridos para la gestión de los servidores de un centro de datos. Gracias a las herramientas de gestión, control y automatización de Xen, las empresas pueden virtualizar sus servidores por un modesto coste.
• Reducir el TCO: hoy en día, la virtualización todavía no ha llegado al corazón de los centros de datos. Las razones son dos: el bajo rendimiento de los hipervisores propietarios y su enorme coste. Xen es el hipervisor con mejor rendimiento, y es gratuito. Ésto cambia radicalmente la perspectiva económica a la hora de considerar la virtualización.
Xen se diferencia de otras técnicas de virtualización en varios puntos:
• Es código abierto, lo que supone una mejor funcionalidad, mejor rendimiento y gran extensibilidad
• Es, sin duda alguna, el hipervisor con mejor rendimiento del mercado, fruto de su tecnología de paravirtualización, pionera y líder en el mercado, que permite la colaboración de los servidores hospedados para conseguir el mejor rendimiento en aplicaciones corporativas.
• Xen usa de manera óptima las capacidades de virtualización por hardware de los procesadores VT de Intel y los Pacifica de AMD.
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:
• Soporte para servidores virtuales con sistema operativo multiprocesador de 32 vias.
• Soporte para la virtualización por hardware de los Intel VT-X y los AMD Pacifica, que permite ejecutar sistemas operativos sin modificar dentro de las máquinas virtuales (Windows XP/2003 y UNIX antiguos)
• Soporte para Intel PAE (Physical Addressing Extensions) en servidores de 32 bits con más de 4 GB de RAM
• Soporte para las arquitecturas x86/64 (tanto AMD64 como EM64T)
• Soporte para SMP (Symmetric Multi-Processor)
• Herramientas de control
• Soporte de ACPI (Advanced Configuration and Power Interface)
• Soporte para gráficos AGP/DRM
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:
• Es conveniente usar el mirror más cercano a nuestra situación geográfica.
• El valor de la directiva gateway deberá cambiarse a la puerta de enlace que usemos para salir a Internet.
• La máscara de red deberá de modificarse en corcondancia a la red que tengamos configurada también.
• Si queremos usar asignación dinámica de dirección IP en lugar de estática, usaremos dhcp = 1 en lugar de gateway y netmask.
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:
• xm console xen01 nos permitirá conectar una consola a la máquina virtual xen01
• xm list nos mostrará una lista de las máquinas virtuales en ejecución y algunos datos de ellas. Un ejemplo de lo que veríamos sería lo siguiente:
• Name ID Mem(MiB) VCPUs State Time(s)
• Domain-0 0 98 1 r----- 5068.6
• xen01 164 128 1 r----- 7.6
• xen-list-images nos mostrará una lista de las imágenes existentes y su dirección IP actual.
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:
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:
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:
• 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 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:
• Enlaza la interfaz vif#.0 al puente xenbr0.
• Levanta la interfaz vif#.0.
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:
• Xen Tools, hechas en Python y disponibles como paquete Debian (utilizadas en este artículo para la creación de máquinas virtuales).
• MLN (del inglés, Manage Large Networks, hechas en Perl.
• Enomalism, un gestor gráfico programado en Python con el MVC TurboGears.
• ConVirt, hecho en Python y GTK, gestor gráfico disponible como paquete Debian.
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.
Estas son, de forma resumida, algunas de sus características:
• Gestión de múltiples servidores. Permite gestionar todos nuestros servidores y todos las máquinas virtuales que en ellos se estén ejecutando sin la necesidad de instalar agente alguno.
• Vista global centralizada. Permite ver el rendimiento, la disponibilidad y la configuración de todos nuestros servidores y máquinas virtuales de un vistazo. Permite llevar a cabo tareas administrativas, de monitorización y de actualización directamente dede la vista centralizada con unos pocos clicks de ratón.
• Comunicaciones seguras. XenMan usa túneles SSH para comunicarse con los servidores. SSH es considerado hoy en día como el estándar para operaciones remotas seguras.
• Almacén de imágenes. Permite guardar imágenes de sistemas operativos huéspedes para distribuirlas fácilmente por nuestros servidores según sea necesario. XenMan se ocupa de descargar dichas imágenes de manera transparente.
• Operar remotamente. Puede verse instantáneamente la información del SO de todos los servidores remotos y reiniciar todas las máquinas virtuales de un servidor con un único click.
• Facilidad de uso. Su interfaz de usuario es muy intuitiva y sencilla de aprender a utilizar.
• Es gratuito y de libre distribución.
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.
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:
• Descomentamos la directiva xend-tcp-xmlrpc-server y le cambiamos el valor a yes en el fichero de configuración /etc/xen/xend-config.sxp del servidor y reiniciamos Xen con /etc/init.d/xend restart.
• Nos aseguramos de poder hacer login mediante SSH como root en el servidor (directiva PermitRootLogin a yes en el /etc/ssh/sshd_config del servidor).
• Establecemos acceso al servidor por SSH mediante autenticación de clave pública/privada.
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:
• Creamos un par claves DSA pública/privada en la máquina cliente (cuando se nos pregunte por una contraseña, pulsamos intro para dejarla en blanco):
ssh-keygen -t dsa
• Copiamos la clave pública de la máquina cliente (~/.ssh/id_dsa.pub) al directorio de trabajo del servidor.
scp ~/.ssh/id_dsa.pub <servidor>:
• En el servidor, añadimos el contenido del fichero recién copiado (~/id_dsa.pub) al fichero ~/.ssh/authorized_keys2:
cat ~/id_dsa.pub >> ~/.ssh/authorized_keys2
• En el servidor, nos aseguramos de que el directorio ~/.ssh tenga permisos 700 y el fichero ~/.ssh/authorized_keys2 tenga permisos 600.
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:
• Asistente de instalación para facilitar la instalación de los componentes principales que utiliza el servidor LDAP ya instalado en nuestro servidor.
• Capacidad para cambiar el tamaño de las particiones de las máquinas virtuales utilizando LVM (del inglés, Logical Volume Manager).
• Posibilidad de cambiar la asignación de CPU y memoria de las máquinas virtuales.
• Soporte para múltiples distribuciones de Linux y BSD.
• Interfaz de usuario basado en AJAX claro, optimizado y fácil de utilizar.
• Gestión de usuarios mejorada y control de las ACL (del inglés, Access Control Lists) del dominio.
• Programado según el paradigma Modelo-Vista-Controlador de TurboGears.
• Soporte de sHype/ACM en Fedora Core 6.
• Soporte para Windows XP/Vista a través de XenSource Enterprise.
• API disponible y soporte para Web Services para obtener una verdadera arquitectura orientada a servicios.
• Soporte para múltiples servidores.
• Soporte de VMcasting.
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.
Bibliografía
• Computer Laboratory - Xen virtual machine monitor
• Computer Laboratory - Architecture
• Installing Xen 3.0 upon Debian Sarge
• Installing Xen 3.0 upon Debian Unstable, with a custom Kernel
• Xen 3 for Debian
• Xen Virtualization and Linux Clustering, Part 1
• Building A Virtual Cluster with Xen (Part One)
• The Perfect Xen 3.0 Setup For Debian
• How To Set Up Xen 3.0 From Binaries In Ubuntu 6.06 LTS (Dapper Drake)
• X86 virtualization
• Xen
• Hypervisor
• XenSource Products - Xen 3.0
• Xen Wiki - XenDownloads
• Xen Wiki - XenNetworking
• Xen Wiki - IntelVT
• Linux Virtualization with Xen
• Jailtime
• Enomalism
Historial de revisiones
Fecha Versión Cambios
29/08/2006 1.0 Documento inicial
23/03/2007 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.
no se olviden de comentar.saludos
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:
• Incrementar la utilización de los servidores: los centros de datos pueden conseguir enormes mejoras en la utilización de sus servidores y posibilitar la fusión de los mismos, reduciendo los costes de capital y personal técnico.
• Reducir la cantidad de personal técnico necesario: al permitir la consolidación de servidores, Xen reduce el coste, la complejidad y la dedicación del personal requeridos para la gestión de los servidores de un centro de datos. Gracias a las herramientas de gestión, control y automatización de Xen, las empresas pueden virtualizar sus servidores por un modesto coste.
• Reducir el TCO: hoy en día, la virtualización todavía no ha llegado al corazón de los centros de datos. Las razones son dos: el bajo rendimiento de los hipervisores propietarios y su enorme coste. Xen es el hipervisor con mejor rendimiento, y es gratuito. Ésto cambia radicalmente la perspectiva económica a la hora de considerar la virtualización.
Xen se diferencia de otras técnicas de virtualización en varios puntos:
• Es código abierto, lo que supone una mejor funcionalidad, mejor rendimiento y gran extensibilidad
• Es, sin duda alguna, el hipervisor con mejor rendimiento del mercado, fruto de su tecnología de paravirtualización, pionera y líder en el mercado, que permite la colaboración de los servidores hospedados para conseguir el mejor rendimiento en aplicaciones corporativas.
• Xen usa de manera óptima las capacidades de virtualización por hardware de los procesadores VT de Intel y los Pacifica de AMD.
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:
• Soporte para servidores virtuales con sistema operativo multiprocesador de 32 vias.
• Soporte para la virtualización por hardware de los Intel VT-X y los AMD Pacifica, que permite ejecutar sistemas operativos sin modificar dentro de las máquinas virtuales (Windows XP/2003 y UNIX antiguos)
• Soporte para Intel PAE (Physical Addressing Extensions) en servidores de 32 bits con más de 4 GB de RAM
• Soporte para las arquitecturas x86/64 (tanto AMD64 como EM64T)
• Soporte para SMP (Symmetric Multi-Processor)
• Herramientas de control
• Soporte de ACPI (Advanced Configuration and Power Interface)
• Soporte para gráficos AGP/DRM
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:
• Es conveniente usar el mirror más cercano a nuestra situación geográfica.
• El valor de la directiva gateway deberá cambiarse a la puerta de enlace que usemos para salir a Internet.
• La máscara de red deberá de modificarse en corcondancia a la red que tengamos configurada también.
• Si queremos usar asignación dinámica de dirección IP en lugar de estática, usaremos dhcp = 1 en lugar de gateway y netmask.
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:
• xm console xen01 nos permitirá conectar una consola a la máquina virtual xen01
• xm list nos mostrará una lista de las máquinas virtuales en ejecución y algunos datos de ellas. Un ejemplo de lo que veríamos sería lo siguiente:
• Name ID Mem(MiB) VCPUs State Time(s)
• Domain-0 0 98 1 r----- 5068.6
• xen01 164 128 1 r----- 7.6
• xen-list-images nos mostrará una lista de las imágenes existentes y su dirección IP actual.
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:
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:
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:
• 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 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:
• Enlaza la interfaz vif#.0 al puente xenbr0.
• Levanta la interfaz vif#.0.
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:
• Xen Tools, hechas en Python y disponibles como paquete Debian (utilizadas en este artículo para la creación de máquinas virtuales).
• MLN (del inglés, Manage Large Networks, hechas en Perl.
• Enomalism, un gestor gráfico programado en Python con el MVC TurboGears.
• ConVirt, hecho en Python y GTK, gestor gráfico disponible como paquete Debian.
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.
Estas son, de forma resumida, algunas de sus características:
• Gestión de múltiples servidores. Permite gestionar todos nuestros servidores y todos las máquinas virtuales que en ellos se estén ejecutando sin la necesidad de instalar agente alguno.
• Vista global centralizada. Permite ver el rendimiento, la disponibilidad y la configuración de todos nuestros servidores y máquinas virtuales de un vistazo. Permite llevar a cabo tareas administrativas, de monitorización y de actualización directamente dede la vista centralizada con unos pocos clicks de ratón.
• Comunicaciones seguras. XenMan usa túneles SSH para comunicarse con los servidores. SSH es considerado hoy en día como el estándar para operaciones remotas seguras.
• Almacén de imágenes. Permite guardar imágenes de sistemas operativos huéspedes para distribuirlas fácilmente por nuestros servidores según sea necesario. XenMan se ocupa de descargar dichas imágenes de manera transparente.
• Operar remotamente. Puede verse instantáneamente la información del SO de todos los servidores remotos y reiniciar todas las máquinas virtuales de un servidor con un único click.
• Facilidad de uso. Su interfaz de usuario es muy intuitiva y sencilla de aprender a utilizar.
• Es gratuito y de libre distribución.
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.
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:
• Descomentamos la directiva xend-tcp-xmlrpc-server y le cambiamos el valor a yes en el fichero de configuración /etc/xen/xend-config.sxp del servidor y reiniciamos Xen con /etc/init.d/xend restart.
• Nos aseguramos de poder hacer login mediante SSH como root en el servidor (directiva PermitRootLogin a yes en el /etc/ssh/sshd_config del servidor).
• Establecemos acceso al servidor por SSH mediante autenticación de clave pública/privada.
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:
• Creamos un par claves DSA pública/privada en la máquina cliente (cuando se nos pregunte por una contraseña, pulsamos intro para dejarla en blanco):
ssh-keygen -t dsa
• Copiamos la clave pública de la máquina cliente (~/.ssh/id_dsa.pub) al directorio de trabajo del servidor.
scp ~/.ssh/id_dsa.pub <servidor>:
• En el servidor, añadimos el contenido del fichero recién copiado (~/id_dsa.pub) al fichero ~/.ssh/authorized_keys2:
cat ~/id_dsa.pub >> ~/.ssh/authorized_keys2
• En el servidor, nos aseguramos de que el directorio ~/.ssh tenga permisos 700 y el fichero ~/.ssh/authorized_keys2 tenga permisos 600.
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:
• Asistente de instalación para facilitar la instalación de los componentes principales que utiliza el servidor LDAP ya instalado en nuestro servidor.
• Capacidad para cambiar el tamaño de las particiones de las máquinas virtuales utilizando LVM (del inglés, Logical Volume Manager).
• Posibilidad de cambiar la asignación de CPU y memoria de las máquinas virtuales.
• Soporte para múltiples distribuciones de Linux y BSD.
• Interfaz de usuario basado en AJAX claro, optimizado y fácil de utilizar.
• Gestión de usuarios mejorada y control de las ACL (del inglés, Access Control Lists) del dominio.
• Programado según el paradigma Modelo-Vista-Controlador de TurboGears.
• Soporte de sHype/ACM en Fedora Core 6.
• Soporte para Windows XP/Vista a través de XenSource Enterprise.
• API disponible y soporte para Web Services para obtener una verdadera arquitectura orientada a servicios.
• Soporte para múltiples servidores.
• Soporte de VMcasting.
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.
Bibliografía
• Computer Laboratory - Xen virtual machine monitor
• Computer Laboratory - Architecture
• Installing Xen 3.0 upon Debian Sarge
• Installing Xen 3.0 upon Debian Unstable, with a custom Kernel
• Xen 3 for Debian
• Xen Virtualization and Linux Clustering, Part 1
• Building A Virtual Cluster with Xen (Part One)
• The Perfect Xen 3.0 Setup For Debian
• How To Set Up Xen 3.0 From Binaries In Ubuntu 6.06 LTS (Dapper Drake)
• X86 virtualization
• Xen
• Hypervisor
• XenSource Products - Xen 3.0
• Xen Wiki - XenDownloads
• Xen Wiki - XenNetworking
• Xen Wiki - IntelVT
• Linux Virtualization with Xen
• Jailtime
• Enomalism
Historial de revisiones
Fecha Versión Cambios
29/08/2006 1.0 Documento inicial
23/03/2007 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.
no se olviden de comentar.saludos