Usando snapshot para equipos virtualizados con XEN en Debian

Pese al título, esta entrada aún necesita llevar un subtítulo: "Usando qcow en máquinas virtuales en Debian Jessie", y ya, no se necesitaría mayor introducción al respecto.

Cuando se sigue una guía de virtualización en Debian, se cae por defecto en la virtualización con XEN. No hay problema, pero parece que hasta Jessie, las herramientas para administración por defecto siguen sin manejar la cuestión de snapshot para las máquinas virtuales.

Tampoco fuí capaz de encontrar una opción en xen-create-image que permita crear las imágenes con formato qcow. Crear la imagen con qemu-img create y luego apuntarla en xen-create-image con --image-dev y --swap-dev  no funciona porque sin importar qué, xen-create-image convierte las imágenes a raw.

Con todo esto, es necesario complicar el proceso de instalación de la siguiente manera:

• Creamos la máquina virtual con un disco raw, que es el formato por defecto:

xen-create-image  --hostname=pdc.salud.gob.sv --vcpus=2 --size=20Gb --memory=896Mb --ip=10.20.20.10 --gateway=10.20.20.1 --bridge=xenbr0 --arch=amd64 --role=udev --dir=/var/lib/xen/

La instalación del sistema base empezará creando dos imágenes: disk.img y swap.img , dentro de /var/lib/xen/domains/pdc.salud.gob.sv/ en este caso según el hostname dado.

• Lo convertimos a qcow (Respecto a preallocation: Resulta que en Jessie no es posible usar full, además, no soy capaz de decir si para el caso de conversión esta opción tiene algún tipo de efecto)

qemu-img convert -O qcow2 -o preallocation=metadata /var/lib/xen/domains/pdc.salud.gob.sv/disk.img /var/lib/xen/domains/pdc.salud.gob.sv/disk.qcow2

• Ahora, modificamos el fichero que define a la máquina virtual para que apunte al nuevo disco: Por xen-create-image, el fichero había quedado de esta forma:

#
#  Disk device(s).
#
root        = '/dev/xvda2 ro'
disk        = [
                  'file:/var/lib/xen/images/domains/pdc.salud.gob.sv/disk.img,xvda2,w',
                  'file:/var/lib/xen/images/domains/pdc.salud.gob.sv/swap.img,xvda1,w',
              ]

Y el gran cambio será file: por tap:qcow2: y la extensión: .img por .qcow2 en donde se apunte al disco que cambiamos

#
#  Disk device(s).
#
root        = '/dev/xvda2 ro'
disk        = [
                  'tap:qcow2:/var/lib/xen/images/domains/pdc.salud.gob.sv/disk.qcow2,xvda2,w',
                  'file:/var/lib/xen/images/domains/pdc.salud.gob.sv/swap.img,xvda1,w',
              ]

Fuentes:
Using qcow2 images in Xen 4.1 on Debian 

Acomodando virt-install para Debian sobre OpenSuSE

Siguiendo la línea de una anterior entrada, me pareció que todo iba bien hasta el momento en que tuve que virtualizar un sistema Debian.
Usando paravirtualización y escogiendo un servidor HTTP como fuente del árbol de instalación, mediante las herramientas virt-manager (Que se encuentra en los repositorios de Open SuSE y CentOS, por ejemplo ), el comando de instalacion

virt-install --prompt --network bridge=br0 --virt-type=xen --location http://ftp.egr.msu.edu/debian/dists/wheezy/main/installer-amd64/ -n enlace --description enlace -r 512 --vcpus=1 --disk path=/dev/system/gateway --os-type=linux --paravirt --arch x86_64 

me arrojaba el siguiente error:

ERROR    'NoneType' object has no attribute '__getitem__'

Después de revisar el log de virt-manager

tail -f  ~/.virtinst/virt-install.log

Llegué a la siguiente solución
Abrimos el fichero

vim /usr/lib/python2.7/site-packages/virtinst/OSDistro.py 
 

Aproximadamente en la línea 80 de dicho fichero, empieza una selección en la código de esta forma (La lista de hecho se extiende un poco màs)

 # FIXME: This 'distro ==' doesn't cut it. 'distro' is from our os
    # dictionary, so would look like 'fedora9' or 'rhel5', so this needs
    # to be a bit more intelligent
    if distro == "fedora" or distro is None:
        stores.append(FedoraDistro)
    if distro == "rhel" or distro is None:
        stores.append(RHELDistro)
    if distro == "centos" or distro is None:
        stores.append(CentOSDistro)
    if distro == "suse" or distro is None:
        stores.append(SuseDistro)
    if distro == "sl" or distro is None:
        stores.append(SLDistro)
    if distro == "debian" or distro is None:
        stores.append(DebianDistro) ... 

Básicamente, el cambio consiste en cambiar el orden de las opciones. Hasta ahora el error sólo aparece cuando el sistema es Debian, por lo tanto basta con anteponer este a SuSE Empresarial

if distro == "fedora" or distro is None:
        stores.append(FedoraDistro)
    if distro == "rhel" or distro is None:
        stores.append(RHELDistro)
    if distro == "centos" or distro is None:
        stores.append(CentOSDistro)
    if distro == "debian" or distro is None:
        stores.append(DebianDistro)
    if distro == "suse" or distro is None:
        stores.append(SuseDistro)
    if distro == "sl" or distro is None:
        stores.append(SLDistro)

Obviamente, si hoy problemas de ese tipo con otras distribuciones, entonces también puede cambiarse el orden con respecto a SLES. 
Y claro, el problema pasa por ser más complicado, pero esta solución chapucera realmente me funciona

Afinando nuestro servidor Xen en Open SuSE

Virtualizar con Open SuSE podría parecer más fácil (que no sencillo) que en otras distros, por el hecho que casi todo es más fácil (que no sencillo) que hacer que en otras distros.

Sólo agrego una último detalle del que parece que nadie se había dado cuenta que faltaba:

Según las buenas prácticas de Xen, se aconseja especificar un máximo de memoria RAM a ser usado por Domain-0. Y no estaría mal el limitar el número de núcleos del procesador a ser usados por él. Que aparte de seguir con la costumbre de no dejar configuraciones por defecto, permite que se gane un poco en rendimiento.

No entiendo porque las herramientas gráficas de OpenSuSE no me funcionaron para ello. Me salté el problema agregando lo siguiente al archivo /etc/default/grub, de donde se leen las configuraciones para crear el archivo  /boot/grub2/grub.cfg

GRUB_CMDLINE_XEN="resume=/dev/system/swap dom0_mem=2048M,max:2048M dom0_max_vcpus=1 splash=silent quiet showopts" 

 Tal como la documentación de Xen lo dice, lo importante acá son las opciones dom0_mem=2048M,max:2048M dom0_max_vcpus=1 

Luego, se crea el archivo grub.cfg de acuerdo a nuestra nueva configuración

grub2-mkconfig -o /boot/grub2/grub.cfg

Después basta con reiniciar, y al volver podrá verse que Domain-0 se restringe al uso de los recursos del sistema tal como se ha especificado.

Algunas pruebas de como la configuración ha funcionado

Y si, posiblemente sea lo que se tenga que hacer en otras distribuciones con Grub2