Problema

En entornos donde un único nodo ejecuta Debian 13 con Xen y aloja varias máquinas virtuales críticas (DHCP, LDAP, Kerberos, servicios de backup, etc.), cualquier intervención profunda en el hipervisor implica riesgo de interrupción. La práctica habitual consiste en “apagar, actualizar y volver a encender”, lo que genera ventanas de indisponibilidad que los usuarios finales no pueden tolerar. La necesidad es disponer de un host de respaldo que pueda asumir la carga, mantener la misma dirección IP/MAC y permitir trabajar en el nodo original sin afectar a los clientes.

Causa

Los factores que convierten esta tarea en un dolor de cabeza son:

  • Acoplamiento estático de red – Las VMs y los servicios dependen de direcciones IP y MAC fijas. Cambiar esas direcciones obliga a actualizar manualmente DHCP, DNS, reglas de firewall y scripts de autenticación.
  • Falta de almacenamiento compartido – Sin un SAN/NFS común, los discos de las VMs deben copiarse físicamente, lo que alarga el tiempo de sincronización y aumenta la probabilidad de desincronización.
  • Hipervisor legado – Xen 4.21 no ofrece migración en vivo entre hosts con hardware heterogéneo, por lo que la única opción es una replicación offline.
  • Documentación insuficiente – Cuando la topología de red y los bindings de MAC no están registrados, cualquier cambio inesperado puede romper la autenticación de Kerberos o la resolución de nombres.

Solución

Una estrategia robusta combina replicación de discos, reutilización de la identidad de red y pruebas de failover antes de tocar el nodo productivo.

1. Preparar el host de respaldo

  1. Instalar la misma versión de Debian 13 y el paquete xen-hypervisor-4.21 en el servidor antiguo.
  2. Configurar la misma red física (bridge xenbr0) y asegurarse de que el módulo bridge está cargado.
  3. Reservar la dirección IP del nodo original en el switch de capa 2 (puede hacerse con una entrada estática en el DHCP o con una reserva de ARP).

2. Sincronizar discos y configuraciones

  • Snapshot de cada VM en el nodo original con xl save -c <domU> /tmp/<domU>.img.
  • Copiar los snapshots y los archivos de configuración (/etc/xen/*.cfg) al host de respaldo usando rsync sobre SSH.
  • En el host de respaldo, restaurar los snapshots con xl restore -c /tmp/<domU>.img.

3. Mantener la identidad MAC

Xen permite sobrescribir la MAC en el archivo de configuración. Copiar la línea vif = ['mac=aa:bb:cc:dd:ee:ff,bridge=xenbr0'] tal cual. Si el hipervisor genera una nueva MAC, editarla manualmente para que coincida con la original; de lo contrario, los clientes que usan filtrado de MAC perderán la conectividad.

4. Cambiar la IP del nodo sin tocar los clientes

Una vez que los discos están en el host de respaldo, apagar el nodo original, mover el cable de red o la VLAN al nuevo hardware y activar la misma IP. En la mayoría de los switches, enviar un gratuitous ARP (arping -c 3 -A -I xenbr0 <IP>) obliga a que la tabla ARP de los clientes se actualice inmediatamente.

5. Validar y volver a la producción

Con el nodo de respaldo en línea, probar cada servicio (DHCP lease, LDAP bind, Kerberos ticket) desde una máquina de prueba. Cuando la migración del hipervisor esté completa, repetir el proceso inverso: sincronizar de nuevo los discos, volver a asignar la IP al nodo modernizado y validar.

Alternativas

  • Proxmox con replicación integrada – Si el plan incluye migrar a Proxmox, habilitar la replicación de VMs (pve-replicate) simplifica el proceso, pero requiere que ambos nodos ejecuten Proxmox.
  • DRBD – Para entornos donde la latencia de red es baja, replicar los discos a nivel de bloque permite conmutación por error casi instantánea, aunque añade complejidad de configuración.
  • Live migration con Xen 4.21 – Solo viable si ambos hosts comparten el mismo pool de almacenamiento y la CPU es compatible; de lo contrario, la migración offline es la única opción segura.

Cuándo aplicar esta solución

Utilízala cuando:

  • Necesites rehacer el hipervisor, actualizar el kernel o cambiar la arquitectura del nodo.
  • Cuentas con un servidor de repuesto que puede asumir la carga completa durante varios días.
  • Los servicios críticos no toleran más de unos minutos de downtime.

Evítala si:

  • No puedes reservar la misma dirección IP/MAC porque la red está estrictamente segmentada y no permite ARP spoofing.
  • La carga total supera la capacidad del host de respaldo.
  • Requieres migración sin ninguna interrupción y dispones de un storage compartido que permita live migration.

Código

# 1. Snapshot de la VM en el nodo original
xl save -c vm01 /tmp/vm01.img

# 2. Copia segura de discos y configuración
rsync -avz -e ssh /etc/xen/vm01.cfg root@backup:/etc/xen/
rsync -avz -e ssh /var/lib/xen/images/vm01.img root@backup:/var/lib/xen/images/

# 3. Restaurar en el nodo de respaldo
ssh root@backup "xl restore -c /tmp/vm01.img"

# 4. Enviar gratuitous ARP para actualizar la tabla ARP de los clientes
arping -c 3 -A -I xenbr0 192.168.10.10

Verificación

  1. Conectividad – Desde una máquina cliente, ejecutar ping <IP> y confirmar respuesta sin pérdida.
  2. Servicios críticos –
    • ldapsearch -x -b dc=example,dc=org debe devolver resultados.
    • kinit [email protected] debe obtener un ticket sin error.
    • dhclient -v en una estación de prueba debe recibir una lease del servidor DHCP.
  3. Logs – Revisar /var/log/xen/xend.log y los logs de cada servicio para detectar errores de binding o de MAC conflictiva.
  4. Failback – Repetir los pasos inversos y comprobar que los clientes siguen respondiendo tras el retorno al nodo modernizado.

Notas adicionales

  • Documentar MAC/IP antes de iniciar la replicación evita sorpresas cuando el switch bloquea puertos por seguridad.
  • Mantener backups offline de los snapshots permite volver a un estado previo si la restauración falla.
  • Automatizar con Ansible: un playbook que ejecute los rsync, ajuste los archivos de configuración y envíe el ARP reduce errores humanos.
  • Monitoreo continuo: habilitar nagios o prometheus para observar latencia y disponibilidad durante el periodo de conmutación.
  • Pruebas de carga en el host de respaldo antes de la migración real garantizan que la CPU y la RAM son suficientes para soportar la carga pico.

Con este enfoque, la reestructuración del nodo original se vuelve una tarea planificada y reversible, sin obligar a los usuarios a cambiar configuraciones ni a experimentar interrupciones prolongadas.