LinuxParty

Esta entrada está enfocada a Xen, proyecto Open Source con el que podremos para-virtualizar hardware/software, consiguiendo con ello un gran rendimiento en nuestras máquinas virtuales.

Conceptos básicos

• Hypervisor: Monitor de máquina virtual ( VMM, Virtual Machine Monitor), es una capa creada sobre el hardware de la máquina física sobre la que se van creando MVs cada una de las cuales puede contener distintos OS y aplicaciones. El hypervisor es el encargado de gestionar la plataforma de hardware, haciendo que las máquinas virtuales estén completamente aisladas.
• Domains: Cada uno de los sistemas operativos virtuales que corre sobre Xen. Son denominados domU (donde U es el número de máquina) y es de especial importancia saber que dom0 es como un guest invitado (OS virtualizado) solo que con dos funciones definidas:

1. Trabaja junto al hypervisor para hacer que este inicie o detenga a los guest invitados, es decir, controla al hypervisor.
2. Contiene los drivers de los dispositivos necesarios para direccionar el hardware.

• Para-virtualización: También llamada bare-metal. Utiliza OS modificados los cuales son conscientes de que están siendo virtualizados (guest), por lo que no se necesitan llamadas especiales a dispositivos de hardware virtual (emulación de hardware con QEMU como por ejemplo en KVM), es decir acceden directamente al hardware “sin intermediarios” lo que favorece al rendimiento de las máquinas. Xen también acepta la full-virtualization. En la para-virtualización, hasta el propio sistema operativo anfitrión (el que utilizaremos para virtualizar) lleva un kernel modificado, algo que se consigue instalando el paquete de herramientas Xen.
• Full-virtualization (Hardware Virtual Machine, HVM): La virtualización “convencional”. Se virtualiza un OS corriente que se envuelve en “una capa” que crear llamadas a los recursos hardware (emulación), esto requiere de mas recursos que la para-virtualización, además de extensiones especiales de la CPU (VT-x para procesadores Intel y AMD-V para procesadores AMD). La ventaja es que podemos virtualizar cualquier OS.

Que es Xen project

Xen project es un paquete que consiste en un Xen project-enable kernel, el hypervisor, una versión modificada de QEMU para dar soporte a HVM y un kit de herramientas para la administración.

Los OS virtualizados en Xen son llamados DomU, no tienen privilegios para acceder directamente al hardware, en cambio el dom0 si.

El dom0 contiene una toolstack y consola para permitir al usuario administrador administrar la creación, destrucción y configuración de los guest. El toolstack trabaja a través de una consola, una interfaz gráfica o una interfaz en cloud como openstack o cloudstack.

dom0 necesita de un Xen project que habilite las características pertinentes del kernel para hacer posible la para-virtualización, es por ello que no todos los OS Linux sirven para para-virtualizar con Xen. A partir de la serie 2.6.24 del kernel de linux se habilitó la PV utilizando Linux pvops framework.

Si vamos a virtualizar un sistema cualquiera mediante HVM con Xen, este no necesitará de ninguna extensión en su kernel (incluso Windows puede ser virtualizado) y para ello Xen utilizará QEMU (emulación). Al utilizar la emulación, los guest sufrirán problemas de rendimiento en comparación a si son para-virtualizados con Xen.

En resumen: Xen es un proyecto de código abierto que nos permite para-virtualizar sistemas operativos ofreciendo un aumento en el rendimiento de estos, debido a que no existe una capa de emulación entre el hypervisor (controlador de la virtualización) y los sistemas virtualizados. Las llamadas al sistemas se hacen directas entre el hypervisor y los sistemas invitados. Para ello necesitaremos que el sistema que contiene al hypervisor Xen posea ciertas particularidades al igual que los sistemas que utilizaremos en las máquinas virtuales (deben de estar modificados para poder ser virtualizados).

Instalación Debian y Xen

Requisitos:

• Servidor x86_64
• Si vamos a crear los guest bajo HVM (full-virtualization, no es nuestro caso), entonces necesitaremos soporte para VT-d o AMD-V
• Disco de almacenamiento para alojar el host anfitrión (Xen) y los guest (SSD recomendado)
• Un CD/DVD o unidad USB
• Acceso a Internet para descargar Debian (el sistema anfitrión sobre el que instalaremos la suit de Xen)
• Si vamos a utilizar HVM entonces deberemos de activar el soporte para emulación en la BIOS (podemos saltar esto, ya que nosotros aquí vamos a para-virtualizar), no obstante, esto se hace en la BIOS y por lo general se encuentra en pestañas con el nombre Enable “Virtualization Technology” o “Enable Intel VT”, normalmente bajo el menú “Advanced Chipset Features”

