Las aplicaciones de virtualización no funcionan: ¿Qué hacer?
Cuando se instala una aplicación de virtualización en un equipo Windows en el que están instalados Hyper-V o servicios relacionados, a menudo pueden producirse errores. Los errores que se producen al ejecutar máquinas virtuales en aplicaciones de virtualización que no son Hyper-V causan problemas importantes. Esta entrada de blog explica qué causa estos errores, cómo solucionarlos y cómo ejecutar otras aplicaciones de virtualización en un ordenador con Hyper-V.
Antecedentes y principio de funcionamiento
Después de instalar VMware Workstation, VMware Player u Oracle VirtualBox en una máquina Windows, es posible que se produzcan errores al iniciar una máquina virtual en estas aplicaciones de virtualización. Los errores se producen incluso si las máquinas virtuales Hyper-V no se están ejecutando en ese momento. Puedes instalar VMware Workstation y VirtualBox, y ejecutar VMs de VMware y VMs de VirtualBox en el mismo ordenador, pero no simultáneamente. ¿Cuál es la causa de este problema con Hyper-V? Veámoslo más de cerca.
VMware Workstation, VMware Player y VirtualBox son hipervisores de tipo 2, mientras que Hyper-V es un hipervisor de tipo 1. Un hipervisor de tipo 2 se instala en el sistema operativo que se ejecuta en el hardware. Un hipervisor de tipo 1 se instala sobre el hardware. Todos los hipervisores requieren extensiones de virtualización del procesador, que son conjuntos de instrucciones para la virtualización del hardware: Intel VT-x o AMD-V. Hyper-V toma el control de las extensiones de virtualización cuando arranca Windows. Estas extensiones de virtualización no están disponibles para VMware Workstation y VirtualBox cuando se carga Windows. Sólo un componente de software puede utilizar Intel VT-x o AMD-V a la vez.
Esta incompatibilidad es causada por Hyper-V porque las extensiones de virtualización no están expuestas a hipervisores de tipo 2 instalados en una máquina Windows donde el rol Hyper-V está habilitado.
Errores de la estación de trabajo VMware:
VMware Workstation e Hyper-V no son compatibles. Elimine el rol Hyper-V del sistema antes de ejecutar VMware Workstation.
VMware Workstation y Device/Credential Guard no son compatibles. VMware estación de trabajo se puede ejecutar después de desactivar Device/Credential guard.
Errores de VirtualBox:
BSOD, como BSOD con SYSTEM_SERVICE_EXCEPTION
VT-x no está disponible (VER_VMX_NO_VMX). E_FAIL (0x80004005).
Una VM VirtualBox funciona con demasiada lentitud y utiliza el modo de paravirtualización (emulación).
La situación más interesante es cuando un usuario no instala Hyper-V y aún así se encuentra con uno de los errores mencionados anteriormente al utilizar VMware Workstation o VirtualBox. El error se produce cuando las actualizaciones automáticas de Windows están activadas. Con las actualizaciones (Windows 10 v1607 y las versiones correspondientes de Windows Server a partir de Windows Server 2016), algunas funciones nuevas relacionadas con Hyper-V se instalan y habilitan automáticamente sin el consentimiento del usuario de Windows. Estas funciones son Device Guard y Credential Guard. Windows actualiza vulnerabilidades conocidas pero puede añadir problemas y destruir una configuración que funcione. Por eso a muchos usuarios no les gustan las actualizaciones automáticas.
Device Guard es un grupo de funciones de seguridad de Windows. La idea de implementar esta función es endurecer la ejecución de código malicioso. Device Guard está disponible en Windows 10, Windows Server 2019, y Windows Server 2019. Los requisitos principales son: UEFI funcionando en modo nativo y Secure Boot activado.
Credential Guard es una función para minimizar el impacto de los ataques si el código malicioso ya se está ejecutando mediante el aislamiento de los secretos del sistema y del usuario para hacer más difícil el compromiso.
El modo seguro virtual (VSM) es una función para aprovechar las extensiones de virtualización del procesador que protege los datos en una región aislada de la memoria. HVCI es la integridad del código protegida por el hipervisor. LSA es Local Security Authority (Autoridad Local de Seguridad).
Virtualization Based Security (VBS) es una clase de tecnologías que utiliza extensiones de virtualización, incluyendo VSM, para proporcionar seguridad en Windows. El rol Hyper-V es necesario para que estas funciones funcionen (las herramientas de gestión de Hyper-V no son necesarias).
Primero se carga el hipervisor (Hyper-V) y después el sistema operativo (Windows). Hyper-V proporciona una capa de abstracción entre el hardware y el sistema operativo. Un VSM permite etiquetar procesos críticos específicos y la memoria que utilizan, ya que pertenecen a un sistema operativo independiente controlado por Hyper-V. El principio es similar al aislamiento de dos máquinas virtuales que se ejecutan en un host Hyper-V cuando cada máquina virtual puede utilizar únicamente los recursos de hardware que le han sido asignados.
Nota: Si necesita un hipervisor de tipo 1 de VMware, utilice el entorno VMware ESXi y VMware vSphere. Obtenga más información en estas publicaciones del blog: Hyper-V frente a VMware, VMware Workstation frente a VMware Player y Cómo instalar ESXi en Hyper-V.
Exploremos en detalle cómo resolver el problema de incompatibilidad de Hyper-V y otras aplicaciones de virtualización.
Método 1: Desinstalar Hyper-V en la GUI
Compruebe la información del sistema sobre la configuración de Windows ejecutando el siguiente comando en CMD:
msinfo32.exe
Se abrirá una ventana de información del sistema. En la siguiente captura de pantalla, puede ver que Hyper-V está activado (se ha detectado un hipervisor) y que se está ejecutando la seguridad basada en la virtualización de Device Guard. Ahora puedes eliminar estas funciones.
Debe tener en cuenta que las siguientes funciones relacionadas con Hyper-V no estarán disponibles después de eliminar Hyper-V:
- Hyper-V
- Credential Guard y Device Guard
- Plataforma de máquinas virtuales
- Windows Sandbox
- WSL2.
Elimine la función Hyper-V de la interfaz gráfica de usuario (GUI) mediante el asistente Panel de control, Agregar funciones y características.
En Windows 10, abra el Panel de control, haga clic en Programas y características y, a continuación, en Activar o desactivar las funciones de Windows.
Se abre la ventana de funciones de Windows.
Desmarque la casilla Hyper-V y pulse Aceptar.
Para terminar de eliminar Hyper-V, reinicie el ordenador.
Los pasos para eliminar Hyper-V en Windows 10 y Windows Server 2016 son similares.
En Windows Server 2016, abra Server Manager y haga clic en Manage > Remove Roles and Features. En el Asistente para la eliminación de roles y funciones, vaya al paso Roles de servidor y anule la selección de Hyper-V. Pulse Siguiente en cada paso para continuar. Es necesario reiniciar para terminar de eliminar el rol Hyper-V.
Método 2: Utilizar PowerShell para desactivar la función Hyper-V
Puede realizar una acción similar utilizando la interfaz de línea de comandos en lugar de la GUI.
Inicie sesión en PowerShell como administrador y ejecute el comando para desactivar la función Hyper-V:
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Hypervisor
Reinicie su máquina anfitriona:
shutdown -r -t 0
Método 3: Desactivar Hyper-V mediante BCDedit
La idea detrás de este método es editar los datos de configuración de arranque y deshabilitar el arranque de Hyper-V sin desinstalar el rol Hyper-V.
Inicie sesión en PowerShell como administrador o ejecute el comando desde un símbolo del sistema elevado para desactivar Hyper-V:
bcdedit /set hypervisorlaunchtype off
Si necesita volver a habilitar Hyper-V y establecer el valor predeterminado, ejecute este comando:
bcdedit /set hypervisorlaunchtype auto
Para mayor control y comodidad, desactive el arranque rápido en Windows 10. Abra el Editor del Registro de Windows y vaya a
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power
Ajuste el parámetro HiberbootEnabled a 0
Si a veces necesita utilizar máquinas virtuales Hyper-V, cree dos entradas para un cargador de arranque de Windows: una para arrancar Windows con Hyper-V y otra para arrancar Windows sin Hyper-V. A continuación, seleccione la opción necesaria antes de arrancar Windows. Este enfoque le evita tener que ejecutar comandos en PowerShell manualmente cada vez que necesite activar o desactivar Hyper-V.
bcdedit /copy "{current}" /d "No Hyper-V"
«La entrada se ha copiado correctamente en {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}.»
Copie y pegue su valor en lugar de xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx.
bcdedit /set "{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}" hypervisorlaunchtype off
Reinicia el ordenador.
Una vez reiniciado el ordenador, debería ver dos opciones en el Administrador de arranque de Windows.
Si desea eliminar la entrada de arranque No Hyper-V, utilice la opción /delete para bcdedit.
Obtener una lista de las entradas de arranque actuales:
bcdedit /v
En la salida se muestra una lista de todas las entradas con sus identificadores. Copie el ID de la entrada que desea eliminar y ejecute el siguiente comando:
bcdedit /delete "{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}"
Método 4: Desinstalar el rol Hyper-V en PowerShell con dism.exe
La idea detrás de este método es utilizar la herramienta de Servicio y Gestión de Imágenes de Instalación en la interfaz de línea de comandos para desinstalar Hyper-V.
Inicie sesión en CMD o PowerShell como Administrador. Ejecute el siguiente comando para desinstalar Hyper-V:
dism.exe /Online /Disable-Feature:Microsoft-Hyper-V
Si desea instalar Hyper -V de nuevo, utilice este comando:
dism.exe /Online /Enable-Feature:Microsoft-Hyper-V /All
Método 5: Desactivar la seguridad basada en la virtualización en Windows
Este método se utiliza para desactivar Device Guard y Credential Guard, que son funciones relacionadas con Hyper-V.
Abra el Editor de directivas de grupo para un equipo local. El Editor de directivas de grupo está disponible en Windows 10 Pro, Enterprise y Education. En el símbolo del sistema, ejecute gpedit.msc
Vaya a Política de equipo local > Configuración del equipo > Plantillas administrativas > Sistema > Device Guard
Haga doble clic en Activar seguridad basada en virtualización. Por defecto, el estado de este ajuste es No configurado.
En la ventana que se abre, seleccione Desactivado y pulse OK para guardar los ajustes, y cierre la ventana.
Editar el Registro como alternativa
En Windows 10 Home, donde no está presente el Editor de directivas de grupo, puede desactivar la Seguridad basada en virtualización en el Registro de Windows.
Haga un backup del registro de Windows antes de cambiar los ajustes del registro para evitar errores y problemas.
Abra el Editor del Registro. Ejecute regedit en la línea de comandos que debe abrirse como Administrador.
Vaya a HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control > DeviceGuard
Cree la entrada EnableVirtualizationBasedSecurity si falta esta entrada. Para crear una nueva entrada, haga clic con el botón derecho del ratón en un lugar vacío del directorio de DeviceGuard y, en el menú contextual, haga clic en Nuevo > Valor DWORD (32 bits). Introduzca el EnableVirtualizationBasedSecurity nombre de esta entrada del registro. Por defecto, los datos configurados para esta entrada deben ser 0 (véase la siguiente captura de pantalla). Puede hacer doble clic en el botón EnableVirtualizationBasedSecurity y configurar 0 manualmente.
Vaya a HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control > Lsa
Cree una nueva entrada de registro en el directorio Lsa. Haga clic con el botón derecho del ratón en un espacio vacío del panel derecho de la ventana del Editor del Registro. En el menú contextual, haga clic en Nuevo > Valor DWORD (32 bits).
Introduzca el LsaCfgFlags nombre de este valor. Este valor debe ajustarse a 0.
Cierre el Editor del Registro y reinicie el ordenador.
Puede ejecutar los siguientes comandos en PowerShell (como administrador) para desactivar Device Guard y Credential Guard en el siguiente arranque de Windows.
Monta una partición del sistema UEFI en la unidad X: (selecciona un volumen no utilizado):
mountvol X: /s
Copie el archivo C:\Windows\System32\SecConfig.efi a X:\EFI\Microsoft\Boot\SecConfig.efi con la opción de sobrescribir el archivo si el archivo existe. Este archivo es una imagen de arranque para la herramienta de configuración de seguridad de Windows.
copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y
Cree una nueva opción en el menú de arranque con el ID {0cb3b571-2f2e-4343-a879-d86a476d7215} y el nombre DebugTool:
bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
Establezca la opción de arranque que creó en el paso anterior en \EFI\Microsoft\Boot\SecConfig .efi:
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"
Configure el Gestor de arranque de Windows para que la nueva entrada sea la predeterminada en el próximo reinicio. Después de eso, reinicie su Windows debe volver al arranque normal.
bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
Configure el gestor de arranque para que pase las opciones DISABLE-LSA-ISO,DISABLE-VBS al archivo SecConfig.efi cuando el gestor de arranque inicie el archivo.
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO,DISABLE-VBS
Establece la partición de la unidad de arranque en X:
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
Desmonte la unidad X: del sistema:
mountvol X: /d
Método 6: Actualizar VMware Workstation
Si tiene Windows 10 versión 2004 (20H1) build 19041 o más reciente en su computadora física, puede actualizar VMware Workstation a VMware Workstation 15.5.6 o más reciente y ejecutar VMware VMs en su máquina Windows sin deshabilitar/desinstalar las funciones de Hyper-V y Virtualization Based Security (VBS), incluyendo Device Guard y Credential Guard.
Debido a las numerosas quejas de los clientes, Microsoft y VMware decidieron desarrollar un proyecto conjunto que adopta las API de Microsoft Windows Hypervisor Platform (WHP) para permitir que los hipervisores de tipo 2, como VMware Workstation, se ejecuten en un host en el que Hyper-V esté habilitado. Estas API permiten a las aplicaciones gestionar los recursos de la CPU, leer/escribir valores del registro, finalizar el funcionamiento de la CPU y generar interrupciones.
VMware Workstation antes de la versión 15.5.5 utiliza un Virtual Machine Monitor (VMM) que tiene acceso directo a la CPU y a los conjuntos de instrucciones de virtualización (Intel VT-x o AMD-V). Un VMM funciona en modo privilegiado. Si las funciones de seguridad basadas en la virtualización están activadas en un host Windows, se añade una capa adicional de hipervisor (Hyper-V) entre el hardware y Windows. Hyper-V tiene acceso directo a las funciones de la CPU utilizadas para la virtualización del hardware, y VMM no tiene acceso a las funciones de virtualización de la CPU.
VMware ha realizado cambios en la arquitectura de VMware Workstation 15.5.6 para permitir que su producto utilice las API de Microsoft WHP y solucionar el problema de compatibilidad. Ahora VMM puede ejecutarse a nivel de usuario (no en modo privilegiado) utilizando las API de WHP y ejecutar máquinas virtuales sin acceso directo a las extensiones de virtualización de la CPU. Este modo se denomina Monitor de Nivel de Usuario (ULM) o modo Host VBS. Si desinstalas las funciones relacionadas con Hyper-V de tu host Windows, VMware Workstation lo detecta automáticamente, y VMM se cambia al acceso directo de las extensiones de virtualización de CPU (ejecutándose en modo privilegiado).
Windows Hypervisor Platform (WHP) debe estar instalado en una máquina física Windows donde Hyper-V esté habilitado para permitir que VMware Workstation ejecute VMs VMware en esta máquina. Instale la función Plataforma de hipervisor de Windows en el Panel de control haciendo clic en Activar o desactivar las funciones de Windows.
De este modo, puede actualizar Windows 10 y VMware Workstation en su máquina física a versiones que admitan la ejecución de funciones relacionadas con Hyper-V y VMware Workstation VMs en la misma máquina.
Limitaciones del modo Host VBS:
- Windows Hypervisor Platform no es compatible con Windows Server 2016 y otras versiones y ediciones de Windows Server. Como resultado, VMware Workstation no puede ejecutar VMs en el modo host VBS en máquinas físicas que ejecutan Windows Server.
- La virtualización anidada no es compatible. No puede ejecutar VMs anidadas (VMs dentro de VMware Workstation VMs).
- Las máquinas virtuales de VMware pueden funcionar más lentamente.
- Los contadores de supervisión del rendimiento X86 (PMC) no son compatibles.
- La función de claves de protección en modo usuario (PKU) no está disponible.
- Las funciones de memoria transaccional restringida (RTM) y elisión de bloqueo de hardware (HLE) no están disponibles.
VirtualBox e Hyper-V
VirtualBox puede coexistir con Hyper-V, Device Guard y Credential Guard a partir de VirtualBox 6.0. VirtualBox 6 puede trabajar con las API de Hyper-V de forma similar a VMware Workstation en Windows 10 v1803 x64.
Estas funciones deben estar habilitadas en una máquina host Windows para permitir que VirtualBox funcione con las APIs Hyper-V:
- Hyper-V
- Plataforma Windows Hypervisor
Si la función Hyper-V está activada, pero la función Windows Hypervisor Platform está desactivada, en System > Acceleration en VM configuration summary, puede ver que el modo Paravirtualisation está activado. Si intenta iniciar una VM, VirtualBox le recuerda que debe activar la Plataforma Hipervisor de Windows y muestra el mensaje de error.
El mensaje de error:
¡WHvCapabilityCodeHypervisorPresent es FALSE! Asegúrese de que ha activado la función «Plataforma de hipervisor de Windows».
(VERR_NEM_NOT_AVAILABLE).
VT-x no está disponible (VERR_VMX_NO_VMX).
Si las funciones relacionadas con Hyper-V requeridas en Windows están habilitadas, se muestra la siguiente información para la VM en la sección Sistema:
Aceleración: VT-x/AMD-v, Nested Paging, Paravirtualización Hyper-V
La máquina virtual debería iniciarse correctamente. En el panel inferior de la ventana de VirtualBox aparece el icono de una tortuga verde. Este icono indica que una VM se está ejecutando en el modo de paravirtualización Hyper-V en lugar del modo nativo que suele utilizar VirtualBox cuando interactúa directamente con las extensiones de virtualización de la CPU. El rendimiento de las máquinas virtuales VirtualBox disminuye en las máquinas en las que Hyper-V y las funciones relacionadas están activadas. Puede desactivar o eliminar Hyper-V como se explicó anteriormente para ejecutar VMs en VirtualBox en el modo nativo utilizando extensiones de virtualización de CPU directamente.
Lee también la comparativa VirtualBox vs Hyper-V y la comparativa VirtualBox vs VMware.
Conclusión
Las nuevas funciones de Windows como la seguridad basada en la virtualización (Device Guard y Credential Guard), Windows Sandbox, WSL que utilizan el motor Hyper-V causan muchos problemas a los usuarios, administradores y desarrolladores de software que utilizan otros hipervisores como VMware Workstation, VirtualBox, QEMU y Google Android Emulator en máquinas Windows. Existen dos enfoques para resolver estos problemas de incompatibilidad: Desactivar/desinstalar Hyper-V o utilizar nuevas versiones de aplicaciones de virtualización que admitan el trabajo con las API de Hyper-V, como Windows Hypervisor Platform API proporcionada por Microsoft.
Ejecutar VMs en VirtualBox, VMware Workstation y otros hipervisores en máquinas con Hyper-V mediante el uso de APIs puede degradar el rendimiento de las VMs que no son Hyper-V. Hacer backup de los datos es crucial para los casos en que fallan las aplicaciones de virtualización. Si aún no ha elegido la mejor solución de backup de Hyper-V para su entorno, considere NAKIVO Backup & Replication. La solución ofrece backups robustos, protección contra el ransomware, recuperación ante desastres y mucho más. Descargue la edición gratuita para ver la solución en acción.
