Cómo solucionar problemas de Hyper-V en Windows 11

W11 » Requisitos de Windows 11 » Cómo solucionar problemas de Hyper-V en Windows 11

Si utilizas máquinas virtuales en tu PC con Windows 11, tarde o temprano acabarás topándote con algún problema relacionado con Hyper-V: errores al instalar la característica, fallos al arrancar una VM, pantallas azules con HYPERVISOR_ERROR, conflictos con VMware o VirtualBox, o redes virtuales que no tiran ni para atrás. La buena noticia es que la mayoría de estos líos tienen solución si sabes dónde mirar.

En esta guía te voy a explicar, de forma ordenada y con bastante detalle, cómo diagnosticar y arreglar los problemas más habituales de Hyper-V en Windows 11: desde errores de instalación y WMI dañada, hasta migraciones fallidas, conflictos de seguridad con Credential Guard, cuelgues de VMMS o incidencias de red y almacenamiento. La idea es que puedas ir revisando sección a sección y ataques justo el origen del fallo que estás sufriendo.

Principales síntomas y tipos de problemas en Hyper-V para Windows 11

Cuando algo va mal con Hyper-V en Windows 11, suele encajar en unas cuantas categorías típicas de errores. Identificar el síntoma concreto ayuda a acotar de inmediato en qué parte del sistema está el fallo y qué debes revisar primero.

En el terreno de la instalación y configuración pueden aparecer mensajes como:

• “Error en la solicitud para agregar o quitar características en el servidor especificado”.
• “Hyper-V característica desconocida”.
• Hyper-V no aparece como rol o característica tras el reinicio.
• Entradas en los registros CBS del estilo “ERROR_SXS_ASSEMBLY_MISSING”.
• Errores WMI del tipo CSI 000000b5/000000b6 o problemas al abrir msinfo32.

En entornos con varias máquinas o servidores, los dolores de cabeza suelen llegar durante la migración en vivo o en clúster:

• “No se pudo acceder al registro remoto en <host>…”.
• “La máquina virtual no se puede migrar en vivo al host de destino porque el hardware no es compatible…”.
• Errores de credenciales tipo 0x8009030D durante la migración.
• Validación de clúster extremadamente lenta o con errores recurrentes.
• Volúmenes compartidos de clúster que aparecen como RAW o inaccesibles desde ciertos nodos.

En el día a día, otro bloque muy habitual son las incidencias con las propias máquinas virtuales y Hyper-V Manager:

• Una VM no arranca y muestra “No se pudo iniciar la máquina virtual debido a una memoria insuficiente”.
• La VM se queda atrapada en estado “guardado” y no termina de iniciarse tras un reinicio o actualización del host.
• El servicio de administración de máquinas virtuales (VMMS) no arranca.
• Hyper-V Manager no puede conectarse y muestra errores de WinRM.
• El modo de sesión mejorada no está disponible en ciertos escenarios (por ejemplo, modo auditoría).

También hay un grupo amplio de problemas relacionados con redes y almacenamiento:

• Adaptadores de red que se deshabilitan tras instalar Hyper-V, IPs que no se asignan o IPv4 desactivada.
• VMs que no obtienen dirección IP o no pueden comunicarse con la LAN o con Internet.
• Conmutadores virtuales que aparecen como “red no identificada” y no dan salida.
• Configuraciones de VLAN que solo funcionan con la VLAN nativa y fallan con VLAN etiquetadas.

Finalmente, hay síntomas algo más técnicos que suelen pasar desapercibidos pero que delatan conflictos de seguridad, puertos o metadatos internos:

• Cambios inesperados en la dirección MAC de las VMs tras reiniciar el host.
• Conflictos por reservas de puertos TCP altos (50000-50059, por ejemplo) que bloquean aplicaciones al activar Hyper-V.
• Eventos de SPN (ID 14050) registrados por Hyper-V-VMMS en el visor de eventos.
• Repositorio WMI corrupto que impide instalar/usar características de Hyper-V.

Errores al instalar o habilitar Hyper-V en Windows 11