Instalar Debian

Para descargar en instalar Debian (sistema base para nuestra para-virtualización con Xen) 

Es posible (si no hemos formateado los volúmenes lógicos durante la instalación), que tengamos que hacerlo una vez iniciado el sistema y además configurar el archivo /etc/fstab:

# mkfs.ext4 /dev/mapper/xen_grp-lv_home

# mkfs.ext4 /dev/mapper/xen_grp-lv_images

# mv -f /home/miuser /mnt/

# mount /dev/mapper/xen_grp-lv_home /home

# mv -f /mnt/miuser /home/

# vi /etc/fstab
/dev/mapper/xen_grp-lv_home /home ext4 defaults 0 0
/dev/mapper/xen_grp-lv_images /images ext4 defaults 0 0

# mount -a

# df -h
S.ficheros Tamaño Usados Disp Uso% Montado en
/dev/sda1 46G 1,4G 44G 3% /
udev 10M 0 10M 0% /dev
tmpfs 350M 4,9M 345M 2% /run
tmpfs 875M 0 875M 0% /dev/shm
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 875M 0 875M 0% /sys/fs/cgroup
/dev/mapper/xen_grp-lv_home 92G 60M 87G 1% /home
/dev/mapper/xen_grp-lv_images 778G 69M 738G 1% /images
tmpfs 175M 0 175M 0% /run/user/0

Nota: La próxima vez que reiniciemos estará todo montado

Instalar Xen project

Para dar soporte Xen a nuestro Debian instalaremos el paquete xen-linux-system el cual contiene todo lo necesario para comenzar: grub-xen-bin, grub-xen-host, qemu-system-x86, qemu-utils, xen-hypervisor-4.4-amd64 y xen-utils-4.4 (entre otros)

# apt-get -P install xen-linux-system xen-tools

Ahora ya tendremos instalado el hypervisor, el Xen project kernel y las Xen tools.

Configurar Xen

Configurar Grub

Para hacer que inicie el hypervisor al arrancar el servidor, necesitaremos modificar algunos parámetros de GRUB.

