Disponible Xen 4.4

Tras 8 meses de intenso desarrollo la comunidad de Xen anunció la tan esperada nueva release: Xen Project Hypervisor version 4.4. En sacar esta nueva versión, colaboraron empresas tales como AMD, Intel, Oracle y por supuesto Citrix.

La nota con todos los cambios y mejoras efectuados la puedes leer aquí, pero los más destacados son:

• Soporte grub2 para Xen Project PV Images
• Soporte experimental para EFI boot
• Integración entre GlusterFS y Xen
• Soporte de entornos móviles y mayor integración "en la nube"
• Soporte para arquitecturas ARM
• Hipervisor ABI para ARM finalmente estable
• Disponibilidad de sistemas de 64 bits sobre plataforma ARM
• Soporte LVM sobre plataforma ARM

Más información en la web oficial: www.xenproject.org

Leer más

Actualización de pyGRUB en máquinas virtuales

pyGrub es un pequeño GRUB, escrito en Python que se instala con las xen-utils en sistemas Debian/Ubuntu y gracias al cual se manejan perfectamente las entradas de GRUB de las máquinas virtualizadas. pyGrub viene siendo la versión virtualizada de GRUB. Se instala y configura automáticamente al terminar la instalación de la máquina virtual y coge por defecto aquellos kerneles que la máquina tenga en el momento de finalizar la instalación. También modifica el fichero de configuración de la misma para indicarle que éste será su gestor de arranque.

...
bootloader = '/usr/lib/xen-default/bin/pygrub'
...

Y la apariencia que tiene es similar a la siguiente,

pyGrub Debian - Xen

Es todo prácticamente igual a lo que ya teníamos de GRUB, pero en un entorno virtual. El problema viene a la hora de actualizar el listado kerneles que tiene el sistema disponible para arrancar. Esta configuración hay que hacerla manualmente, ya que ni el comando update-grub ni update-grub2 son capaces de realizarlo.

Simplemente hay que cambiar el fichero /boot/grub/menu.lst y añadir (o sacar) las entradas que así deseemos. En mi caso, tras pasar una máquina de Ubuntu Lucid a Ubuntu Precise tuve que actualizar el fichero, pasando de ésta configuración,

default   0
timeout   2

title     Ubuntu 10.04 LTS
root      (hd0,0)
kernel    /boot/vmlinuz-2.6.32-46-generic-pae root=/dev/xvda2 ro 
initrd    /boot/initrd.img-2.6.32-46-generic-pae

title     Ubuntu 10.04 LTS (Single-User)
root      (hd0,0)
kernel    /boot/vmlinuz-2.6.32-46-generic-pae root=/dev/xvda2 ro single
initrd    /boot/initrd.img-2.6.32-46-generic-pae

A esta otra,

default   1
timeout   2

title     Ubuntu 10.04 LTS
root      (hd0,0)
kernel    /boot/vmlinuz-2.6.32-46-generic-pae root=/dev/xvda2 ro 
initrd    /boot/initrd.img-2.6.32-46-generic-pae

title     Ubuntu 12.04-3.2-virtual LTS
root      (hd0,0)
kernel    /boot/vmlinuz-3.2.0-41-virtual root=/dev/xvda2 ro
initrd    /boot/initrd.img-3.2.0-41-virtual

title     Ubuntu 12.04-3.2 LTS
root      (hd0,0)
kernel    /boot/vmlinuz-3.2.0-41-generic-pae root=/dev/xvda2 ro
initrd    /boot/initrd.img-3.2.0-41-generic-pae

Tras el cambio, desde el dom0 podemos ejecutar el siguiente comando,

shell> /usr/lib/xen-default/bin/pygrub /dev/vg0/my_domU-disk

que mostrará la apariencia que tendrá el gestor de arranque y también nos servirá para saber si está configurado como queremos.

La entrada Actualización de pyGRUB en máquinas virtuales la puedes leer en Puppet Linux.

Leer más

XenSource, PV drivers para windows

Son muchas las personas que deciden optar por sistemas de virtualización de pago, como puede ser XenServer o VMWare, ya que una de las ventajas que presentan es el conocimiento de la plataforma Windows. Si tienes que virtualizar uno o varios equipos con Windows, estas empresas tiene unos driver's que hacen que el equipo Windows virtual se ejecute con mucho mejor rendimiento que si empleas la versión free de Xen.

