XenSever - Backup con Snapshots

Este método permite realizar backups de tus máquinas virtuales en formato nativo de Citrix XenServer.

Básicamente el proceso es hacer un snapshot de cada maquina virtual especificada en el fichero de configuración (backup2.cfg) y exportarla a un filesystem del domain0, ese puede ser NFS, SMB, Local... Una vez exportada la maquina virtual la comprime usando gzip. Cada vez que se ejecuta el script comprueba que no haya maquinas más antiguas de siete días en el FS de destino.

Se compone de 3 ficheros:

-backup2.cfg #Fichero de configuración donde se define el disco/directorio de destino del backup y las maquinas virtuales que queremos hacer backup.

-backup2.sh #La shell que lanza el proceso, se puede poner en un cron.

-backup2.log #El log de la shell

Puedes descargarlos desde: https://github.com/fsmsystems/stuff/tree/master/XEN-Backup o mediante git.

XenServer - RedHat / CentOS Paravirtualizados

Una de las ventajas de usar XenServer es la posibilidad de arrancar las máquinas virtuales en modo paravirtualizado (PV). Algunas distros dificultan un poco la instalación en PV directamente desde el Setup. Ese es el caso de Red Hat o CentOS que por defecto se instalan en modo Virtualización completa (HVM).

Una vez instalado el sistema, modificamos los siguientes parámetros del grub:

title CentOS Xen (2.6.18-53.1.14.el5xen)

        root (hd0,0)

        kernel /xen.gz-2.6.18-53.1.14.el5

          module /vmlinuz-2.6.18-53.1.14.el5xen ro root=/dev/VolGroup00/LogVol00

          module /myinitrd.img

Modificamos las líneas en negrita por:

title CentOS (2.6.18-53.1.14.el5xen)

        root (hd0,0)

        kernel /vmlinuz-2.6.18-53.1.14.el5xen ro root=/dev/VolGroup00/LogVol00

        initrd /myinitrd.img

Reiniciamos con el nuevo kernel y creamos un nuevo initrd, sino nos aparecerá el error:

mount: could not find filesystem '/dev/root'

Setting up other filesystems.

Setting up new root fs setuproot:

 ...

Booting has failed

Genramos el nuevo initrd. El nuevo initrd hay que generarlo ignorando el soporte SCSI mediante la siguiente línea:

mkinitrd --omit-scsi-modules --with=xennet --with=xenblk --preload=xenblk initrd-$(uname -r)-no-scsi.img $(uname -r)

Apagamos la maquina virtual y modificamos los siguientes parámetros mediante el CLI para que XenServer reconozca que tiene que arrancar esta máquina como PV.

xe vm-param-set uuid= HVM-boot-policy=""

xe vm-param-set uuid= PV-bootloader=pygrub

xe vm-param-set uuid= PV-args="console=ttyS0 xencons=ttyS"

La volvemos arrancar y tendría que iniciarse correctamente. Si aparece siguiente el error:

Error: (2, 'Invalid kernel', "elf_xen_note_check: ERROR: Not a Xen-ELF image: No ELF notes or '__xen_guest' section found.\n")

significa que hay algún problema con la config del grub, comprueba que el kernel que has configurado en el grub sea el correcto.

XenServer - Migración de maquinas virtuales entre diferentes pools

El tema en cuestión es bastante habitual, lo he visto preguntado en foros y también, personalmente, me he encontrado con la necesidad de encontrar una solución al hecho de traspasar las maquinas virtuales de un pool a otro como podria darse el caso en una migración de entorno físico donde los nuevos servidores tienen un hardware completamente distinto a los servidores domain0 que tenemos en producción.

Para ello utilizo una maquina virtual en la misma red que el management de los domain0  y una LUN conectada a los dos entornos, no hace falta que sea a todos los miembros del pool, yo lo he hecho con uno domain0 de cada entorno. El proceso tiene dos partes:

Exportación de la VM 

Pool-1  Exportamos la VM  a la LUN compartida

Importación de la VM

Pool-2  Importamos la VM desde la LUN al nuevo storage del nuevo pool

El proceso a mano seria:

1- Montamos la LUN en el serividor de origen

2- Apagamos la maquina virtual: xe vm-shutdown name-label=vm_a_migrar

3- Exportamos la VM: 

