Live migration en Hyper-V: guía completa para mover VMs sin parar servicios

La migración en vivo en Hyper-V se ha convertido en una pieza clave para cualquier infraestructura virtual moderna que necesite mantener sus servicios siempre disponibles, incluso mientras se realizan tareas de mantenimiento o se reorganizan recursos entre servidores. Gracias a esta funcionalidad, es posible mover máquinas virtuales en ejecución entre hosts físicos de forma transparente para el usuario, con un tiempo de interrupción tan pequeño que, en la práctica, suele ser imperceptible.

Detrás de esta “magia” hay muchos requisitos, tecnologías complementarias y también problemas típicos que pueden aparecer si algo no está bien configurado: desde incompatibilidades de CPU hasta fallos de autenticación Kerberos, errores de red, almacenamiento compartido mal montado o versiones de configuración de VM que no cuadran entre hosts. Entender bien cómo funciona Hyper-V Live Migration, qué modos ofrece, qué necesita para operar con garantías y cómo se soluciona cuando falla es fundamental si administras entornos Windows Server en producción.

Qué es exactamente la migración en vivo en Hyper-V

La migración en vivo (Live Migration) de Hyper-V es una característica de Windows Server (introducida en Windows Server 2008 R2 y mejorada en versiones posteriores) que permite trasladar una máquina virtual en ejecución desde un host Hyper-V a otro sin tener que apagarla. El objetivo principal es poder hacer equilibrio de carga, mantenimiento planificado y operaciones de optimización de recursos minimizando el impacto en los servicios que consumen los usuarios.

A diferencia de una migración “en frío”, en la que la VM se apaga, se mueve y luego se enciende en el nuevo host, Live Migration copia el estado de memoria y CPU mientras la VM sigue funcionando. Solo se produce una pausa muy breve al final del proceso, cuando se termina de sincronizar la memoria restante y se conmuta la ejecución al host de destino.

Esta funcionalidad está estrechamente ligada a la alta disponibilidad: cuando se combina con clústeres de conmutación por error (WSFC) y, en muchos casos, con System Center Virtual Machine Manager (SCVMM), permite construir plataformas tolerantes a fallos y con capacidad para mover las cargas críticas de un nodo a otro en cuestión de segundos.

En versiones modernas como Windows Server 2016, 2019 o 2022, Hyper-V Live Migration ha ido eliminando restricciones, como la necesidad estricta de clúster para todos los escenarios. Hoy es posible realizar migraciones en vivo sin clúster de conmutación por error, únicamente entre hosts independientes correctamente configurados, lo que abre la puerta a entornos más flexibles.

Arquitectura básica y requisitos de Hyper-V Live Migration

Para que la migración en vivo funcione con garantías, es imprescindible que los hosts de origen y destino cumplan una serie de condiciones de hardware, software, red y almacenamiento. Aunque algunos requisitos se han relajado con el tiempo, seguir ciertas buenas prácticas marca la diferencia entre una migración fluida y un festival de errores en el visor de eventos.

A nivel de sistema operativo, ambos servidores deben ejecutar versiones compatibles de Windows Server con Hyper-V activado y debidamente actualizado (service packs, actualizaciones acumulativas y firmware/BIOS al día). Lo ideal en producción es que todos los nodos compartan la misma versión de sistema y un nivel de parcheo homogéneo.

En cuanto al procesador, lo normal es que los hosts tengan CPUs de la misma familia y generación (por ejemplo, Intel-Intel de una misma línea) para evitar conflictos de instrucciones avanzadas. Hyper-V permite habilitar en la configuración de la VM la opción de “migrar a un equipo físico con otra versión de procesador” para suavizar diferencias entre generaciones, pero no soluciona cambios de fabricante: no puedes mover una VM en ejecución de un host con CPU AMD a otro con CPU Intel, salvo que apagues la VM y hagas una migración sin estar encendida.

La parte de red también es fundamental: las redes utilizadas para administración, migración en vivo, tráfico de las propias VMs y, si aplica, almacenamiento, deben estar bien configuradas, con IPs fijas, latencia baja y un ancho de banda suficiente. En producción es habitual reservar redes específicas para Live Migration para no saturar el tráfico de usuario.

En escenarios clásicos con clúster de conmutación por error, la recomendación es contar con almacenamiento compartido (SAN, NAS, SMB 3.0) accesible desde todos los nodos del clúster. El almacenamiento compartido simplifica mucho la migración, porque los discos virtuales no tienen que moverse físicamente de un host a otro, solo cambia el propietario que los gestiona.

