Live migration de un guest KVM junto con su storage, paso a paso

Mover una máquina virtual en marcha entre hosts sin storage compartido suena a magia hasta que lo ha hecho unas cuantas veces. Entonces es una lista de comprobación: confirmar que los hosts son compatibles, preparar el destino para que el guest encuentre todo lo que espera, ejecutar un comando, y saber cuándo no intentarlo. Esta es esa lista para KVM puro con libvirt.

Qué ocurre realmente durante una live migration

Con --copy-storage-all, libvirt pide a QEMU en el destino que cree el guest, y después transmite el disco mientras el guest sigue funcionando y escribiendo. Una vez que el disco está replicado, la memoria se copia en rondas: cada ronda envía las páginas que el guest ensució durante la anterior. Cuando el conjunto sucio restante es lo bastante pequeño para enviarse dentro del downtime permitido, el guest se pausa, las últimas páginas y el estado de los dispositivos cruzan, y se reanuda en el destino. La pausa suele ser de unos cientos de milisegundos. Las conexiones de red sobreviven porque el guest conserva su MAC y su dirección IP, y el switch aprende la nueva ubicación con los primeros paquetes del guest.

Todo lo que puede salir mal es un desajuste entre lo que el guest espera y lo que el destino ofrece. Así que compruebe eso primero.

Paso uno: decida en caliente o en frío

La live migration es la herramienta adecuada cuando origen y destino son compatibles y la tasa de escritura del guest es moderada. Es la herramienta equivocada cuando todo cambia a la vez: una generación de CPU distinta, un diseño de red distinto y una versión de hipervisor distinta en el mismo movimiento. Entonces el camino seguro es en frío: apague el guest limpiamente, copie el disco, defínalo en el destino, arránquelo, y conserve el origen intacto como rollback.

Un primario de base de datos con una tasa de páginas sucias muy alta puede además no converger nunca. Mida antes de intentarlo:

virsh domdirtyrate-calc <guest> --seconds 5
virsh domstats <guest> --dirtyrate

Paso dos: compruebe la compatibilidad de CPU

El modelo de CPU del guest debe existir en el destino. Si el guest usa host-passthrough, las CPU de los dos hosts deben coincidir en la práctica. Compare la definición del guest con el host de destino:

virsh dumpxml <guest> > guest.xml                       # on the source
xmllint --xpath '//cpu' guest.xml > guest-cpu.xml
virsh hypervisor-cpu-compare guest-cpu.xml              # on the destination

identical o superset significa adelante. incompatible significa cambiar el guest a un modelo de CPU con nombre que ambos hosts admitan (en su siguiente reinicio) o moverlo en frío.

Paso tres: prepare la red del destino

Cada bridge, o VLAN sobre un bridge, al que se conectan las interfaces del guest debe existir en el destino con el mismo nombre, y debe llevar las mismas VLAN en el uplink:

virsh domiflist <guest>      # on the source: which bridges
ip -br link show type bridge # on the destination: do they exist?

Un bridge ausente hace fallar la migración limpiamente al principio. Un bridge que existe pero está sobre un uplink sin la VLAN migra con éxito y deja al guest inalcanzable, que es peor. Compruebe también el lado del switch.

Paso cuatro: prepare el storage del destino

El destino necesita un sitio donde aterrice el disco, en una ruta que libvirt gestione como storage pool:

virsh pool-define-as images dir --target /var/lib/libvirt/images
virsh pool-start images && virsh pool-autostart images

Para la mayoría de las disposiciones libvirt crea la imagen de destino por sí mismo. Para las inusuales, créela de antemano con exactamente el mismo tamaño virtual y el mismo formato que el origen:

qemu-img info --output=json /var/lib/libvirt/images/<guest>.qcow2   # note virtual-size
qemu-img create -f qcow2 /var/lib/libvirt/images/<guest>.qcow2 <virtual-size>

Paso cinco: migre

Desde el host de origen, con acceso SSH por clave al destino como el usuario de libvirt:

virsh migrate --live --persistent --undefinesource \
  --copy-storage-all --auto-converge --verbose \
  <guest> qemu+ssh://<destination>/system

• --live mantiene el guest en marcha.
• --copy-storage-all replica el disco completo. (--copy-storage-inc existe para discos cuya imagen base ya está en el destino.)
• --auto-converge frena ligeramente la CPU del guest si la memoria se ensucia más deprisa de lo que puede enviarse, de modo que los guests ocupados también terminan.
• --persistent y --undefinesource mueven la definición junto con el guest, para que no reaparezca en el host antiguo en el siguiente reinicio.

Usamos la ruta de migración directa en lugar de --tunnelled cuando se copia storage. Mientras se ejecuta, observe el progreso desde un segundo terminal:

virsh domjobinfo <guest>

domjobinfo muestra los datos restantes, la tasa de páginas sucias y el downtime esperado. Si claramente no converge, virsh domjobabort <guest> detiene el trabajo y deja el guest funcionando en el origen, intacto.

Paso seis: verifique a la llegada

Compruebe, desde fuera del guest:

virsh list --all                      # running on the destination only
virsh domblklist <guest>              # disk at the expected path
virsh domifaddr <guest> --source arp  # address visible on the network

Si el guest es un balanceador o una réplica de base de datos, confirme que ha reanudado su papel (estado VRRP, hilos de replicación) en lugar de suponerlo.

Solo después de eso, elimine la imagen de disco antigua del origen, o mejor, consérvela hasta el siguiente ciclo de mantenimiento.

Su lista de comprobación

• En caliente o en frío decidido a propósito, con la tasa de páginas sucias medida para los guests ocupados.
• Modelo de CPU comparado con el host de destino.
• Cada bridge y cada VLAN presentes en el destino, incluidos los uplinks del switch.
• Un storage pool en el destino, espacio libre suficiente, y una imagen creada de antemano donde la disposición lo necesite.
• El comando migrate ejecutado con copia de storage y auto converge, observado con domjobinfo.
• El guest verificado desde fuera, y la copia de origen conservada hasta estar seguro.

Si quiere mover guests sin apagarlos, o necesita una salida de su hipervisor actual, con gusto le ayudamos.

CTA

Hable con un ingeniero

Related

Relacionado: Live migration y salida de hipervisores · Private cloud sobre KVM con OLVM · Múdese a nosotros sin renumerar: extensión de capa 2