Solución al error “Virtualized Intel VT‑x/EPT is Not Supported” en Surface Pro 8 y VMware

Al usar VMware Workstation 17 Pro en un Surface Pro 8 con Windows 11 Pro 24H2 y Seguridad Basada en Virtualización (VBS) activada, aparece el mensaje “Virtualized Intel VT‑x/EPT is Not Supported on this Platform”. A continuación se expone por qué sucede y todas las rutas posibles para resolverlo sin sacrificar productividad ni seguridad.

Descripción completa del problema

Cuando se crea o se inicia una máquina virtual con la casilla Virtualize Intel VT‑x/EPT habilitada, VMware intenta aprovechar las instrucciones de virtualización asistida por hardware del procesador Intel Tiger Lake que incorpora la Surface Pro 8. Sin embargo, si el sistema operativo host mantiene Device Guard y Credential Guard – componentes de VBS – estas instrucciones ya están “prestadas” al hipervisor protegido de Windows. El resultado es un fallo fatal antes de arrancar la VM, con el error citado y código de salida 0x80004005.

Por qué VBS ocupa VT‑x/EPT

VBS crea una pequeña máquina virtual de confianza (L0) mediante Hyper‑V. Esa “mini‑VM” aísla procesos sensibles (LSA, credenciales, claves TPM virtuales, etc.) del resto del sistema. Para lograrlo, reserva en exclusiva la extensión de paginación extendida (EPT) y los root modes de VT‑x. VMware Workstation, a su vez, precisa acceso directo para exponer Intel VT‑x/EPT a las máquinas virtuales invitadas. Como solo puede existir un hipervisor a la vez controlando el mismo conjunto de MSRs y tablas EPT, el choque es inevitable.

Relación con Windows Hello

En la práctica, Windows Hello for Business no depende técnicamente de Device Guard / Credential Guard; usa el TPM físico para proteger claves de credenciales. Sin embargo, muchos modelos Surface activan políticas OEM que reencienden todo el bloque VBS cuando Hello se reconfigura o cuando se añade un PIN/rostro. El usuario percibe una asociación causal que, en realidad, se basa en scripts de aprovisionamiento internos de Microsoft Surface.

Resumiendo los componentes en conflicto

Componente	Rol principal	Razón del conflicto
VBS (Device Guard, Credential Guard)	Hipervisor de confianza L0 que aísla secretos y ejecuta código protegido	Bloquea las extensiones VT‑x/EPT necesarias para VMware
Windows Hello	Autenticación biométrica / PIN respaldada por TPM	En Surface reactiva VBS al configurarse, re‑creando el bloqueo
VMware Workstation 17 Pro	Hipervisor hosted tipo 2 para entornos de laboratorio y desarrollo	Requiere acceso exclusivo a VT‑x/EPT cuando se virtualiza el VT al invitado

Opciones de solución detalladas

Opción A: Priorizar VMware Workstation (desactivar VBS y, si es necesario, Windows Hello)

1. Apagar el hipervisor protegido de forma permanente: bcdedit /set hypervisorlaunchtype off Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All
2. Deshabilitar Device Guard / Credential Guard con la herramienta oficial: .\DGReadinessTool_v3.6.ps1 -Disable La utilidad limpia las claves de arranque ELAM, revierte los GPO de VBS y solicita reinicio.
3. Verificar que “Aislamiento del núcleo” y “Integridad de memoria” estén en Desactivado en Configuración → Privacidad y seguridad → Seguridad de Windows → Seguridad del dispositivo.
4. Reconfigurar Windows Hello (si se necesita) y comprobar si renace VBS.
   En la mayoría de equipos no Surface, Hello permanece activo sin reactivar Device Guard. En Surface Pro 8 suele devolver VBS y, por ende, reintroducir el error de VMware; si ocurre, deberá elegirse entre VBS+Hello o VMware+VT‑x/EPT.

Ventajas: máximo rendimiento de VMware, acceso a snapshots complejos y a topologías virtuales avanzadas (por ejemplo, Cisco CML).
Desventajas: se sacrifica parte de la protección a credenciales y la prueba de futuro de Windows 11 frente a malware de kernel.

Opción B: Priorizar VBS y Windows Hello (migrar de VMware a Hyper‑V)

1. Mantener VBS habilitado tal cual lo dispone Surface.
2. Instalar el rol de Hyper‑V desde “Activar o desactivar características de Windows”; no requiere cambios adicionales.
3. Si se necesitan contenedores o Linux, activar igualmente WSL 2, que comparte el mismo hipervisor base y no colisiona.
4. Recrear las cargas de trabajo: Hyper‑V carece de algunas funciones (red fog computing, VLAN anidadas avanzadas, compatibilidad con complex network appliances) pero admite checkpoints y dinámico de RAM.

Ventajas: se conserva SecureBoot, Credential Guard y autenticación facial/PIN; parcheo de Microsoft garantizado.
Desventajas: pérdida de funciones exclusivas de VMware (clones vinculados, compatibilidad completa con vSphere Lab, interfaces de red personalizados tipo vmnet0/1/8 en modo usuario, Workstation‑Player cross‑compatibility).

Opción C: Necesito VMware + VT‑x/EPT y Windows Hello al mismo tiempo