Modos de migración en vivo en Hyper-V

Hyper-V ofrece varios modos y tecnologías para realizar la migración en vivo y optimizar el uso del ancho de banda, el tiempo de migración y la integración con el almacenamiento existente. Elegir uno u otro dependerá del diseño de tu infraestructura.

Migración en vivo “estándar” es el modo básico en el que el host de origen copia progresivamente la memoria de la VM al host de destino mientras la máquina sigue en ejecución. Se repiten varias pasadas hasta que las diferencias de memoria entre ambos lados se reducen lo suficiente. En el último paso, la VM se pausa durante un instante, se transfiere el estado de CPU y las últimas páginas de memoria pendientes, y la VM se reanuda ya en el nuevo host.

Migración en vivo con compresión añade una capa de optimización: los datos de la memoria se comprimen antes de enviarse a través de la red, de forma que se reduce el volumen de información transferida. Es especialmente interesante en redes con ancho de banda limitado o cuando hay muchas migraciones simultáneas.

Migración en vivo sobre SMB aprovecha el protocolo SMB (normalmente SMB 3.x) para transportar los datos de la VM y su estado. Es muy útil cuando el almacenamiento subyacente ya está montado vía SMB, por ejemplo con archivos VHDX ubicados en un file server o cabina compatible con SMB. En este caso se combina muy bien con características como SMB Multichannel y SMB Direct para exprimir la red.

En versiones recientes de Windows Server, además, puedes ajustar opciones avanzadas como el número máximo de migraciones simultáneas permitidas en un host, o configurar el límite de ancho de banda dedicado a Live Migration para no estrangular otros servicios críticos que compartan la red.

Preparación de los hosts Hyper-V para usar Live Migration

Antes de lanzarte a mover máquinas virtuales en caliente, conviene dejar bien preparados los servidores Hyper-V. El procedimiento difiere un poco según trabajes con clúster de conmutación por error o con hosts independientes, pero las ideas base son las mismas.

En sistemas anteriores a Windows Server 2016, lo típico es montar un clúster de conmutación por error (WSFC) que agrupe varios hosts Hyper-V. Estos nodos comparten almacenamiento y son gestionados como una unidad lógica que permite mover roles de VM de un nodo a otro con alta disponibilidad.

En Windows Server 2016 y posteriores, Microsoft simplificó bastante el escenario permitiendo migraciones en vivo entre hosts que no forman necesariamente parte de un clúster. Aun así, es imprescindible configurar correctamente la capa de red, la autenticación (CredSSP o Kerberos), las direcciones IP utilizadas para Live Migration y, opcionalmente, el almacenamiento compartido si quieres reducir complejidad.

Desde el Administrador de Hyper-V, en cada host debes entrar en “Configuración de Hyper-V”, ir a la sección de “Migraciones en vivo” y habilitar las migraciones entrantes y salientes. En esa misma sección se configuran las IPs que se utilizarán para Live Migration y la autenticación (CredSSP o Kerberos). CredSSP es más sencillo de poner en marcha, aunque exige iniciar sesión con el mismo usuario en ambos hosts cuando vayas a mover una VM.

Si optas por Kerberos, el despliegue es algo más delicado porque implica configurar delegación restringida en Active Directory, registrar correctamente los SPN (Service Principal Names) para el servicio de migración y, en general, controlar bien cómo se delegan las credenciales entre equipos. A cambio, resulta más cómodo para automatizar y no requiere sesiones interactivas simultáneas.

Pasos básicos para realizar una migración en vivo en Hyper-V

Una vez que los hosts están preparados, el proceso de mover una VM en vivo desde el Administrador de Hyper-V es bastante guiado y no tiene demasiada complicación, siempre que se cumplan los requisitos de compatibilidad y red.

1. Abrir la consola y conectar a los servidores: en el Administrador de Hyper-V, conectas tanto al servidor de origen como al de destino (mediante “Conectar al servidor”). De este modo puedes ver todas las VMs desde un único punto.

2. Lanzar el asistente de movimiento: en el host de origen, haces clic derecho sobre la VM que quieres mover y seleccionas “Mover”. Se abre el asistente para migración, que te irá preguntando por el tipo de movimiento que quieres realizar.