Uno de los quebraderos de cabeza más comunes en Windows 11 es que Hyper-V ni se instala bien, ni aparece en la lista de características, o da error al intentar activarlo tanto desde la interfaz gráfica como desde PowerShell o DISM. Aquí entran en juego varios factores.

La causa más habitual es que haya paquetes de Component Based Servicing (CBS) dañados o con permisos erróneos. En esos casos verás referencias a “ERROR_SXS_ASSEMBLY_MISSING” en los logs de CBS, y la característica de Hyper-V queda en un estado a medio camino, imposible de activar o quitar.

Otra fuente de líos es intentar usar Hyper-V en ediciones de Windows 11 no compatibles, como Windows 11 Home, o en equipos cuyo procesador no soporta las extensiones necesarias (Intel VT-x/VT-c, AMD-V, SLAT). En estos sistemas, aunque actives las casillas que toquen, el rol no llegará a funcionar correctamente.

No hay que olvidar tampoco los casos en los que el repositorio de WMI está dañado. Cuando WMI se rompe, tanto la instalación de características como herramientas como msinfo32 dejan de funcionar o devuelven errores extraños.

Y, por supuesto, siempre hay algún equipo donde en la BIOS/UEFI está desactivada la virtualización de hardware, con lo que Hyper-V nunca podrá lanzar el hipervisor aunque en Windows parezca todo bien marcado.

Reparar permisos y paquetes CBS antes de reinstalar Hyper-V

Si sospechas que el problema viene de CBS, conviene ajustar primero los permisos del registro. La idea es dar control total sobre la clave de paquetes CBS para que el sistema pueda modificar estados internos de las características:

1. Abre el Editor del Registro (regedit) con permisos de administrador y ve a:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages

2. Asegúrate de que la clave “Packages” tiene permisos de control total para los usuarios necesarios (normalmente SYSTEM y administradores). En algunos escenarios de reparación avanzada se concede control total temporal a “Todos” para poder modificar estados y luego se vuelve a endurecer.

El siguiente paso consiste en forzar el reseteo del estado de los paquetes relacionados con Hyper-V mediante PowerShell, ajustando el valor “CurrentState” en las subclaves afectadas. Es un procedimiento delicado, por lo que debe hacerse solo si comprendes lo que tocas o siguiendo una guía técnica detallada, pero en muchos casos desbloquea instalaciones atascadas.

Activar Hyper-V desde DISM y comprobar la edición de Windows

Una vez corregidos permisos y estado de los paquetes, lo más fiable suele ser habilitar Hyper-V usando DISM en lugar de solo marcar la casilla en “Características de Windows”:

• Abre una consola de PowerShell como administrador.
• Ejecuta:
  Dism /online /enable-feature /featurename:Microsoft-Hyper-V-All /All
  Dism /online /enable-feature /featurename:Microsoft-Hyper-V-Management-Clients
  Dism /online /enable-feature /featurename:Microsoft-Hyper-V-Management-PowerShell
• Reinicia cuando lo pida.

Si al ejecutar estos comandos DISM responde con errores de edición no compatible, es que estás en Windows 11 Home u otra variante que no incluye Hyper-V cliente. En ese caso, no hay truco mágico: necesitas Windows 11 Pro, Enterprise o Education, o tirar de otro hipervisor de tipo 2 (VMware Workstation, VirtualBox, etc.).

Reparar WMI cuando rompe Hyper-V y msinfo32

Cuando WMI está mal, no solo fallan consultas de sistema, sino que la propia instalación de Hyper-V puede negarse a continuar. Para intentar reconstruir el repositorio:

• Abre CMD como administrador y ejecuta, uno a uno:
  winmgmt /resetrepository
  winmgmt /verifyrepository
  winmgmt /salvagerepository
• Después, ve a %windir%\system32\wbem y recompila los archivos MOF/MFL:
  for /f %s in (‘dir /b *.mof’) do mofcomp %s
  for /f %s in (‘dir /b *.mfl’) do mofcomp %s

