Esta semana nos hemos visto en la tesitura de tener que migrar unas máquinas virtuales basadas en Xen desde un servidor físico a otro con más recursos. A pesar de que Xen incluye herramientas especializadas para estas tareas, hemos preferido seguir nuestra propia «receta» en previsión de una serie de obstáculos que imaginábamos nos podíamos encontrar durante el proceso de migración. Voy a describir a continuación cuales han sido estos obstáculos y las soluciones que utilizamos en cada caso.
La situación era la siguiente: teníamos que migrar varias máquinas virtuales Xen que contenían sendos portales web desde un servidor físico a otro. Aquí se nos presentaba la primera dificultad. A pesar de que las arquitecturas hardware de los servidores eran prácticamente idénticas, no era así en el caso de los sistemas operativos, ya que el origen tenía instalado Debian 4.0 y el destino Debian 5.0. Habrá quien piense que soy un exagerado y que eso no es tanta diferencia. Nada más lejos de la realidad, ya que las versiones de núcleo Linux y del software de virtualización Xen son diferentes, lo que de algún modo impedía el correcto funcionamiento de la herramienta «xm migrate», que fallaba inmediata e indefectiblemente con un error críptico cada vez que era invocada desde la línea de comandos del servidor de origen. A pesar de preparar concienzudamente ambos servidores para permitir la migración al vuelo, la herramienta propia de Xen no hacía su trabajo.
La solución fue relativamente sencilla. Todo consistió en hacer lo mismo que se suponía debía hacer «xm migrate» pero a mano y paso a paso. Lo primero era parar la máquina virtual con «xm shutdown», para proceder a continuación a su copia al servidor destino. Aunque nosotros lo hicimos por SSH, las posibilidades aquí son amplias (FTP, NFS, SMB, USB, etc.). La copia de cada máquina virtual comprendía el fichero imagen del disco principal, el fichero imagen de la memoria de intercambio o swap y el fichero de configuración correspondiente.
Una vez copiados los ficheros al servidor destino, el siguiente paso es arrancar las máquinas virtuales una a una con «xm create». Sin embargo, no iba a ser tan sencillo, ya que Xen se quejó de que le faltaban el núcleo Linux y el initrd de las máquinas virtuales, que procedimos a copiar desde el servidor origen, con lo que el arranque se produjo después sin más problemas.
Para finalizar, quedaban por ajustar algunas cosas, como la configuración de red de Xen (en el servidor origen se usaba el modo bridge mientras que en el destino estaba activo por defecto el modo NAT), la actualización de los DNS de los portales web con la IP del servidor destino y la configuración del proxy inverso residente en los servidores físicos que gestiona las peticiones realizadas a cada máquina virtual.
De esta historia puede obtenerse una valiosa lección. Aunque cualquier sistema de virtualización, incluyendo Xen, hacen su trabajo a un buen nivel, podemos encontrarnos en cualquier momento una serie de problemas que impidan su adecuada gestión y mantenimiento, más teniendo en cuenta lo delicados y exigentes que son. En este sentido, es fundamental tener unos profundos conocimientos y experiencia en administración de sistemas en general y en el sistema de virtualización de nuestra elección en particular para evitarnos males mayores y salir airosos de cualquier situación.