3. Elegir el tipo de desplazamiento: en el caso de una migración en vivo típica, eliges “Mover la máquina virtual” (no solo el almacenamiento ni otras variantes). A continuación, especificas el nombre del host de destino al que se va a enviar la VM.

4. Decidir qué pasa con los archivos: el asistente permite varias opciones, entre ellas mover todos los datos de la VM a una única ubicación en el destino, o distribuir archivos de forma más personalizada. Si toda la VM va a vivir en un único volumen o ruta en el nuevo host, suele ser más cómodo escoger la opción de “mover todos los datos a una única ubicación”.

5. Confirmar y ejecutar la migración: tras revisar la ruta de destino y las opciones elegidas, haces clic en “Finalizar” y da comienzo el movimiento. El tiempo que tarda depende sobre todo del tamaño de la VM (memoria y discos implicados), de la velocidad de la red y de la carga que tenga en ese momento la máquina.

Autenticación, delegación y SPN en Live Migration

Uno de los puntos que más dolores de cabeza suele dar en entornos Hyper-V es todo lo relacionado con la autenticación entre hosts para permitir la migración en vivo. Los errores típicos incluyen códigos como 0x80070005 (acceso denegado) o 0x8009030E/0x8009030D, relacionados con Kerberos, delegación o SPN mal configurados.

Si utilizas Kerberos como protocolo de autenticación para Live Migration, debes habilitarlo explícitamente en la configuración avanzada de las migraciones en vivo del host. Después, en Active Directory, hay que ir a las propiedades del objeto de equipo del servidor y, en la pestaña “Delegación”, marcar la opción de confiar en ese equipo para la delegación a servicios concretos únicamente.

En esa delegación restringida, es usual añadir al menos los servicios “cifs” (para acceso a recursos compartidos) y “Microsoft Virtual System Migration Service” para permitir la transferencia del estado de las VMs entre hosts. Además, has de asegurarte de que existen los SPN correctos para este servicio, registrándolos con comandos como setspn si es necesario.

Cuando los SPN están incompletos o las delegaciones no son correctas, la migración suele fallar con errores de autenticación, y en algunos casos es útil purgar los tickets Kerberos antiguos con herramientas como KLIST para forzar la obtención de nuevos tickets basados en la configuración actualizada.

Si prefieres CredSSP, el despliegue es más directo, pero con la contrapartida de que tendrás que abrir la misma sesión de usuario con derechos suficientes en ambos hosts cada vez que quieras lanzar una migración. En entornos pequeños o de laboratorio esto es bastante cómodo; en producción, Kerberos y la delegación restringida suelen ser la opción preferida para automatizar.

Red, conmutadores virtuales y almacenamiento en Live Migration

Además de la autenticación, la conectividad de red es otra de las grandes fuentes de problemas en Hyper-V Live Migration. Si los hosts no se resuelven correctamente por nombre o IP, o si el tráfico de WinRM, SMB o clustering está bloqueado por un firewall, la migración fallará antes incluso de empezar a transferir memoria.

Los errores típicos incluyen mensajes como “El cliente no puede conectarse al destino especificado en la solicitud” o fallos de protocolo WinRM, a menudo acompañados de eventos con ID 20406 o 280. Para diagnosticar estos casos, conviene probar primero conectividad básica (ping, resolución DNS), revisar reglas de firewall y verificar que WinRM esté correctamente habilitado con comandos como winrm quickconfig.

Otro aspecto clave es la coincidencia de los conmutadores virtuales entre hosts. Si las VMs usan un switch virtual que no existe con el mismo nombre en el destino, la migración puede solicitarte que reasignes el adaptador de red en el host de destino. Esto no es necesariamente un problema, pero conviene planificarlo para que el tráfico de las VMs no cambie de VLAN o de red sin querer.

En lo relativo al almacenamiento, lo normal es que las VMs utilicen discos VHDX en almacenamiento compartido accesible por los nodos del clúster, o bien que se muevan junto con la VM si no hay almacenamiento compartido. Los discos virtuales compartidos (como los VHDX compartidos usados por ciertas configuraciones en clúster) tienen limitaciones: no se pueden mover con los métodos de migración estándar y, en muchos casos, tendrás que moverlos y volver a adjuntarlos manualmente en el destino.