Con el repositorio limpio y los MOF recompilados, suele volver a funcionar msinfo32 y la consulta de características, y ya puedes reintentar la instalación de Hyper-V con DISM o desde la GUI.

Revisar BIOS/UEFI y soporte de virtualización

Aunque suene muy básico, muchos problemas se solucionan con una parada rápida en la BIOS/UEFI para confirmar que VT-x/AMD-V, SLAT y las opciones de virtualización están activadas. En algunas placas esto se llama “SVM”, “Virtualization Technology” o similar.

También conviene verificar que el firmware y la BIOS están actualizados y, si es necesario, activar Secure Boot en Windows 11, sobre todo si vas a exprimir Hyper-V con varias VMs o características de seguridad como Credential Guard o aislamiento del núcleo, que se apoyan en el hipervisor.

También conviene verificar que el firmware y la BIOS están actualizados, sobre todo si vas a exprimir Hyper-V con varias VMs o características de seguridad como Credential Guard o aislamiento del núcleo, que se apoyan en el hipervisor.

Problemas de compatibilidad entre Hyper-V y otros hipervisores

En Windows 11 es muy común que los usuarios instalen Hyper-V “de regalo” al activar funciones como la plataforma de máquina virtual, Windows Hypervisor Platform o seguridad basada en virtualización, y luego se encuentren con que VMware Workstation, VirtualBox o emuladores Android dejan de funcionar o van a pedales.

La razón es sencilla: solo un hipervisor puede usar las extensiones de virtualización de hardware a la vez. Hyper-V es un hipervisor de tipo 1 que se coloca por debajo de Windows; si está activo, los hipervisores de tipo 2 (VMware, VirtualBox, etc.) se ven obligados a usar modos emulados mucho más lentos o directamente no arrancan las VMs.

Cómo saber si el hipervisor de Hyper-V está activo

Antes de romperte la cabeza por qué tu software de virtualización de terceros no arranca, conviene comprobar si el hipervisor de Hyper-V está en ejecución:

• En el buscador de Windows, escribe msinfo32 y abre “Información del sistema”.
• En el panel derecho, al final del resumen del sistema, busca la línea de requisitos de Hyper-V.
• Si pone “Se ha detectado un hipervisor. Las funciones necesarias para Hyper-V no se mostrarán”, significa que Hyper-V está levantado en el arranque.

Deshabilitar Hyper-V desde la GUI (Características de Windows)

La forma más cómoda para un usuario medio es desinstalar o deshabilitar Hyper-V y sus plataformas relacionadas desde el Panel de control:

• Abre Panel de control > Programas > Programas y características.
• Pulsa en “Activar o desactivar las características de Windows”.
• Desmarca “Hyper-V” y también “Plataforma de máquina virtual” y “Plataforma de hipervisor de Windows”.
• Aplica cambios y reinicia.

Con esto, el hipervisor deja de cargar y VMware, VirtualBox o emuladores Android que dependen de VT-x/AMD-V vuelven a poder usar el hardware directamente.

Desactivar el hipervisor con bcdedit sin desinstalar Hyper-V

Si quieres mantener Hyper-V instalado pero no que arranque siempre, puedes jugar con bcdedit para desactivar el hipervisor en el arranque:

• Abre CMD como administrador.
• Ejecuta:
  bcdedit /set hypervisorlaunchtype off

Al reiniciar, Windows 11 arrancará sin cargar Hyper-V, por lo que el resto de hipervisores tendrán acceso completo al hardware. Si más adelante quieres volver a usar Hyper-V, ejecuta:

bcdedit /set hypervisorlaunchtype on

También puedes crear dos entradas de arranque: una con Hyper-V y otra sin, para elegir en el menú de inicio qué modo quieres en cada sesión. Es muy útil si alternas entre usar Hyper-V y usar VMware o VirtualBox con frecuencia.

Integridad de memoria, Credential Guard y otros servicios que fuerzan Hyper-V