Sin embargo si deseas seguir usando Xen como sistema de virtualización, pero quieres mejorar el performance de tus equipos Windows, quizás te interesa saber que existen unos drivers "libres", Xen PV Drivers, que modifican el acceso a disco y la tarjeta de red mejorando notablemente el rendimiento, especialmente en lo que acceso a disco se refiere. Los puedes descargar desde aquí.

Leer más

BUG: soft lockup - CPU

Latencia de red (en ms)

Ayer me pasó algo curioso en unas máquinas virtuales bajo XenServer. Hay que decir que estas máquinas están virtualizadas en una infraestructura a la que no hay acceso y sobre la que no sabemos qué tipo de máquinas hay, a mayores de las nuestras. El caso es que todas las nuestras se estaban a ejecutar en mismo nodo del clúster y sin más ni más, comenzaron a subir el uso de CPU y su latencia de red. Gracias a #zabbix, su perfecta monitorización y sus alertas nos pudimos enterar al momento. Dejo un par de gráficas que representan las subidas experimentadas, que como se pueden ver, son considerables.

Consumo de CPU

Lo sorprendente es que la carga de las máquinas se originó sin motivo aparente, ya que no hubo nada "extraño" en la red ni en las máquinas, según las primeras palabras del proveedor. Sin embargo, tras revisar un poco de log's, nos encontramos con el siguiente fallo,

