La migración en vivo —Live Migration— permite mover una VM encendida desde un nodo origen hacia un nodo destino, manteniendo el servicio disponible durante el proceso. Es una herramienta para mantenimiento, balanceo y continuidad, no un botón mágico: exige compatibilidad, capacidad, red y almacenamiento correctamente preparados.
1. Qué ocurre durante una migración en vivo
Proxmox transfiere el estado de ejecución de la VM al nodo destino mientras la máquina continúa trabajando. La memoria y los cambios se copian progresivamente; al final se realiza una breve sincronización para completar el cambio de ejecución.
El disco puede permanecer accesible desde ambos nodos cuando se utiliza almacenamiento compartido. La guía oficial de Proxmox identifica este como uno de los beneficios principales del almacenamiento compartido: permitir migrar VMs activas sin trasladar manualmente sus imágenes de disco.
2. Requisitos antes de migrar
| Requisito | Qué revisar | Riesgo si falta |
|---|---|---|
| Clúster sano | Nodos en línea y quorum activo | La operación puede bloquearse o quedar insegura. |
| CPU compatible | Modelo y capacidades admitidas en destino | La VM puede no iniciar o perder funciones. |
| RAM disponible | Margen suficiente en el destino | La migración no encuentra capacidad. |
| Red | Canal estable y, si es posible, dedicado | La copia de memoria se ralentiza o falla. |
| Storage | Discos accesibles desde el destino | La VM llega sin sus datos o no puede arrancar. |
| Invitado | Guest Agent y drivers revisados | Menor visibilidad y peor control operativo. |
3. Compatibilidad de CPU, memoria y almacenamiento
La VM debe poder ejecutarse con el conjunto de instrucciones disponible en el destino. Por eso un clúster con procesadores muy diferentes necesita un modelo de CPU común o una política de compatibilidad definida.
También se comprueba la RAM. El destino no debe estar al límite antes de iniciar la migración: necesita recibir la memoria de la VM y conservar margen para sus propias cargas.
En cuanto al almacenamiento, la opción más directa es que ambos nodos vean el mismo recurso compartido, como NFS, iSCSI o Ceph. Con almacenamiento local se requieren mecanismos adicionales —por ejemplo, mover discos o usar replicación— y el procedimiento deja de ser una simple migración con discos compartidos.
4. Preparar la red de migración
La migración mueve memoria y estado entre nodos. Si ese tráfico comparte una red saturada con usuarios, backups o almacenamiento, una operación que debía ser rápida puede competir con servicios críticos.
- Identificar la interfaz o VLAN destinada a migración.
- Confirmar conectividad entre origen y destino.
- Comprobar velocidad, latencia y ausencia de pérdidas.
- Verificar que las reglas de firewall permiten el tráfico necesario.
- Registrar qué red se utilizará y en qué horario.
UsuariosBackupsMigración
5. Guest Agent: visibilidad dentro de la VM
El QEMU Guest Agent permite que Proxmox intercambie información y acciones con el sistema invitado cuando está instalado y habilitado. No es el motor de la migración, pero mejora la coordinación y la observabilidad de la VM.
Antes de migrar una VM, comprueba que el agente y los drivers estén instalados según el sistema operativo. No asumas que una VM recién creada lo tiene listo.
6. Los 12 pasos de la infografía
- Verificar el clúster: confirma nodos en línea, quorum y estado sano.
- Comprobar recursos: revisa CPU y RAM libres en el destino.
- Preparar la red: valida conectividad y canal de migración.
- Comprobar storage: confirma que el destino ve los discos necesarios.
- Configurar la red de migración: selecciona la interfaz o red definida.
- Habilitar Guest Agent: instala y activa el agente dentro del invitado.
- Comprobar compatibilidad: revisa versión, CPU y dispositivos.
- Seleccionar la VM: identifica correctamente la carga y su criticidad.
- Ejecutar la migración: inicia la acción y confirma el nodo destino.
- Monitorear: observa progreso, tiempo y mensajes de tarea.
- Verificar destino: comprueba que la VM aparece activa en el nuevo nodo.
- Realizar pruebas finales: valida servicios, red, rendimiento y usuarios.
7. Ejemplo empresarial
Una empresa debe actualizar el firmware de su nodo pve-node1. La aplicación de facturación corre en la VM 120 y los usuarios no pueden tener una interrupción prolongada.
El equipo verifica quorum, RAM disponible en pve-node2, CPU compatible, storage compartido y red de migración. Ejecuta Live Migration, observa el progreso y prueba desde un equipo usuario que la aplicación siga respondiendo. Solo después coloca el nodo origen en mantenimiento.
El beneficio es una ventana de mantenimiento más flexible; la responsabilidad sigue siendo del equipo que comprueba el servicio.
8. Escenario práctico
Debes migrar una VM Linux que presta un servicio web. Diseña un checklist con:
- Estado requerido del clúster.
- Recursos mínimos del destino.
- Storage y red que deben estar disponibles.
- Pruebas antes, durante y después de migrar.
- Criterio para cancelar o devolver la VM al nodo origen.
9. Qué puede hacer fallar una migración
- El nodo destino no tiene memoria suficiente.
- La CPU no es compatible con la configuración de la VM.
- El storage de los discos no está disponible en el destino.
- La red de migración tiene latencia o pérdida.
- La VM utiliza dispositivos físicos o configuraciones no migrables.
- El clúster ha perdido quorum o presenta errores.
Ante un fallo, no repitas la operación sin leer la tarea y verificar el estado real de la VM. Primero determina si la VM sigue activa en origen, si quedó detenida o si la tarea solo se interrumpió antes de cambiar de nodo.
10. Buenas prácticas y errores frecuentes
Buenas prácticas
- Usar RAM suficiente y evitar overcommit excesivo.
- Separar la red de migración cuando sea posible.
- Mantener versiones y CPU compatibles.
- Probar migraciones periódicamente.
- Registrar tiempos y resultados.
Errores frecuentes
- Migrar sin comprobar storage compartido.
- Confundir migración con backup.
- Ignorar el consumo del destino.
- Realizar la primera prueba en horario crítico.
- Dar por buena la migración sin probar la aplicación.
Preguntas frecuentes
¿La VM se apaga durante una migración en vivo?
El objetivo es mantenerla ejecutándose, aunque puede existir una pausa muy breve al transferir el estado final. La experiencia depende de la carga, la red y el almacenamiento.
¿Puedo migrar entre CPUs diferentes?
Solo si la configuración de CPU de la VM es compatible con ambos nodos. En clústeres heterogéneos hay que definir un modelo común y probarlo.
¿Necesito almacenamiento compartido?
No en todos los diseños, pero es la opción más directa para que ambos nodos accedan a los discos durante una migración. Con almacenamiento local se requieren mecanismos adicionales.
¿Qué debo validar después?
Estado de la VM, red, servicios, rendimiento, logs, Guest Agent y respuesta desde el punto de vista del usuario.
Conclusión
Live Migration es una herramienta práctica para mantenimiento y balanceo, pero funciona bien cuando el clúster, la CPU, la memoria, la red, el storage y la VM están preparados. La migración termina con una prueba del servicio, no con el cambio de nodo visible en la interfaz.
Continúa con la Temporada 2
En EP017 veremos backup y restauración de máquinas virtuales.
Leer EP017 →