Aparte de Hyper-V “puro y duro”, Windows 11 tiene funciones como Integridad de memoria, Device Guard o Credential Guard que se apoyan en el hipervisor; revisa la seguridad en Windows 11 Pro para gestionarlas. Aunque desmarques Hyper-V en las características, si estas protecciones siguen activas, el hipervisor puede seguir cargándose.

En entornos gestionados (Intune, directiva de grupo) hay que revisar las políticas de seguridad basadas en virtualización y las claves de registro asociadas. Solo cuando estas funciones se desactivan por completo, el hardware de virtualización queda libre para que lo use un hipervisor de terceros.

Pantallas azules HYPERVISOR_ERROR y fallos graves del sistema

Un síntoma especialmente molesto son las BSOD con el mensaje HYPERVISOR_ERROR en Windows 11. Suelen indicar problemas con la configuración del hipervisor, drivers en mal estado, memoria defectuosa o corrupción del sistema.

En muchos casos, el origen está en una configuración conflictiva de Hyper-V (cambios de hardware, VMs con ajustes raros, interacciones con otros drivers) o en módulos de RAM/controladores que no se llevan bien con el hipervisor.

Revisar Hyper-V, drivers y actualizaciones

Un primer paso razonable es deshabilitar temporalmente Hyper-V y ver si el sistema deja de mostrar pantallas azules. Puedes hacerlo desde “Características de Windows” como se ha explicado o usando:

Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All

Además, es crucial tener los controladores de chipset, gráfica, almacenamiento y red actualizados. Los drivers antiguos o defectuosos son un clásico a la hora de generar BSOD cuando el hipervisor está gestionando memoria y E/S.

Por último, instala todas las actualizaciones pendientes de Windows 11, ya que muchas corrigen precisamente incidentes con la virtualización, VBS y la interacción con hardware concreto.

Reparar archivos de sistema con DISM y SFC

Si el sistema lleva tiempo arrastrando errores, conviene pasar una reparación de imagen y archivos de sistema:

• Abre CMD como administrador.
• Ejecuta, en este orden:
  DISM /Online /Cleanup-Image /ScanHealth
  DISM /Online /Cleanup-Image /CheckHealth
  DISM /Online /Cleanup-Image /RestoreHealth
  SFC /Scannow

Estos comandos analizan la imagen de Windows, reparan componentes dañados y reemplazan archivos corruptos del sistema. Si el error HYPERVISOR_ERROR venía de corrupción interna, muchas veces desaparece tras este proceso.

Arranque limpio para descartar software de terceros

Cuando sospechas de conflictos con programas en segundo plano (antivirus, herramientas de monitorización, drivers adicionales), un inicio limpio es una buena prueba:

• Pulsa Win+R, escribe msconfig y abre Configuración del sistema.
• En la pestaña General, selecciona “Inicio selectivo” y desmarca “Cargar elementos de inicio”.
• En Servicios, marca “Ocultar todos los servicios de Microsoft” y luego pulsa “Deshabilitar todos”.
• Aplica los cambios y reinicia.

Si así el sistema se estabiliza, ya sabes que algún servicio o controlador de terceros está chocando con Hyper-V. A partir de ahí puedes ir reactivando elementos por bloques hasta localizar al culpable.

Problemas de red y DNS en máquinas virtuales Hyper-V

Otra fuente inagotable de dudas con Hyper-V en Windows 11 son las redes virtuales que no funcionan como deberían. Desde VMs que no obtienen IP hasta escenarios en los que solo hay conectividad por IP pero no resolución DNS, como ocurre con algunas instalaciones de Linux.

En Windows 11, el conmutador predeterminado de Hyper-V crea una red NAT gestionada por el propio host. Para muchos casos de uso de escritorio es suficiente, pero cuando se empieza a hacer puente de adaptadores, VLANs o switches externos, los problemas aparecen si no se entiende bien cómo se reparten las direcciones y el DNS.

Por ejemplo, en un escenario con un invitado Debian que obtiene IP pero no resuelve nombres, suele ser porque la VM no está recibiendo correctamente los servidores DNS del host o de la red, o porque systemd-resolved/no resolvectl están configurados de forma diferente a lo esperado.