kernel: [12005213.706327] BUG: soft lockup - CPU#0 stuck for 64s! [kjournald:908]
kernel: [12005213.706327] Modules linked in: iptable_filter ip_tables x_tables firewire_sbp2 firewire_core crc_itu_t loop snd_pcm snd_timer parport_pc i2c_piix4 snd i2c_core joydev soundcore snd_page_alloc pcspkr parport processor evdev button psmouse serio_raw ext3 jbd mbcache usbhid hid sg sr_mod cdrom sd_mod crc_t10dif ata_generic ata_piix uhci_hcd 8139too ehci_hcd thermal libata floppy thermal_sys 8139cp mii usbcore nls_base scsi_mod [last unloaded: scsi_wait_scan]
kernel: [12005213.706327]
kernel: [12005213.706327] Pid: 908, comm: kjournald Not tainted (2.6.32-5-686 #1) HVM domU
kernel: [12005213.706327] EIP: 0060:[] EFLAGS: 00000282 CPU: 0
kernel: [12005213.706327] EIP is at cp_interrupt+0x23/0x28a [8139cp]
kernel: [12005213.706327] EAX: f7dea03e EBX: c1360aa0 ECX: c1360aa0 EDX: f6f60001
kernel: [12005213.706327] ESI: f6f62ba0 EDI: 00000020 EBP: f6f62800 ESP: e770fcf4
kernel: [12005213.706327]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
kernel: [12005213.706327] CR0: 8005003b CR2: f8260ffc CR3: 36f58000 CR4: 000006d0
kernel: [12005213.706327] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
kernel: [12005213.706327] DR6: ffff0ff0 DR7: 00000400

Lo más sorprendente que hemos encontrado ha sido la línea de BUG destacada en los log's y el posterior trace completo que hace. Tras investigar un poco a qué pudo ser debido, todo apunta a un fallo en la reserva de IRQ de las máquinas, lo que provocó un incremento de la carga de todos los equipos.

Por lo que hemos podido averiguar a posteriori, el proveedor sí nos reconoció que algunas de las máquinas del clúster efectivamente estaban consumiendo un gran ancho de banda, lo que afectó a las otras, que estaban mucho más ociosas. Se ve que la virtualización todavía no es 100% efectiva bajo ciertas circunstancias.

Leer más

XenServer: backup de máquinas

XenServer, la versión de pago de xen, permite realizar backup's de las máquinas de una forma mucho más simple que la versión free, que se basa en los snapshot de lvm. Aunque internamente XenServer también lo hará, veremos cómo hacerlo desde el interfaz xen de forma mucho más simple y rápidamente.

La idea será crear un snapshot de una máquina en producción (en caliente) y a continuación volver a usarla para comprobar que el backup fue correcto. Los backup's desde línea de comandos, se realiza con el comando xe vm-snapshot.

shell> xe vm-snapshot vm=syslog \
       new-name-label=backup_syslog

Si la máquina de la que se va a realizar backup es un equipo Windows, para darle una mayor compatibilidad se podría usar el soporte VSS.

shell> xe vm-snapshot-with-quiesce vm=win_2k8 \
       new-name-label=backup_win_2k8

Cuando el backup finaliza, la salida que se obtiene es el UUID del snapshot, los cuales podremos ver con el comando xe snapshot-list. Si a éste comando se le pasa el UUID de una de las máquinas virtuales, listará todos los backup's que se han realizado para dicha máquina.

Por defecto, el snapshot de una máquina se crea como una template que luego se podría importar y crear nuevas máquinas a partir de ella. En este caso, lo que estamos realizando es un backup de una máquina, por lo que nos interesa tener dicha máquina y no una plantilla. Para transformar una template a máquina virtual,

shell> xe template-param-set is-a-template=false \
ha-always-run=false uuid=UUID_template

Y ahora exportamos la máquina a una imagen .xva.

shell> xe vm-export uuid=UUID_template filename=/mnt/syslog.xva

Cuando nos haga falta restaurarla, únicamente habrá que importarla en el sistema.

shell> xe vm-import filename=/mnt/syslog.xva preserve=true

Leer más

XenServer: bonding ethX

Una de las desventajas que tiene la virtualización es justamente una de las ventajas, que todos los equipos, o cuando menos un gran número de los mismos, están sobre una única máquina física. Si ésta falla, todos los equipos que se estén ejecutando en ella, también falla. El método que hay para evitar estos fallos es la replicación de hardware. Por ejemplo, a nivel de discos duros/sistema operativo, lo que se hace es usar RAID, así aunque un disco falle, el sistema no falla, ya que está replicado. A nivel de tarjetas de red, existe algo similar, el  bonding. Para poder activarlo, simplemente es necesario que el kernel del sistema lo soporte y en caso de XenSever, sí está soportado.

Existen 7 modos de diferentes de bonding, que son:

• mode=0 (balance-rr)
  Balanceo por round-robin.
  
  Permite tolerancia a fallos y balanceo de cargas. Los datos  son recibidos y enviados secuencialmente por cada interfaz del bond, empezando con el primero disponible. Si uno falla, es deshabilitado del balanceo.
• mode=1 (balance-xor)
  Balanceo de respaldo activo.
  
  Los datos son enviados y recibidos por el interfaz activo del bond. Si éste falla, se empiezan a enviar por el otro disponible.
• mode=2 (balance-xor)
  
  Balanceo XOR para tolerancia a fallos y balanceo de carga.
  Con este modo el interfaz tiene la dirección MAC de las peticiones entrantes con la dirección MAC de una de las NIC's del bond. Una vez que se establece un nuevo enlace, los datos son enviados secuencialmente comenzando con la primera interfaz disponible.

Leer más

Comandos interesantes: xentop

xentop es una herramienta de monitorización de dominios cero (dom 0) que, al igual que top, permite observar en tiempo real los cambios que se van produciendo en las máquinas virtuales así como en el dom 0. Está disponible tanto para XenServer como para xen no comercial.

shell> xentop
xentop - 11:13:29   Xen 4.0.1
6 domains: 1 running, 5 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
Mem: 10485140k total, 10476364k used, 8776k free    CPUs: 4 @ 1995MHz
NAME     STATE  CPU(sec) CPU(%) MEM(k)  MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS ...
apache   --b---  78413   0.1    2093312 20.0   2097152   20.0      1     1    ...
dhcp     --b---  30969   0.0     258304  2.5    262144    2.5      1     1    ...
Domain-0 -----r 260649   4.1    4625408 44.1   no limit  n/a       4     0    ...
mysql    --b---  85804   0.2    2093312 20.0   2097152   20.0      1     1    ...
puppet   -----r 171038   0.5     258304  2.5    262144    2.5      1     1    ...
win      --b---  94523   7.0    1052640 10.0   1052672   10.0      1     1    ...

Leer más

XenServer: instalar Windows 2008

En la última versión de XenServer, existe un fallo conocido por Microsoft que impide la instalación y correcto funcionamiento de Windows 2008 SBS como sistema virtualizado. Para evitar este fallo hay que realizar una serie de pasos, tal como se detalla en la página de soporte de Microsoft.

Los pasos a seguir para evitar que suceda el bug son:

1. Instalar nuestro Windows 2008 desde la plantilla que provee XenServer.
2. En el primer arranque presionar F8 para entrar en modo a prueba de fallos y entramos como administrador.
3. Se modifica la entrada del registro HKLM\SYSTEM\CurrentControlSet\Services\HTTP y se añade el multi-string DependOnService y decimos que sea de tipo CRYPTSVC.
4. Se reinicia el equipo.

Leer más

XenServer: comandos básicos (II)

Seguimos con la lista de comandos útiles para manejar XenServer desde la consola.

• Listado de máquinas virtuales
  

  shell> xe vm-list

• Listado de hosts por pool
  

  shell> xe host-list

• Listado de máquinas en un host
  

  shell> xe vm-list resident-on=UUID

• Listado de repositorios de almacenamiento
  

  shell> xe sr-list

Leer más

XenServer: cómo instalar un hotfix

XenServer, como la mayoría del software existente tiene ciertas vulnerabilidades que van apareciendo con el tiempo y para solucionarlas, sacan parches que pueden ser instalados como upgrades a la versión que esté instalada. La forma de hacerlo desde consola es:

1. Descargamos el parche desde la web oficial.

shell> wget http://support.citrix.com/.../XS56ESP2010.zip

2. Descomprimimos el parche.

shell> unzip XS56ESP2010.zip

3. Instalamos el parche con patch-upload.

shell> xe patch-upload file-name=XS56ESP2010
655996656-1d38-485e-8f9d-fa6fc4859591

4. Aplicamos ahora el parche que se acaba de instalar con patch-pool-apply.

shell> xe patch-pool-apply uuid=655996656-...

5. Podemos ahora verificar que el parche está correctamente aplicado.

shell> xe patch-list

6. Se reinicia el servidor.

shell> reboot

Leer más

XenServer: comandos básicos (I)

XenServer tiene la posibilidad de usarse desde interfaz gráfico, gracias a la potente herramienta que han desarrollado para tal efecto, pero también es posible su manejo desde consola. Para hacerlo, la forma más sencilla es interactuar con la API que provee: La XenAPI. En ella, prácticamente todos los comandos comienzan por xe vm-*.
A continuación veremos los comandos básicos para realizar las principales operaciones:

• Arrancar
  

  shell> xe vm-start name-label=NAME

• Apagar
  

  shell> xe vm-shutdown name-label=NAME

  Se le puede pasar la opción force=true, para forzar el apagado de la máquina, que sería como sacarle la corriente de la misma.

  shell> xe vm-shutdown name-label=NAME force=true

• Reiniciar
  

  shell> xe vm-reboot name-label=NAME

  Al igual que en el apagado, se le puede pasar la opción force=true para forzar el reinicio en caso de que no responda.

  shell> xe vm-reboot name-label=NAME force=true

• Migrar
  
  Se migra una máquina de un servidor físico a otro servidor físico. Para que este comando sea correcto, los servidores necesitarán estar en clúster y además tener un medio de almacenamiento compartido para la máquina a migrar.
  La máquina por su parte necesitará de las xen-tools instaladas para que todo el proceso sea correcto.

  shell> xe vm-migrate name-label=NAME host=server_02

• Exportar
  
  Exporta la máquina como un fichero (una copia del disco) para poder hacer backup del mismo. La máquina en este caso necesita estar apagada. En otro post se indica cómo exportar una máquina encendida (en caliente).

  shell> xe vm-export name-label=NAME filename=/mnt/NAME.xva

• Importar
  
  Permite importar la máquina desde un fichero previamente exportado, ya bien sea del mismo sistema o de otro sistema.

  shell> xe vm-import /mnt/NAME.xva

En todas las opciones se puede pasar el nombre de la máquina o el UUID de la misma. Aquí se muestran con el nombre por la simplicidad que ello conlleva para entenderse.

Leer más