Actualmente no existe configuración soportada oficial que permita coexistir los tres elementos en Surface Pro 8. El firmware UEFI reserva las capacidades de virtualización para VBS cuando las políticas OEM lo requieren. La única vía a medio plazo es:

• Abrir un ticket de soporte con Microsoft Surface Enterprise y adjuntar MSINFO32.nfo, DG_Readiness logs y VMware vmware‑log.txt.
• Monitorizar canales Insider/Preview de Windows y actualizaciones de firmware Surface UEFI; cualquier mejora llegaría vía un ACPI patch que permita compartir VMCS entre hipervisores o un nuevo modo de partición (análogo a Intel VT‑d Flexible Mode).

Opción D: Solo me preocupa arrancar las máquinas virtuales

Si Windows Hello no es imprescindible, basta con mantenerlo deshabilitado y aplicar el procedimiento de la opción A. Una estrategia mixta muy adoptada en entornos de pentesting es:

1. Desactivar VBS y Hello en el equipo anfitrión.
2. Usar YubiKey o credenciales FIDO para suplir la facilidad de Hello.
3. Mantener cifrado BitLocker completo (no depende de VBS) para proteger datos ante pérdida o robo.

Guía paso a paso para administradores

Identificar el estado actual

Get-CimInstance -ClassName Win32_DeviceGuard
SystemInfo | findstr /i "Hyper-V"
wmic cpu get VirtualizationFirmwareEnabled

Estos comandos confirman si VBS está activo, si Hyper‑V está habilitado y si el firmware expone VT‑x‑with‑EPT al SO.

Desactivar selectivamente Device Guard con GPO

1. Ejecuta gpedit.msc.
2. Navega a Directiva Equipo Local → Configuración del equipo → Plantillas administrativas → Sistema → Device Guard.
3. Define “Activar la seguridad basada en virtualización” → Deshabilitado.
4. Reinicia obligatoriamente.

En ediciones Pro basta, aunque algunas configuraciones OEM restablecen la política tras cada arranque si el dispositivo está inscrito en Autopilot. Compruébalo mediante rsop.msc.

Reparar VMware después del cambio

Cuando se elimina Hyper‑V, VMware suele detectar el retorno de VT‑x/EPT automáticamente. Si una VM aún no arranca:

• Edita el fichero .vmx y asegúrate de que vhv.enable = "TRUE" y hypervisor.cpuid.v0 = "FALSE" no aparezcan en la misma línea: causan ambigüedad en el host.
• Limpia módulos de kernel VMware con
  vmware‑modconfig --console --install‑all
• Activa “Virtualize CPU performance counters” solo si tu invitado los necesita.

Validar que Windows Hello no reactive VBS

1. Dirígete a Configuración → Cuentas → Opciones de inicio de sesión.
2. {@ Reagrega tu rostro o PIN y reinicia inmediatamente.}
3. Rerun SystemInfo | findstr /i "Hyper-V". Si se listan características Hyper‑V Client, entonces VBS ha regresado y necesitas optar por la Opción B o renunciar a Hello.

Buenas prácticas y recomendaciones finales

• Prepara un método de recuperación de BitLocker antes de toquetear VBS: un cambio de hipervisor puede obligar a introducir la clave de recuperación.
• Mantén tu contraseña de cuenta Microsoft actualizada; perderás el desbloqueo rápido del PIN temporalmente.
• Si administras entornos corporativos, documenta cada paso para cumplir auditoría de secure configuration baseline.
• Observa que Surface Pro 9 (Intel 13ᵃ Gen) maneja mejor la partición de recursos VT‑x/EPT; el comportamiento descrito es específico de la serie 8.

Preguntas frecuentes

¿Puedo usar VMware Workstation dentro de Hyper‑V en modo anidado?

No en un host Windows; VMware sobre Hyper‑V solo funciona en vSphere ESXi cuando se habilita VHV (virtual hardware virtualization) y se emula EPT. Hyper‑V no reexpone VT‑x/EPT a hipervisores hosted.

¿Es seguro desactivar Credential Guard?

Mientras mantengas BitLocker y un TPM activo, sigues protegido frente a ataques de pass‑the‑hash offline. Sin embargo, malware en modo kernel podría robar credenciales de LSA si logra vulnerar el sistema.

¿La edición Home de Windows 11 también activa VBS?

En general no, salvo que un OEM lo especifique. Windows 11 Home incluso carece de la GUI “Aislamiento del núcleo” para activar HVCI.

Conclusión

El error “Virtualized Intel VT‑x/EPT is Not Supported on this Platform” refleja un choque directo entre dos hipervisores que necesitan el mismo hardware. En Surface Pro 8 solo puedes escoger actualmente entre:

• La potencia y flexibilidad de VMware Workstation con VT‑x/EPT (sacrificando VBS y, posiblemente, Windows Hello).
• La seguridad reforzada de Windows 11 con VBS y autenticación biométrica (migrando a Hyper‑V o WSL 2).

No hay truco oculto, script mágico ni ajuste de registro que permita combinar los tres elementos al mismo tiempo sin parches de firmware. Hasta que llegue una actualización oficial, tu mejor estrategia es decidir cuáles son las prioridades de tu flujo de trabajo y aplicar la opción correspondiente.