Comprobar adaptadores y bindings IPv4 en el host

Tras instalar Hyper-V, algunos usuarios ven que su NIC física aparece deshabilitada o sin IPv4. Es importante verificar en el Administrador de dispositivos y en “Cambiar configuración del adaptador” que el componente TCP/IPv4 está habilitado y los adaptadores están activos.

Desde PowerShell puedes forzar la habilitación:

• Enable-NetAdapter -Name «NombreAdaptador»
• Enable-NetAdapterBinding -Name «NombreAdaptador» -ComponentID ms_tcpip

Con eso devuelves al adaptador físico su capacidad de gestionar tráfico IPv4, algo básico para que las VMs que usan un switch externo salgan bien a la red.

Ajustar conmutadores virtuales y VLAN

Si utilizas VLANs en tu red física, debes alinear esa configuración con la de Hyper-V. El etiquetado incorrecto provoca que las VMs solo vean la VLAN nativa (sin etiquetar) y se queden aisladas en cuanto marcas una VLAN diferente.

• Creación de un switch SET por PowerShell:
  New-VMSwitch -Name «SET» -NetAdapterName «NombreAdaptador» -EnableEmbeddedTeaming $true
• Asignación de VLAN a la NIC virtual de una VM:
  Set-VMNetworkAdapterVlan -VMName «NombreVM» -Access -VlanId ID_VLAN

Revisa también que el switch físico al que se conecta la NIC del host está configurado como troncal o acceso, según lo que pretendas, y que permite las VLAN etiquetadas que estás usando en Hyper-V.

DNS en invitados Linux (por ejemplo, Debian en Hyper-V)

En distribuciones como Debian, puede que la VM coja una IP válida pero no consiga resolver nombres porque la configuración de resolv.conf, systemd-resolved o NetworkManager no encaja con el modo de red de Hyper-V. Algunos puntos que merece la pena revisar en el invitado:

• Que el adaptador virtual se detecta como interfaz activa (ip a, ip route, etc.).
• Que el servidor DHCP está entregando también DNS correcto (comprueba /etc/resolv.conf o el equivalente moderno en systemd).
• Si has hecho un puente manual de adaptadores en Windows, asegúrate de que el propio puente tiene DNS configurado correctamente (por ejemplo, 8.8.8.8 y 8.8.4.4) y el DHCP de la red lo respeta.

En algunos casos, deshacer el puente manual y crear un conmutador externo “limpio” en Hyper-V Manager, conectado directamente a la NIC física, simplifica muchísimo la configuración y evita problemas raros con DNS.

Errores de migración en vivo y problemas de clúster

En entornos más avanzados, Windows 11 se usa a veces como parte de un laboratorio de clústeres Hyper-V o para pruebas de migración en vivo con hosts adicionales. Aquí surgen fallos específicos relacionados con seguridad, criptografía y compatibilidad de CPU.

Uno de los mensajes típicos al intentar mover una VM entre nodos es que “no se puede acceder al registro remoto” del host de destino o que las credenciales no son válidas (0x8009030D). Esto suele indicar problemas con el servicio de Registro remoto, WinRM, TLS/SSL o SPN/Kerberos.

Restaurar claves de criptografía y TLS

En algunos servidores, ciertas claves del registro usadas para la configuración de SSL/TLS y autenticación pueden faltar o estar dañadas. Un ejemplo clásico es:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002

Cuando esta clave no existe o está corrupta, las conexiones seguras necesarias para la migración pueden fallar. La solución habitual pasa por exportar la clave desde un servidor que funcione bien e importarla en el nodo problemático, para luego reiniciar.

Configurar Kerberos y delegación para migración en vivo

Para que la migración en vivo funcione de forma fluida en un dominio, la autenticación debe hacerse con Kerberos y delegación adecuada en Active Directory:

• En Hyper-V Manager, en la configuración de migraciones en vivo, selecciona “Usar Kerberos” en características avanzadas.
• En AD, configura la delegación restringida para las cuentas de equipo de los hosts, añadiendo servicios como CIFS y “Microsoft Virtual System Migration Service”.

Si la delegación no está configurada correctamente, verás errores constantes de credenciales no reconocidas o autenticación fallida cuando intentes mover una VM entre nodos.

Compatibilidad de CPU y estado de la VM

Aun con la red y la seguridad bien configuradas, la migración puede fallar si las CPUs de los hosts no son compatibles entre sí. El estado de la VM incluye información específica del procesador; si el host de destino no soporta ciertas instrucciones, la operación se aborta.

En esos casos necesitas habilitar la opción de compatibilidad de procesador en la configuración de la VM (modo de compatibilidad para migraciones) o hacer una migración rápida/exportación/importación para “alinear” el estado con el nuevo host, en vez de usar migración en vivo pura.

Permisos, seguridad y servicios que afectan a Hyper-V

Más allá del hipervisor en sí, Hyper-V depende de una serie de permisos de archivos, cuentas de servicio y registros de SPN para funcionar correctamente. Cualquier cambio agresivo en estas áreas puede dejar VMs inaccesibles o servicios sin arrancar.

Una causa típica de errores al abrir o mover máquinas virtuales es que la carpeta donde residen los archivos de la VM o los VHDX no tenga permisos correctos para “Administradores”, “Hyper-V Administradores” y “NT VIRTUAL MACHINE\Virtual Machines”. Si estas entradas no existen o están incompletas, Hyper-V no puede acceder a los discos ni a la configuración.

También es relativamente frecuente que, en entornos con SQL Server o System Center Virtual Machine Manager (SCVMM), alguien borre cuentas de servicio asociadas a estos componentes, impidiendo que se inicien servicios esenciales para la gestión de VMs y clústeres.

En el plano de la autenticación Kerberos, los SPN mal configurados o ausentes generan eventos como el ID 14050 de Microsoft-Windows-Hyper-V-VMMS, indicando que la autenticación de servicios no está funcionando como debería.

Errores conocidos y defectos de producto que afectan a Hyper-V

Aunque Hyper-V es una tecnología madura, siguen existiendo bugs específicos y problemas conocidos que se arrastran en determinadas versiones de Windows 11 o Windows Server y que pueden dar lugar a fallos muy concretos.

Uno de ellos es el error del generador de World Wide Port Name (WWPN), donde ciertos valores de registro fuera de rango provocan que el servicio VMMS falle al gestionar identificadores de puerto para funcionalidades de Fibre Channel. La solución pasa por ajustar el valor “NextWWPN” en el registro al rango adecuado y reiniciar Hyper-V/VMMS.

También se han registrado interbloqueos entre MsMpEng.exe (Microsoft Defender) y NTFS y ReFS cuando hay metadatos transaccionales de por medio, provocando bloqueos y lentitud que impactan de rebote en las VMs. En esos escenarios, las actualizaciones de Defender y de Windows han ido corrigiendo comportamientos, por lo que mantener el sistema al día es clave.

Por último, ciertos defectos en la activación KMS y en los procesos de creación de clústeres pueden generar errores difíciles de diagnosticar sin soporte directo de Microsoft. Cuando se han agotado las opciones habituales de reparación y los logs apuntan a errores internos del producto, lo más sensato es recopilar registros (CBS, dism.log, logs de Hyper-V-VMMS) y escalar el caso al soporte oficial.

A la hora de la verdad, Hyper-V en Windows 11 es una herramienta potentísima, pero también muy sensible a la salud del sistema operativo, la configuración de seguridad y la compatibilidad de hardware. Entender dónde encaja cada síntoma (instalación, red, migración, permisos, hipervisor activo, etc.) y aplicar las correcciones adecuadas —desde reparar WMI y CBS hasta desactivar el hipervisor con bcdedit o ajustar DNS y VLAN— marca la diferencia entre un entorno de virtualización inestable y uno en el que tus máquinas virtuales funcionan con la fluidez que necesitas en tu día a día.