El archivo principal de GRUB es /boot/grub/grub.cfg, pero no editaremos este archivo directamente ya que cada vez que un nuevo kernel es instalado este archivo cambia. En vez de ese archivo, modificaremos los scripts que se encuentran bajo el directorio /etc/grub.d/* que son configurados vía /etc/default/grub.

Para darle prioridad de arranque al hypervisor (que sea la opción de arranque por defecto) vamos a ejecutar el siguiente comando:

# dpkg-divert --divert /etc/grub.d/08_linux_xen --rename /etc/grub.d/20_linux_xen

Actualizamos /boot/grub/grub.cfg:

# update-grub

Si ahora reiniciamos el servidor, lo primero que arrancará será el hypervisor

Una vez reiniciado podemos ejecutar el siguiente comando para ver cierta información sobre Xen:

# xen info

Configurar red: Bridge (puente de red)

Para que las máquinas virtuales tengan acceso a Internet a través de Dom0 (servidor anfitrión e hypervisor) vamos a crear un puente de red (bridge) mediante software para conectar la interfaz física (normalmente eth0) con cada interfaz virtual.

Para no alargar esta entrada demasiado, podemos acudir aquí donde explicamos como crear un puente de red.

Configurar la memoria de Dom0

Es una buena práctica asignar cierta cantidad de memoria fija a Dom0, de manera que el resto pueda ser dedicada exclusivamente a los hosts virtuales.

Para levar a cabo tal configuración deberemos de modificar los parámetros de GRUB.

Si tenemos GRUB Legacy deberemos de modificar el archivo /boot/grub/grub.conf o /boot/grub/menu.lst y añadir el siguiente contenido (dom0_mem=512M,max:512M) en la línea del kernel  quedando algo así:

title Xen 4.1.0 / pv_ops dom0 kernel 2.6.32.3
    root (hd0,0)
    kernel /xen-4.0.gz dom0_mem=512M,max:512M loglvl=all guest_loglvl=all
    module /vmlinuz-2.6.32.36 ro root=/dev/sda2 console=hvc0 earlyprintk=xen nomodeset
    module /initrd-2.6.32.36.img

Si en cambio tenemos GRUB (GRUB2) añadiremos la siguiente línea (GRUB_CMDLINE_XEN_DEFAULT=”dom0_mem=512M,max:512M”) al archivo /etc/default/grub.

Nota: Esto suponiendo que le queremos dar 512MB de lo contrario ajustar a gusto.

Ahora solo queda actualizar GRUB y reiniciar el servidor:

# update-grub

# shutdown -r now

Configurar la Virtual memory ballooning

Memory ballooning es una técnica empleada por los hypervisores mediante la cual se reclama memoria RAM no utilizada por los  guest de manera que esta pueda ser compartida por el resto de hosts (hasta aquí, way).

Esto tiene ciertas implicaciones, por ejemplo que un host ya no necesite la memoria, el hypervisor la reclame para otra máquina y a continuación la máquina vuelve a necesitar esta memoria pero ya no la tiene!! y peor aún el hypervisor no puede cedérsela porque ya la tiene otro guest. Otra desventaja es que una máquina virtual necesite un gran tamaño de memoria en un determinado momento y el hypervisor se la ceda hasta tal punto que Dom0 (el encargado de gestionar las máquinas) se quede sin memoria física y comience a hacer swapping.

En este link explican bastante bien este concepto: http://www.vfrank.org/2013/09/18/understanding-vmware-ballooning/

Desde Xen aconsejan dar una memoria física estática a Dom0 y desactivar el ballooning de manera que nuestras máquinas virtuales tengan una configuración de recursos óptimos para el fin que vayan a desempeñar. Esto será lo mas parecido a tener máquinas aisladas.

Para configurar el ballooning deberemos de modificar los siguientes archivos:

Si estamos usando el toolstack XL:

# vi /etc/xen/xl.conf
autoballoon=0

Si estamos utilizando xend toolstack:

# vi /etc/xen/xend-config.sxp
dom0-min-mem 512
enable-dom0-ballooning no

Ahora reiniciamos nuevamente el servidor para que los cambios se realicen. Una vez iniciado el servidor podremos comprobar con los siguiente comando que Dom0 ahora dispone de 512MB de RAM quedando el resto de nuestra memoria física libre para crear máquinas virtuales.

Para XL toolstack:

# xl list  => nos dirá la cantidad de memoria asignada a Dom0

# xl info => nos dirá la cantidad de memoria disponible en el hypervisor

Para xend toolstack:

# xm list

# xm info

CPU Time

Desde Xen aconsejan duplicar el peso de uso de CPU de dom0 frente a los guest de manera que este tenga mas tiempo de CPU para procesar y servir las solicitudes I/O de las VMs, lo que favorecerá al rendimiento en general.

Por defecto tanto los guest como dom0 tienen un peso de 256, se aconseja aplicar como máximo el doble de esta cantidad a dom0 de la siguiente manera:

# xl sched-credit -d Domain-0 -w 512

# xm sched-credit -d Domain-0 -w 512

Podemos ver ahora el peso tal que así:

# xl sched-credit -d Domain-0

# xm sched-credit -d Domain-0

Importante: Deberemos de ejecutar este comando cada vez que el servidor anfitrión sea reiniciado. Podemos o bien crear una tarea cron, crear un script, o añadirlo a /etc/rc.local pero deberemos de tener en cuenta que este comando debe de ser ejecutado después de que Xen incie.

Asignar core de CPU

Otra buena práctica es asignar exclusivamente un core de CPU a dom0. Para configurar el core tan solo deberemos de modificar nuevamente la línea del kernel de Xen en GRUB añadiendo lo siguiente:

dom0_max_vcpus=1 dom0_vcpus_pin

Tras reiniciar, podemos comprobar los cambios con el siguiente comando:

# xl vcpu-list

# xm vcpu-list

Importante: Ahora cuando configuremos los guest deberemos de especificar que estos no utilicen ese pin. Podriamos especificar por ejemplo el uso del 2 al 7. Esto se hace en el archivo /etc/xen/<guest> añadiendo cpus=”2-7″

Podemos acudir a este a FAQ si tuviesemos dudas o problemas.