Migración en vivo
La migración en vivo mueve una VM en ejecución a otro Host mientras mantiene su sistema operativo funcionando. Sirve para preparar mantenimiento o cambiar la ubicación. Es una operación de infraestructura que necesita un rol de flota adecuado, no solo colaboración en un Proyecto. Antes de iniciarla, compruebe capacidad del destino, compatibilidad de CPU, conectividad y acceso a los discos.
Preparar el destino
El Host de destino debe estar disponible y ser adecuado para la VM. El almacenamiento compartido debe estar conectado donde haga falta; unir dos Hosts a un Pool no convierte discos locales en compartidos. Revise espacio libre y PBD. Confirme que el destino ofrece las redes de la VM y que el tráfico de migración puede atravesar la ruta de gestión.
Los dispositivos PCI, USB u otros vinculados a un Host pueden impedir la migración. La falta de controladores PV, CPU incompatibles, memoria insuficiente y SR inaccesibles se notifican como condiciones previas incumplidas. El Edge está fijado a su Host y tiene bloqueadas las operaciones de migración. No use la migración para trasladar la propiedad de una NIC pública física.
Migrar la VM
Con un rol de flota autorizado, abra Migrar en la VM. Revise Host de destino y Migración en vivo (la VM sigue en ejecución). Compruebe origen y destino antes de enviar.
La ruta CLI dentro del mismo Pool es:
hv vm show VM --pool POOL
hv vm migrate VM --pool POOL --host DESTINATION_HOST --live
hv task list --pool POOLUse la configuración de producción o el modo remoto autenticado de CLI y API. Siga la tarea de migración e inspeccione de nuevo la VM al terminar.
Para otro Pool se añade --dest-pool DESTINATION_POOL. En ese caso, la CLI admite varias correspondencias --network-map VIF=NETWORK. Los discos utilizan el SR predeterminado del Pool de destino en esta ruta CLI; revíselo antes de comenzar. Las correspondencias de red se rechazan en migraciones dentro del mismo Pool. Importar una definición XenServer no implica compatibilidad de ABI ni de migración en vivo entre productos.
Mover web-01 antes del mantenimiento
Suponga que web-01 se ejecuta en hv-01, dentro de un Pool que también contiene hv-02. El objetivo es liberar hv-01 para mantenimiento mientras la aplicación sigue funcionando. Antes de solicitar el traslado, anote el Host residente, los discos conectados y las redes. Confirme que la cuenta dispone del permiso de flota necesario; el acceso al Proyecto no autoriza por sí solo cambios de ubicación en la infraestructura.
Revise hv-02 y compruebe su memoria disponible para esta VM, en lugar de comparar únicamente la memoria instalada de ambos Hosts. Compruebe que puede acceder a todos los SR necesarios. Si web-01 usa una VPC, verifique que la red superpuesta alcanza el destino. Si usa una red externa, revise la conexión física correspondiente. Un nombre igual no demuestra que otra red tenga la misma conectividad.
Abra Migrar en web-01, elija hv-02 y revise la opción de migración en vivo. Envíe una sola solicitud y conserve el identificador de tarea. Mientras se ejecuta, no solicite otra migración de la misma VM. Una reconexión del navegador o un progreso que tarda en actualizarse justifican consultar la tarea, no dar por perdida la solicitud.
Al terminar, abra la página de la VM y confirme que su Host residente es hv-02. Compruebe la aplicación desde su acceso habitual y también mediante la consola de la VM. Una consola funcional confirma acceso al invitado, pero no prueba la red de la aplicación ni sus dependencias externas. Solo después de estas comprobaciones dé por evacuada web-01 de hv-01.
Si falla el traslado, revise la condición indicada y la ubicación real de la VM. Por ejemplo, un SR inaccesible desde hv-02 exige reparar su conexión o elegir otro destino. Cambiar el nombre de la VM o repetir la solicitud no resuelve ese problema. Mantenga disponible hv-01 hasta confirmar dónde se ejecuta la VM.
Planificar un traslado entre pools
Un traslado entre Pools exige revisar la propiedad y la infraestructura de destino, además del invitado en ejecución. Identifique explícitamente el Pool de destino y revise su SR predeterminado antes de usar la CLI. Compruebe que sirve para todos los discos y tiene espacio suficiente. No deduzca el destino del último Pool seleccionado en la CLI.
Prepare una correspondencia para cada NIC que necesite otra red de destino. Por ejemplo, distinga la interfaz de aplicación de web-01 de una interfaz de gestión separada; intercambiarlas puede dejar inaccesible un invitado que sigue funcionando. Revise identificadores y conectividad prevista para cada correspondencia antes de enviar. La referencia de la CLI describe las opciones entre Pools y las reglas de selección.
Prepare el acceso a la consola del invitado después del traslado y conserve los datos originales de red y discos hasta verificar el destino. Si no puede confirmar recursos compatibles, posponga el traslado y prepare otro procedimiento de recuperación o mantenimiento. Restaurar una copia es una operación distinta y no debe presentarse a los responsables de la aplicación como equivalente a una migración en vivo.
Verificar la finalización
Compruebe que cambió el Host residente, que el estado de ejecución es correcto y que se alcanzan el sistema operativo y las aplicaciones. Revise discos y NIC en el destino. La migración en vivo no garantiza latencia nula ni sesiones ininterrumpidas bajo cualquier configuración; valide el comportamiento de la aplicación antes de usarla para mantenimiento.
Aceptar la solicitud no significa terminarla. Conserve el identificador de tarea y revise el resultado final. Si se pierde la conexión con hv, reconecte y lea la tarea y ubicación existentes antes de solicitar otro traslado.
Problemas habituales
Ante VM_REQUIRES_SR o SR_NOT_ATTACHED, revise las conexiones del SR de destino. Ante VM_REQUIRES_NETWORK, revise la red y la correspondencia entre Pools. Ante HOST_NOT_ENOUGH_FREE_MEMORY, libere capacidad o elegir otro Host. Los errores de dispositivos asignados requieren decidir si se retiran o se programa una parada.
Si se detiene la evacuación de mantenimiento, el Host puede estar deshabilitado y conservar VM residentes. Resuelva el fallo concreto antes de reiniciar. Un Pool con un único Host necesita apagar sus VM para actualizar la plataforma: no tiene otro Host que reciba la migración.