xe vm-export name-label=vm_a_migrar filename=LUNFS/vm_a_migrar.xva

4- Desmontamos el FS de la LUN

5- Montamos la LUN en el serividor de destino

6- Importamos la VM: xe vm-import filename=LUNFS/vm_a_migrar.xva

7- Desmontamos el FS de la LUN

El proceso es sencillo y se puede hacer a mano, pero para no corromper el filesystem en caso que por error montara el EXT3 de la LUN en dos servidores a la vez, he hecho el siguiente script de bash (migrate.sh) que monta y desmonta la LUN en cada pool para cada uno de los procesos Exportación/importación de modo que solo esté montado en un servidor a la vez.

La sintaxis es migrate.sh nombre_de_la_vm entonces el script se encarga de apagar la maquina virtual,  hacer la exportación xe vm-import ... desde el servidor original $S_OR y la importación en servidor (pool) de destino $S_DE de la maquina virtual que le hemos especificado. Una vez finaliza deja la máquina virtual original y la nueva apagada y la LUN desmontada en ambos servidores.

Si en tu entorno no se puede para las maquinas en producción, puedes hacer el mismo proceso pero en vez de apagar la maquina, capturar un snapshot y luego exportarlo como maquina virtual mediante: 

xe template-param-set is-a-template=false ha-always-run=false uuid=$snapshotUUID

Espero que les sirva de utilidad.
Saludos

Ferran Serafini, nuevo moderador de los foros de virtualización XenServer

Tal día como hoy, hace una hora, se me ha presentado oficialmente como moderador de los foros de virtualización de XenServer en http://www.josemariagonzalez.es/foros/ donde estaré encantado de poder ayudaros en vuestros problemas con XenServer. 

Para quien no conozca este site, es una web de referencia dentro del mundo de la virtualización. Desde que empece a seguirlo percibí que tanto la comunidad de usuarios recurrentes como los nuevos, aportan preguntas y soluciones de alto nivel. Es por eso que para mí es un honor poder formar parte de esta comunidad como moderador.

Aparte del foro podemos encontrar el blog http://www.josemariagonzalez.es/ todo un blog de referencia para entusiastas de la virtualización galardonado por ejemplo con la categoria de vExpert durante tres años consecutivos. Desde hace un tiempo también podemos ver a José María González en http://www.virtualizacion.tv/ donde realiza el "show de la virtualización y Cloud Computing", un entretenido programa semanal donde se exponen trucos, casos de éxito y respuestas a preguntas.

Des de aquí mando le mando un saludo a él y a todo su comunidad.

XenServer - Netback CPU al 100% y sin red

El otro día mientras cambiaba la configuración de una Network para que utilizara otra NIC y posteriormente eliminar las antiguas Network con la NIC anterior tuve una caída "chungisima"... 

Todas la máquinas virtuales de dos domain0 se quedaron sin conectividad por otra Network que nada tenia que ver con las que estaba reconfigurando.

Lo que se podía ver en esos domain0 era un proceso "netback" al 100% de CPU, intenté matar el proceso sin fortuna. Al final se recuperó reiniciando los servidores, el susto fué importante.

Googleando por la red he visto que no soy el único que ha tenido este tipo de caidas. Al parecer este error esta causado porque el servidor domain0 se queda sin memoria. Se puede solucionar asignando una cantidad de memoria exclusiva para el domain0 mediante el siguiente parametro en el grub:

dom0_mem=512M

Y mediante el fichero de config de Xen cambiando dom0-min-mem=256 por dom0-min-mem=0

Esta solución funcionará para plataformas Xen OpenSource pero no para Citrix XenServer.

Entrando un poco a fondo de lo que es netback

netback forma parte de los Backend Drivers, estos están iniciados en los Dom0. Tenemos principalmente controladores de red y controladores de bloqueos. Este controlado en concreto forma parte de los modulos de red y reside en sparse/drives/xen/netback. El controlador de bloqueo esta en sparse/drives/xen/blkback.

Hay muchas cosas en común entre los controladores netback y blkback. La diferencia principal es que los controladores de blkback corren bajo un hilo del kernel (xenblkd), mientras que el controlador netback no corre en ningún hilo del núcleo.

Posiblemente al quedarnos sin memoria, la interconexión entre NetFront y NetBack dejó  las VM incomunicadas.