También hay que vigilar los puntos de control e instantáneas: cadenas de checkpoints muy largas o dañadas, o archivos de estado guardado (.bin y .vsv) corruptos, pueden impedir restaurar o mover una VM. En estos casos, suele ser necesario eliminar el estado guardado desde el Administrador de Hyper-V o borrar manualmente determinados archivos, así como combinar o limpiar puntos de control problemáticos.

Problemas habituales en Live Migration y cómo resolverlos

Aunque la teoría de Live Migration es bastante limpia, en la práctica no es raro toparse con errores al mover VMs entre nodos, especialmente en entornos donde ha habido varias actualizaciones de sistema, cambios de hardware o configuraciones de red poco homogéneas.

Uno de los casos más frecuentes es la incompatibilidad de CPU o de firmware entre hosts. La migración puede funcionar en un sentido (por ejemplo, de un servidor antiguo a uno más nuevo) pero no a la inversa, y en el visor de eventos aparecen IDs como 10698 o 21502 con mensajes sobre problemas de compatibilidad de configuración.

La solución típica pasa por actualizar la versión de configuración de la VM en el nuevo host (desde Hyper-V Manager → Acción → Actualizar versión de configuración de máquina virtual) y comprobar con PowerShell (Get-VM | select Name, Version) que todas las VMs tengan versiones coherentes con el nivel de Hyper-V del nuevo servidor. Tras la actualización, esas VMs ya no podrán volver a hosts con versiones de Hyper-V anteriores.

Los problemas de red o WinRM se solucionan normalmente garantizando que ambos hosts pueden comunicarse por nombre y por IP, revisando WinRM (winrm quickconfig), ajustando la lista de TrustedHosts si corresponde (Set-Item WSMan:\localhost\Client\TrustedHosts) y asegurando que los puertos necesarios para SMB, Live Migration y clustering (como UDP 3343) no están bloqueados.

En escenarios con vTPM o máquinas virtuales blindadas, los errores de migración suelen mencionar la imposibilidad de “desencapsular el protector de claves de la máquina virtual”. En estos casos, es un tema de certificados y de confianza entre hosts: hay que exportar los certificados de protector de claves desde el host de origen e importarlos al host de destino, ya sea usando el complemento de certificados de Windows (certmgr.msc) o mediante cmdlets de PowerShell como Export-PfxCertificate e Import-PfxCertificate.

Lista de comprobación para diagnosticar errores de Live Migration

Cuando una migración en vivo falla, lo más práctico es seguir una lista de comprobaciones ordenada que te ayude a descartar posibles causas sin ir “a ciegas”. Muchos problemas se resuelven con una revisión sistemática de estado, configuración y permisos.

1. Estado de hosts y máquinas virtuales: verifica que los servicios de integración de las VMs estén actualizados, que los hosts estén totalmente parcheados y en versiones compatibles, y que la VM no se encuentre en estados especiales como “Copia de seguridad” o “Detención” que impidan su movimiento.

2. Configuración de clúster y compatibilidad de nodos: comprueba que todos los nodos del clúster estén en línea y sanos en el Administrador de clústeres de conmutación por error, que las CPUs, BIOS/firmware y versiones de configuración de VM sean compatibles, y que todos los nodos tengan una configuración lo más homogénea posible.

3. Red y almacenamiento: revisa que las redes de almacenamiento, administración y migración estén correctamente configuradas y accesibles, que el almacenamiento de la VM sea visible desde el host de destino, y que las reglas de firewall no bloqueen el tráfico de clustering, SMB o WinRM.

4. Autenticación y permisos: confirma que Kerberos o CredSSP estén habilitados y configurados, que los SPN necesarios estén registrados, que la delegación restringida en AD sea la adecuada y que las cuentas de servicio o usuarios tengan el nivel de permisos requerido para lanzar migraciones.

5. Conmutadores virtuales y networking de la VM: asegúrate de que los switches virtuales necesarios existan y estén configurados de forma idéntica entre hosts (nombre, VLANs, tipo), y de que la formación de equipos de red (SET, LBFO) sea consistente para no perder conectividad de las VMs tras la migración.

6. Características específicas de la VM: si trabajas con máquinas blindadas, vTPM, cadenas de puntos de control extensas o discos compartidos, revisa la documentación de compatibilidad y, si procede, consolida checkpoints, quita estados guardados problemáticos y revisa requisitos de certificados.

Recopilación de datos y registros para soporte

Cuando el problema no se resuelve con las comprobaciones habituales, es hora de recopilar datos más detallados para análisis propio o para escalarlos a soporte de Microsoft o al proveedor que corresponda. Hyper-V y Windows Server exponen bastantes registros útiles.

En primer lugar, los registros de eventos específicos de Hyper-V y de clúster aportan mucha información. Puedes usar PowerShell para extraerlos, por ejemplo con Get-WinEvent sobre los registros “Microsoft-Windows-Hyper-V-VMMS/Admin” o “Microsoft-Windows-Hyper-V-Worker-Admin”, y Get-ClusterLog para obtener los logs del clúster con marca de tiempo local.

Además, conviene recoger datos de red y sistema como la salida de Get-NetAdapter, ipconfig /all, msinfo32, rutas de red, configuración de WinRM, listado de SPN (setspn -L) y configuraciones clave de Hyper-V (Get-VM, Get-VMSwitch, Get-VMProcessor, etc.). Todo esto ayuda a ver de un vistazo si hay desajustes entre hosts.

En escenarios más complejos, puede ser necesario habilitar trazas específicas de migración en vivo mediante scripts de soporte de Microsoft (por ejemplo TSS.ps1 con diferentes parámetros), así como revisar cadenas de VHD con utilidades tipo Get-VHDChain para detectar corrupción o errores en rutas de discos.

El objetivo de toda esta recopilación es poder correlacionar eventos de error, tiempos de migración, cambios recientes en parches o firmware y estados de red, de forma que se pueda aislar la causa raíz con rapidez y aplicar el fix definitivo (ya sea una corrección de configuración o una actualización de código).

Live Migration y relación con soluciones de backup y V2V

La migración en vivo en Hyper-V resuelve el movimiento en caliente entre hosts dentro de un entorno Windows Server, pero no cubre todas las necesidades de movilidad de cargas ni de protección de datos que suelen existir en un CPD o en una empresa con varios hipervisores.

Herramientas de backup como BackupChain proporcionan copias de seguridad en vivo de máquinas virtuales Hyper-V, VMware, VirtualBox y otros hipervisores, permitiendo guardar VMs sin detenerlas y almacenarlas tanto en repositorios locales como en la nube. Este tipo de soluciones actúan a nivel de host y ofrecen copias ilimitadas de VMs bajo una misma licencia, además de funciones avanzadas de copia de seguridad de servidores físicos.

BackupChain incluye además características como backup granular y restauraciones granulares, pensadas para acelerar la recuperación de datos cuando solo necesitas ciertos archivos dentro de una VM y no una restauración completa, lo que complementa muy bien las capacidades de Live Migration en el día a día.

Otras soluciones, como Vinchin Backup & Recovery, van un paso más allá permitiendo no sólo respaldar VMs Hyper-V, sino también restaurarlas en otros hipervisores (ESXi, XenServer, Proxmox, etc.) sin necesidad de apagar el servidor, facilitando procesos de migración V2V (virtual a virtual) entre plataformas distintas.

En entornos heterogéneos donde conviven varios hipervisores, este tipo de herramientas sirven como puente para mover cargas entre tecnologías que Hyper-V Live Migration por sí sola no puede abarcar (por ejemplo, migrar una VM de Hyper-V a VMware vSphere), combinando backups, deduplicación, compresión, políticas de retención GFS y recuperación granular para cubrir tanto continuidad de negocio como movilidad de workloads.

Hyper-V Live Migration es solo una pieza dentro de un puzzle mayor que incluye alta disponibilidad, backup, restauración y, en muchos casos, movilidad entre plataformas. Gestionar bien todo ese ecosistema es lo que permite mantener las máquinas virtuales críticas funcionando sin sobresaltos mientras se hacen cambios en el entorno físico.

• Hyper-V Live Migration permite mover VMs en ejecución entre hosts con mínimo impacto, apoyándose en redes rápidas, autenticación Kerberos o CredSSP y, a menudo, almacenamiento compartido.
• Un despliegue estable exige homogeneidad de CPU, firmware y configuración de VM, así como switches virtuales y reglas de firewall coherentes en todos los nodos.
• La resolución de errores de migración pasa por revisar compatibilidad, red, autenticación, discos, checkpoints y certificados, apoyándose en registros y herramientas de diagnóstico.
• Las soluciones de backup y V2V complementan a Live Migration al cubrir copias en vivo, restauraciones granulares y movimientos entre hipervisores distintos.