KomuraSoft LLC
Contáctenos
Menú

Las profundidades de la virtualización de Windows (parte 1) — ¿Dónde se ejecuta realmente su Windows? El hipervisor y las particiones

· · Windows, Virtualización, Hyper-V, Hipervisor, SLAT, VMBus

Abra Información del sistema (msinfo32) en Windows 11 y verá a menudo «En ejecución» en el campo «Seguridad basada en virtualización», incluso en una máquina en la que nunca ha creado una máquina virtual.

Lo que eso significa es el siguiente hecho. En ese PC, el propio Windows anfitrión ya se ejecuta sobre un hipervisor. La «virtualización» ya no es una tecnología solo para quienes crean máquinas virtuales en el Administrador de Hyper-V. En Windows 11, la seguridad basada en virtualización (VBS) está habilitada de forma predeterminada en las configuraciones que cumplen las condiciones —por ejemplo, una instalación limpia en hardware compatible1—, y tanto WSL2 como Windows Sandbox se construyen sobre el mismo hipervisor de Windows. Bajo el Windows que usa a diario ya hay una capa más de software.

Esta serie, «Las profundidades de la virtualización de Windows», sigue lo que ocurre en esa capa, empezando por los fundamentos.

«Las profundidades de la virtualización de Windows» — Las 3 partes

  1. Parte 1 (este artículo): El hipervisor y las particiones
    Seguimos dónde termina ejecutándose el Windows anfitrión cuando se activa Hyper-V.
  2. Parte 2: Memoria que ni el kernel puede ver — VBS, HVCI y Credential Guard
    Seguimos dónde pone Windows secretos que ni un administrador ni el kernel pueden leer.
  3. Parte 3: Máquinas virtuales que arrancan en segundos — WSL2, Windows Sandbox y contenedores
    Seguimos, a partir de cómo se comparten la memoria y las imágenes, por qué WSL2 y Sandbox son ligeros aunque una máquina virtual completa sea pesada.

La pregunta que responde la parte 1 es solo una.

Cuando se activa Hyper-V, ¿dónde termina ejecutándose el Windows anfitrión?

Los lectores previstos son desarrolladores y operadores que usan Hyper-V, WSL2 o Windows Sandbox y quieren entender desde el mecanismo qué hay debajo. Los requisitos previos son Windows 10/11 x64 o una versión actual de Windows Server (el tratamiento de anillos, VT-x/AMD-V y EPT/RVI de este artículo asume x64; Arm64 usa un mecanismo distinto, como los niveles de excepción). El conocimiento de fondo exigido es aproximadamente la distinción entre modo kernel y modo usuario; no hace falta experiencia en operación de máquinas virtuales ni conocimiento de desarrollo de hipervisores. La dificultad es intermedia. Cubrimos el concepto de las extensiones de virtualización de la CPU, pero no entramos en detalles del conjunto de instrucciones.

1. Conclusión principal

Cuando se oye Hyper-V, se puede imaginar «software de ejecución de máquinas virtuales que se sienta encima de Windows». La estructura real es la inversa.

Desde el momento en que se activa Hyper-V y se reinicia, es el hipervisor el que controla las CPU y la memoria físicas, y el Windows anfitrión se ejecuta encima como la primera partición privilegiada: la «partición raíz».

Un hipervisor es una capa de software delgada que se sitúa entre el hardware y el sistema operativo, crea entornos de ejecución aislados llamados «particiones» y media el acceso al hardware.2 Aquella en la que entra el Windows anfitrión es la partición raíz; aquellas en las que entran las máquinas virtuales son las particiones hijas. La partición raíz se trata de forma especial (tiene acceso directo a los dispositivos físicos y tiene la pila de administración), pero en el sentido de que no controla de forma directa las CPU físicas, está en la misma posición que una partición hija.

Estructura general tras activar Hyper-VEl hipervisor se sitúa directamente sobre el hardware físico, y encima están la partición raíz que tiene el Windows anfitrión y las particiones hijas que tienen las máquinas virtualesHardware físicoHipervisorPartición raíz (Windows anfitrión)Particiones hijas (MV)Tiene la pila de administración y los controladores

Figura 1: Hyper-V no es «software de MV encima de Windows», sino una capa que se mete debajo de Windows, y el propio sistema operativo anfitrión se ejecuta dentro de la partición raíz.

Se podría pensar: «Si no se nota nada distinto después de activarlo, ¿ha ocurrido de verdad una inversión tan grande?» Ha ocurrido. Precisamente por eso esta estructura suele pasar desapercibida. En este artículo desmontamos este único diagrama a lo largo de tres ejes: CPU, memoria y E/S de dispositivos.

2. Desde la CPU — Un privilegio más debajo de los anillos

2.1. Un repaso de la protección por anillos

Las CPU x64 tienen niveles de privilegio (anillos), y Windows ejecuta el modo kernel en el anillo 0 y el modo usuario en el anillo 3. Las aplicaciones no pueden tocar el hardware de forma directa porque las instrucciones privilegiadas no se pueden ejecutar desde el anillo 3.

Entonces, ¿cómo se alojan con seguridad varios kernels de sistema operativo, cada uno ejecutándose en el anillo 0, en la misma CPU física? Cada kernel está escrito bajo el supuesto de que «yo controlo la CPU». Dar el anillo 0 a todos hace que choquen; denegárselo y no se ejecutarán.

El problema de varios kernels de SO que exigen el anillo 0Tanto el kernel anfitrión como el invitado están escritos asumiendo autoridad plena en el anillo 0, así que la escalera tradicional de anillos por sí sola no puede alojarlos con seguridad en la misma CPU físicaKernel anfitrión (asume anillo 0)Exige el control de la CPU físicaKernel invitado (asume anillo 0)Los anillos tradicionales no lo concilianHace falta un mediador por encima del anillo 0

Figura 2: La escalera de anillos se construyó asumiendo un solo sistema operativo, así que alojar varios kernels necesita un privilegio más por encima.

2.2. Extensiones de virtualización — Un modo reservado al hipervisor

Lo que resuelve este problema son las extensiones de virtualización de la CPU (Intel VT-x/AMD-V). Hyper-V exige un procesador que tenga esta función.2 Las extensiones de virtualización añaden, en un eje distinto de los anillos tradicionales, un «modo de ejecución para el hipervisor» y un «modo de ejecución para invitados». Es un privilegio aún más fuerte que el anillo 0, a veces apodado «anillo -1».

  • El kernel invitado sigue ejecutándose en el anillo 0, como hasta ahora. No hace falta reescribirlo.
  • Ese anillo 0, sin embargo, es «anillo 0 dentro del modo invitado», y no controla la CPU física en su conjunto.
  • Cuando el invitado da con una operación concreta que exige la intervención del hipervisor (una instrucción configurada como interceptación, o una excepción o violación), la CPU transfiere automáticamente el control al hipervisor (un VM Exit). Cuando el hipervisor termina de gestionarla, vuelve al invitado (un VM Entry). Los accesos ordinarios a memoria pasan sin VM Exit, siempre que la traducción SLAT tenga éxito.

Las interrupciones funcionan del mismo modo. Las particiones no tocan los procesadores físicos de forma directa; el hipervisor recibe las interrupciones y las dirige a cada partición.2

El flujo de la ejecución del invitado y el VM ExitEl kernel invitado y las aplicaciones se ejecutan en el anillo 0 y el anillo 3 en modo invitado; los accesos ordinarios a memoria pasan mediante la traducción SLAT, mientras que las interceptaciones y excepciones configuradas provocan un VM Exit que transfiere el control al hipervisor, que luego vuelve al invitado mediante VM EntryNoSíEjecución en modo invitado (incluye un kernel anillo 0)¿Operación que necesita intervención? (interceptaciones/excepciones)Seguir ejecutando tal cualVM Exit (la CPU transfiere el control)El hipervisor lo gestionaVolver al invitado mediante VM Entry

Figura 3: El sistema operativo invitado sigue ejecutándose en el anillo 0 sin reescritura, y la CPU llama al hipervisor solo cuando hace falta.

Este ida y vuelta se parece mucho al flujo que seguimos en la serie de memoria: «entrar en el kernel en un fallo de página y luego volver a la misma instrucción». La CPU intercepta el control mediante un mecanismo de excepción o de transición, deja decidir a un gestor de nivel superior y luego vuelve. En las profundidades de Windows, esta forma aparece una y otra vez.

2.3. Tipo 1 y tipo 2 — La diferencia es dónde se sitúa

Los hipervisores se dividen a grandes rasgos en tipo 1 (bare-metal), que se ejecuta directamente sobre el hardware, y tipo 2 (hospedado), que se ejecuta encima de un sistema operativo anfitrión. Hyper-V es tipo 1.3 VirtualBox y VMware Workstation (cuando se ejecutan de forma independiente) se clasifican como tipo 2.

Al oír tipo 1, se tiende a imaginar «una configuración solo de servidor, sin sistema operativo anfitrión», pero Hyper-V es distinto. El Windows anfitrión no desaparece: «se muda» a la partición raíz. Cuando se activa Hyper-V y se reinicia, el hipervisor arranca primero durante el arranque, y el Windows anfitrión luego sube como partición raíz encima.

La diferencia entre hipervisores de tipo 1 y tipo 2En el tipo 2 el sistema operativo anfitrión se sitúa sobre el hardware y el hipervisor y las máquinas virtuales se sitúan sobre el sistema operativo anfitrión, mientras que en el tipo 1 Hyper-V el hipervisor se sitúa directamente sobre el hardware y el propio sistema operativo anfitrión entra en la partición raíz encimaTipo 1 (Hyper-V)Tipo 2 (hospedado)HipervisorHardwarePartición raíz (SO anfitrión)MVSO anfitriónHardwareHipervisorMV

Figura 4: En el tipo 2 el hipervisor se sitúa sobre el sistema operativo anfitrión, mientras que en el tipo 1 Hyper-V el orden se invierte y el propio sistema operativo anfitrión se sitúa en la capa un escalón por debajo.

Visto en una línea de tiempo de arranque, el cambio que ocurre al activarlo se ve así.

Orden de arranque tras activar Hyper-VTras el encendido, el hipervisor arranca primero durante el arranque, el Windows anfitrión luego sube como partición raíz encima, y las máquinas virtuales, VBS y similares arrancan despuésEncender y empezar el arranqueEl hipervisor arranca primeroWindows anfitrión arranca como partición raízMV, VBS, WSL2, etc. arrancan encimaLa experiencia del usuario no cambia

Figura 5: La inversión de orden ya está terminada antes de que aparezca la pantalla de inicio de sesión, y el sistema operativo anfitrión sube sobre el hipervisor desde el principio.

3. Particiones — La unidad de aislamiento

3.1. Papeles que solo tiene la partición raíz

Una partición es una unidad lógica de aislamiento que ofrece el hipervisor.2 No todas las particiones son iguales, sin embargo. Hay cosas que solo tiene la partición raíz.

  • Acceso directo a los dispositivos físicos. Los controladores de dispositivo de discos, NIC, GPU y similares viven en el Windows de dentro de la partición raíz, no en el hipervisor. Hyper-V en Windows Server sí tiene una configuración que asigna un dispositivo PCIe concreto de forma directa a una partición hija (Discrete Device Assignment); en ese caso la raíz suelta ese dispositivo (esto no está disponible en Windows cliente).4
  • La pila de administración de la virtualización. VMMS (Virtual Machine Management Service), que gobierna la creación, el arranque y la detención de máquinas virtuales, y el proceso trabajador por máquina virtual (vmwp.exe) se ejecutan en modo usuario en la partición raíz.5 Estos forman parte de las funciones de administración de máquinas virtuales de Hyper-V, así que pueden faltar en un anfitrión donde solo está en ejecución el hipervisor para VBS o WSL2.
  • El derecho a crear particiones hijas. La partición raíz crea particiones hijas mediante la API de hypercall (la interfaz de llamada al hipervisor).2

Este diseño tiene un motivo. Si se mete cada controlador de dispositivo en el propio hipervisor, el hipervisor se vuelve enorme y crece el número de errores y de puntos de entrada de ataque. El hipervisor se limita al trabajo mínimo de mediar CPU y memoria, y deja el cuidado de los dispositivos al Windows de la partición raíz. Esta división de papeles es lo que mantiene Hyper-V delgado.

División de papeles entre la partición raíz y las particiones hijasLa partición raíz tiene la pila de administración de la virtualización y los controladores de dispositivo físicos y crea particiones hijas mediante hypercalls; una partición hija normalmente solo ve dispositivos virtuales, y con Discrete Device Assignment en Windows Server accede de forma directa al dispositivo asignadoPartición raízCrear y gestionar mediante hypercallsPartición hijaSO invitadoEn la config. habitual, solo se ven dispositivos virtualesVMMS y procesos trabajadoresControladores de dispositivo físicosHipervisor (se limita a mediar CPU y memoria)

Figura 6: Poner los controladores de dispositivo y la pila de administración en el lado de la partición raíz es lo que mantiene delgado al propio hipervisor.

3.2. El mundo visto desde una partición hija

El sistema operativo invitado de una partición hija no puede ver el hardware físico de forma directa en la configuración habitual de dispositivos virtuales (la única excepción es un dispositivo asignado mediante Discrete Device Assignment en Windows Server, como se describió en el apartado anterior). Lo que puede ver son procesadores virtuales, un espacio de memoria que parece propio, y dispositivos virtuales. Las peticiones a dispositivos virtuales se reenvían a la partición raíz mediante VMBus o el hipervisor.2 La asignación de tiempo de CPU y la traducción de memoria mediante SLAT, en cambio, las gestiona de forma directa el hipervisor sin pasar por la raíz. Lo que la raíz media es la E/S de dispositivos, no todos los recursos físicos.

El mundo visto desde una partición hijaLo que el sistema operativo invitado ve son procesadores virtuales, un espacio de memoria privado de la partición y dispositivos virtuales; las peticiones a dispositivos virtuales se reenvían a la partición raíz mediante VMBus y similares, el tiempo de CPU y la traducción de memoria las gestiona de forma directa el hipervisor, y en una configuración Discrete Device Assignment en Windows Server solo se accede de forma directa a los dispositivos asignadosSO invitado（hija）Procesadores virtuales¿Memoria o dispositivos?Memoria privadaDispositivos virtualesReenviado a la raízMediante VMBus y similaresCPU, RAM, dispositivosNo visibles en directoDDA: dispositivos asignadosWindows Server

Figura 7: En la configuración habitual de dispositivos virtuales todo lo que el invitado ve es una ventana virtual y el camino a lo físico pasa por un mediador; solo un dispositivo asignado mediante DDA en Windows Server es la excepción.

Lo que importa aquí es que para una aplicación que se ejecuta en el Windows anfitrión, esta estructura es casi transparente. Las llamadas a la API de Win32 y el manejo de fallos de página los sigue procesando el kernel de Windows dentro de la partición raíz, como hasta ahora. El hipervisor interviene solo cuando se da con una interceptación o una excepción configurada.

4. Desde la memoria — La traducción de direcciones gana un nivel más

4.1. Tres tipos de dirección

En la parte 1 de la serie de memoria seguimos el flujo por el que una dirección virtual se traduce a través de la tabla de páginas en una dirección física («El instante en que una dirección virtual se convierte en RAM física»). En un entorno virtualizado se añade un nivel más debajo de esa traducción, y hay tres tipos de dirección.

Dirección Abreviatura Quién la gestiona
Dirección virtual del invitado GVA La tabla de páginas del SO invitado
Dirección física del invitado GPA La dirección que el SO invitado cree «física»
Dirección física del sistema SPA El hipervisor (la ubicación real en la RAM)

El sistema operativo invitado traduce GVA a GPA con su propia tabla de páginas. La GPA que ve el invitado, sin embargo, no es una dirección física real; es un espacio de memoria privado dedicado a cada partición.2 Mapear GPA sobre la ubicación real en la RAM (SPA) es el trabajo del hipervisor.

4.2. SLAT — Traducción de dos niveles en hardware

Si se hace esta traducción de segundo nivel solo en software, el hipervisor tiene que seguir una a una cada actualización de la tabla de páginas del invitado, lo que no es realista desde el punto de vista del rendimiento. Así que la CPU ofrece un mecanismo que recorre las tablas de traducción de segundo nivel en hardware. Eso es SLAT (Second Level Address Translation); Intel EPT (Extended Page Tables) y AMD RVI son las implementaciones. El Hyper-V actual exige un procesador de 64 bits compatible con SLAT.4

Traducción de direcciones de dos niveles mediante SLATUna dirección virtual del invitado se traduce a una dirección física del invitado por la tabla de páginas del sistema operativo invitado, y luego se traduce de nuevo a una dirección física del sistema por SLAT, que gestiona el hipervisor, y llega a la RAM realTabla de páginas del SO invitadoSLAT (tablas EPT/RVI)Dirección virtual del invitado (GVA)Dirección física del invitado (GPA)Dirección física del sistema (SPA)RAM físicaUna capa que el invitado solo cree física

Figura 8: Otra tabla de traducción, gestionada por el hipervisor, se sitúa bajo la tabla de páginas del invitado, y la CPU recorre ambas en hardware.

SLAT no es una función que exista solo para la eficiencia de ejecución de máquinas virtuales. El VBS que veremos en la parte 2 usa la propiedad de que «se puede tener una tabla de traducción SLAT distinta por nivel de privilegio» como material para una frontera de seguridad. La razón de que se pueda crear memoria que ni el kernel puede ver es que el hipervisor tiene esta traducción de segundo nivel. Esto se convierte en un hilo conductor de toda la serie, así que recuerde solo un punto: «el dueño de las tablas de traducción es el hipervisor».

5. Desde la E/S de dispositivos — VMBus y dos tipos de dispositivo

5.1. Los límites de los dispositivos emulados

La forma clásica de mostrar un dispositivo a una partición hija es imitar por completo hardware real (un controlador IDE antiguo, por ejemplo) en software. La compatibilidad es alta porque los controladores de bandeja del sistema operativo invitado funcionan tal cual, pero se produce un VM Exit cada vez que el invitado da con un puerto de E/S, y el rendimiento no escala.

Por qué la E/S a un dispositivo emulado es lentaCada vez que el invitado opera un puerto de E/S, el control se transfiere al lado del hipervisor mediante un VM Exit, el dispositivo se imita en software y se vuelve al invitado, de modo que el ida y vuelta se repite y es lentoSe repite en la siguiente operación de puertoEl invitado opera un puerto de E/SSe produce un VM ExitEl dispositivo se emula en softwareVolver al invitado mediante VM Entry

Figura 9: Este ida y vuelta se ejecuta muchas veces detrás de un solo acceso a disco, y el precio de la compatibilidad se paga en rendimiento.

5.2. VMBus y VSP/VSC — Un camino rápido diseñado para la virtualización

Así que Hyper-V tiene un mecanismo de «dispositivo sintético» diseñado bajo el supuesto de la virtualización. Hay tres personajes.2

  • VMBus: un canal de comunicación lógico entre particiones. Ofrece comunicación de alta velocidad entre particiones que usa memoria compartida.3
  • VSP (Virtualization Service Provider): un servicio que reside en el lado de la partición raíz, recibe las peticiones de dispositivo de la hija y las tiende hacia la pila de dispositivo/backend del lado raíz. Una petición puede llegar a un dispositivo físico, o puede gestionarla un backend del lado anfitrión como un disco virtual o un conmutador virtual.
  • VSC (Virtualization Service Consumer): un controlador de dispositivo sintético que entra en el sistema operativo invitado del lado de la partición hija. Envía peticiones al VSP por VMBus.

Tomando como ejemplo una petición de almacenamiento del sistema operativo invitado, el flujo se ve así. El WriteFile de la aplicación invitada desciende por la pila de E/S del kernel invitado y, al fondo, llega al VSC (en lugar de al hardware real). El VSC pone la petición en VMBus y se la entrega al VSP de la partición raíz, y el VSP hace fluir la petición hacia la pila de E/S del lado raíz. En una configuración de disco virtual (VHDX), esta escritura se gestiona como una escritura a un archivo VHDX en el anfitrión y acaba llegando al disco físico. Este enfoque se llama Enlightened I/O (E/S consciente de la virtualización), y eleva la eficiencia al saltarse la capa de emulación de dispositivo.2

Camino de E/S de un dispositivo sintéticoUna petición de E/S de una aplicación de la partición hija llega al VSC a través del kernel invitado, cruza VMBus hasta el VSP de la partición raíz y, en la pila de E/S del lado raíz a la que el VSP tiende el puente, puede llegar a un dispositivo real mediante un controlador de dispositivo físico, o puede gestionarla un backend del lado anfitrión como un disco virtual o un conmutador virtualVMBusAplicación en la partición hijaPila de E/S del kernel invitadoVSC (controlador de dispositivo sintético)VSP (lado de la partición raíz)Pila de E/S del lado raízControlador de dispositivo físicoBackend del anfitrión (disco virtual, conmutador, etc.)Dispositivo físico

Figura 10: Con un dispositivo sintético, la E/S del invitado cruza a la partición raíz por VMBus y, a través de la pila del lado raíz, llega a un dispositivo real o a un backend del lado anfitrión.

Dicho de otro modo, que la E/S de disco o la red de una máquina virtual sea rápida depende no solo del lado invitado sino también del estado de la pila de E/S y de los controladores de dispositivo del lado de la partición raíz. La razón de que la observación del lado anfitrión sea indispensable cuando se investiga un problema de rendimiento de una máquina virtual es que el camino pasa de hecho por el anfitrión.

Dispositivos emulados frente a dispositivos sintéticosUn dispositivo emulado imita hardware real para que funcionen los controladores de bandeja del invitado pero es lento; un dispositivo sintético es un controlador hecho a propósito que asume VMBus y es rápidoDispositivo mostrado a la partición hijaDispositivo emuladoDispositivo sintéticoEmula hardware real; compatibilidad primeroNecesita intervención en cada E/S; lentoDiseñado en torno a VMBus; rápidoExige un controlador coincidente en el invitado

Figura 11: De los dos tipos de dispositivo virtual, los emulados llevan la compatibilidad justo después de instalar el sistema operativo, y los sintéticos llevan el rendimiento en el uso cotidiano.

6. Por qué esto no es un problema ajeno, aunque nunca use una máquina virtual

La estructura hasta aquí puede parecer «una historia para quienes levantan máquinas virtuales». Como decía la apertura, sin embargo, en el Windows actual el hipervisor forma parte de la vida cotidiana.

  • Seguridad basada en virtualización (VBS). Usa el hipervisor de Windows para crear un entorno aislado y aloja ahí funciones de seguridad. En Windows 11 está habilitada de forma predeterminada cuando se cumplen condiciones como una instalación limpia en hardware compatible.1 Los detalles están en la parte 2.
  • WSL2. Ejecuta un kernel de Linux real dentro de una máquina virtual de utilidad ligera.6
  • Windows Sandbox. Un entorno de Windows desechable aislado por el hipervisor.7 Ambos se cubren en la parte 3.
Funciones cotidianas que se sitúan sobre el mismo hipervisorNo solo las máquinas virtuales de Hyper-V, sino también VBS, que está habilitada de forma predeterminada en los dispositivos que cumplen condiciones como una instalación limpia, más WSL2 y Windows Sandbox, se construyen todos sobre el mismo hipervisor de WindowsHipervisor WindowsVM de Hyper-VVBS (predet. en inst. limpia)WSL2Windows SandboxPor qué corre en PC sin MV

Figura 12: Hay un solo fundamento, y esta figura es donde se cae el supuesto de que «la virtualización es una historia para quienes usan máquinas virtuales».

Una cosa más en la que se pisa a menudo en la práctica es la coexistencia con software de virtualización de terceros. Como el hipervisor usa las extensiones de virtualización de la CPU de forma exclusiva, en un entorno donde el hipervisor de Windows está en ejecución, VirtualBox y similares no pueden ejecutarse de la forma tradicional (la que usa ella misma las extensiones de virtualización de la CPU). Para esto se ofrece una API pública llamada Windows Hypervisor Platform, y una pila de virtualización de terceros puede ejecutarse situándose encima del hipervisor de Windows.8 El VirtualBox/VMware actual puede coexistir con WSL2 gracias a este mecanismo, pero las diferencias de rendimiento y de funciones que vienen con el cambio de modo se observan a veces como «después de activar Hyper-V (o VBS), el software de virtualización empezó a comportarse de otra forma».

Quién posee las extensiones de virtualización de la CPU, y el camino para el software de virtualización de tercerosMientras el hipervisor de Windows está en ejecución posee de forma exclusiva las extensiones de virtualización de la CPU; el software de virtualización de terceros que admite WHP se ejecuta encima mediante Windows Hypervisor Platform, mientras que las implementaciones que no admiten WHP no pueden ejecutarse o quedan limitadasNoSíExtensiones de virtualización de la CPU (VT-x/AMD-V)¿Está en ejecución el hipervisor de Windows?El software de terceros puede usarlo de forma directaEl hipervisor lo usa en exclusivaWindows Hypervisor PlatformEl software de terceros compatible con WHP se ejecuta encimaLas implementaciones no compatibles no se ejecutan, o quedan limitadas

Figura 13: Hay un solo dueño de las extensiones de virtualización, y el único software de terceros que puede coexistir mientras el hipervisor está en ejecución es el que admite la API pública (WHP).

7. Compruébelo usted mismo

Puede confirmar en su propia máquina si un hipervisor está en ejecución.

Primero, una comprobación que se puede ejecutar sin privilegios de administrador.

# Whether we are running on top of a hypervisor
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent

# VBS status (same source as "Virtualization-based security" in msinfo32)
Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus

VirtualizationBasedSecurityStatus devuelve el estado de ejecución de VBS como un número (2 es «En ejecución»).9

Una precaución. Todo lo que HypervisorPresent dice es «si nos ejecutamos sobre un hipervisor»; no distingue raíz de hija. Si se ejecuta en Windows dentro de una máquina virtual, sigue devolviendo True, como partición hija. Si es True en Windows en un PC físico, ese Windows está dentro de la partición raíz: se lee junto con el entorno de ejecución.

A continuación, el clásico desde un símbolo del sistema.

systeminfo

Mire «Hyper-V Requirements» al final de la salida. En una máquina donde el hipervisor aún no está en ejecución, se enumeran los requisitos individuales: compatibilidad con SLAT, si las extensiones de virtualización están habilitadas, etc. En una máquina donde el hipervisor ya está en ejecución, en lugar de los requisitos aparece una sola línea: «A hypervisor has been detected. Features required for Hyper-V will not be displayed.»4 Esa línea es, por tanto, una afirmación de que su Windows se ejecuta sobre algún hipervisor. Como con HypervisorPresent, hay que leerlo como «dentro de la partición raíz» en un PC físico, o «como partición hija» dentro de una máquina virtual.

Aunque todos los requisitos de systeminfo sean «Yes», eso solo significa que el lado del hardware está listo. La propia función Hyper-V está disponible en las ediciones Pro, Enterprise y Education, y no en Home.10

En la interfaz gráfica, compruebe la fila «Seguridad basada en virtualización» bajo «Resumen del sistema» en msinfo32. Tenga en cuenta que «Virtualización: habilitada» en el panel de CPU del Administrador de tareas solo muestra si las extensiones de virtualización están habilitadas en el firmware, que es información distinta de si un hipervisor está en ejecución.

Cómo comprobar si el hipervisor está en ejecuciónSi systeminfo dice que se ha detectado un hipervisor, se está ejecutando sobre un hipervisor (dentro de la partición raíz en un PC físico); si aparece la lista Hyper-V Requirements aún no está en ejecución, así que se comprueba cada requisito como SLAT, VM Monitor Mode Extensions y DEP, pero todo Yes solo significa que el lado del hardware está listo y la función Hyper-V también tiene un requisito de ediciónDetectadoEnumeradoTodos YesAlguno NoEjecutar systeminfo¿Campo de requisitos?El hipervisor está en ejecuciónDentro de la raízen un PC físicoAún no está en ejecución¿Todos los requisitos Yes?El lado del hardware está listoHace falta Pro / Ent / EduComprobar elementos de UEFI/BIOS

Figura 14: El campo «Hyper-V Requirements» de systeminfo sirve a la vez como comprobación de estado de ejecución y como comprobación de requisitos previos.

8. Tres lecturas erróneas que conviene evitar en la práctica

8.1. «No hemos activado Hyper-V, así que la virtualización no tiene nada que ver con nuestros PC»

Aunque no se haya activado la función Hyper-V (las herramientas de administración y el entorno de ejecución de máquinas virtuales), el hipervisor de Windows está en ejecución si VBS está habilitada. Cuando se investiga un problema de compatibilidad de controladores, una prueba de rendimiento o un problema con software de virtualización de terceros, compruebe HypervisorPresent y el estado de ejecución de VBS, no si la función está activada.

8.2. «El Administrador de tareas dice “Virtualización: habilitada”, así que Hyper-V está en ejecución»

Esa indicación es sobre el ajuste del firmware (si VT-x/AMD-V está disponible). Juzgue el estado de ejecución del hipervisor a partir de «A hypervisor has been detected» en systeminfo. A la inversa, si el Administrador de tareas dice «Deshabilitada», tampoco se puede activar Hyper-V ni WSL2, así que compruebe primero los ajustes de UEFI/BIOS.

Tres comprobaciones que es fácil confundirEl campo Virtualización del Administrador de tareas muestra el ajuste del firmware, la lista de características de Windows muestra el estado de instalación, y systeminfo o HypervisorPresent muestran el estado de ejecución; cada uno responde a una pregunta distinta¿Qué pregunta?¿Firmware o Windows?¿Hipervisor en marcha?¿Extensiones de firmware?¿Función Hyper-V on?CPU del AdministradorCaracterísticas WindowssysteminfoHypervisorPresent

Figura 15: Son tres preguntas independientes, e inferir las otras dos a partir de cualquier indicación es una lectura errónea.

8.3. «Si la máquina virtual es lenta, es un problema del sistema operativo invitado»

La E/S de un dispositivo sintético cruza VMBus hasta el VSP de la partición raíz y pasa por la pila de dispositivo/backend del lado raíz (controladores físicos, más el procesamiento del conmutador virtual y del disco virtual). Si solo se miran contadores dentro del invitado, no se encontrará un cuello de botella que esté en el almacenamiento o en una NIC del lado anfitrión. El principio para los problemas de rendimiento de una máquina virtual es observar desde ambos lados: el invitado y el anfitrión (la partición raíz).

9. Resumen

  • Cuando se activa Hyper-V, el hipervisor se ejecuta directamente sobre el hardware y el Windows anfitrión se ejecuta como partición raíz.2
  • El kernel del sistema operativo invitado sigue ejecutándose en el anillo 0, y solo las operaciones configuradas como interceptaciones, más las excepciones, se entregan al hipervisor mediante un VM Exit. Los accesos ordinarios a memoria pasan mediante la traducción SLAT.
  • Solo la partición raíz tiene los controladores de dispositivo físicos y la pila de administración de la virtualización, y crea particiones hijas mediante hypercalls.2
  • La memoria se convierte en una traducción de dos niveles GVA→GPA→SPA, y el segundo nivel lo gestiona en hardware SLAT (EPT/RVI). El Hyper-V actual exige SLAT.4
  • La E/S de dispositivos la domina el camino de dispositivo sintético VSC→VMBus→VSP, y el rendimiento también depende de la pila de E/S del lado anfitrión.2
  • En Windows 11, como VBS está habilitada de forma predeterminada en los dispositivos que cumplen condiciones como una instalación limpia, no es raro que el hipervisor esté en ejecución incluso en un PC que nunca usa una máquina virtual.1 Se puede confirmar el estado de ejecución con HypervisorPresent y systeminfo.

El panorama general de la parte 1 se condensa en este único diagrama.

El panorama general de la parte 1El hipervisor se sitúa bajo la partición raíz y las particiones hijas; las CPU se asignan programando procesadores virtuales (VM Exit solo en interceptaciones y excepciones configuradas), la memoria la media la traducción SLAT de dos niveles, la E/S de dispositivos sintéticos se reenvía por VMBus y la gestiona el VSP de la partición raíz, y los dispositivos emulados y Discrete Device Assignment tienen otros caminosParticiones raíz + hijasHipervisorCPU: programar VPMemoria: SLATVM Exit en interceptaciónTraducción de dos nivelesDispositivos: E/S VMBusEl VSP del lado raíz gestionaEmulado / DDA: otro

Figura 16: La programación de la CPU y la traducción de memoria las gestiona de forma directa el hipervisor (VM Exit solo en la intervención), y la E/S de dispositivos sintéticos la media la partición raíz (el VSP) al otro lado de VMBus.

Continúa en la parte 2, «Memoria que ni el kernel puede ver — VBS, HVCI y Credential Guard».

Recogemos el hilo conductor de este artículo —que el hipervisor tiene las tablas de traducción SLAT— y seguimos cómo Windows crea «memoria que ni un administrador ni el kernel pueden leer».

Artículos relacionados

Áreas de consultoría relacionadas

En KomuraSoft LLC nos encargamos del diseño de entornos de validación para aplicaciones Windows, de las investigaciones de rendimiento en entornos virtualizados y del análisis de problemas de compatibilidad de controladores y periféricos.

Referencias

  1. Microsoft Learn, Silicon assisted security. Sobre que VBS usa la virtualización de hardware para aislar el Secure Kernel del sistema operativo ordinario, y sobre que VBS y HVCI están habilitados de forma predeterminada en los dispositivos que cumplen los requisitos previos en una instalación nueva de Windows 11. ↩ ↩2 ↩3

  2. Microsoft Learn, Hyper-V Architecture. Sobre que el hipervisor ofrece particiones como unidad de aislamiento; que la partición raíz crea particiones hijas mediante la API de hypercall; que las particiones se ejecutan en un espacio de memoria virtual privado sin acceso directo a los procesadores físicos; los papeles de VMBus, VSP, VSC y Enlightened I/O; y que se exigen las extensiones de virtualización de hardware (Intel VT/AMD-V). ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12

  3. Microsoft Learn, Hyper-V architecture (Performance Tuning). Sobre que Hyper-V es un hipervisor de tipo 1, que la partición raíz posee los dispositivos de E/S físicos, y que VMBus ofrece comunicación de alto rendimiento entre particiones que usa memoria compartida. ↩ ↩2

  4. Microsoft Learn, System requirements for Hyper-V on Windows and Windows Server. Sobre que se exigen un procesador de 64 bits compatible con SLAT y VM Monitor Mode Extensions; la posibilidad de confirmar que se cumplen los requisitos en el campo «Hyper-V Requirements» de systeminfo; que se muestra «A hypervisor has been detected» mientras un hipervisor está en ejecución; y que Discrete Device Assignment puede asignar un dispositivo concreto de forma directa a una partición hija. ↩ ↩2 ↩3 ↩4

  5. Microsoft Learn, Appendix B: Hyper-V Architecture and Feature Overview. Sobre que VMMS (Virtual Machine Management Service) gestiona el estado de las máquinas virtuales en las particiones hijas, y que un proceso trabajador (VMWP) arranca en modo usuario en la partición raíz por cada máquina virtual. ↩

  6. Microsoft Learn, Comparing WSL Versions. Sobre que WSL2 ejecuta un kernel de Linux real dentro de una máquina virtual de utilidad ligera, y sobre las precauciones al usarlo junto con el VMware y VirtualBox actuales. ↩

  7. Microsoft Learn, Windows Sandbox architecture. Sobre que Windows Sandbox es un entorno de Windows ligero que combina la tecnología de contenedores con el aislamiento por el hipervisor. ↩

  8. Microsoft Learn, Windows Hypervisor Platform. Sobre que se ofrece una API de modo usuario para que una pila de virtualización de terceros pueda crear y gestionar particiones sobre el hipervisor de Windows. ↩

  9. Microsoft Learn, Enable Hotpatch for Azure Arc-enabled servers. Sobre poder confirmar el estado de ejecución de VBS (virtual secure mode) mediante VirtualizationBasedSecurityStatus de la clase Win32_DeviceGuard. ↩

  10. Microsoft Learn, Install Hyper-V. Sobre que Hyper-V se puede activar en Windows 10/11 Pro o Enterprise y similares, y no se puede instalar en la edición Home. ↩

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

Cuando se activa Hyper-V, ¿dónde se ejecuta realmente el Windows anfitrión?
El hipervisor toma el control directo de cómo se asignan las CPU y la memoria físicas, y el Windows anfitrión se ejecuta dentro de una partición especial llamada partición raíz. El control de los dispositivos físicos lo gestionan normalmente los controladores del lado de la partición raíz. La partición raíz tiene los controladores de dispositivo y la pila de administración de la virtualización, pero la propiedad de las CPU físicas pertenece al hipervisor.
¿«Virtualización: habilitada» del Administrador de tareas significa que Hyper-V está en ejecución?
No. Esa indicación muestra si las extensiones de virtualización de la CPU (Intel VT-x/AMD-V) están habilitadas en el firmware. Para ver si un hipervisor está realmente en ejecución, busque «A hypervisor has been detected» en systeminfo, o compruebe Win32_ComputerSystem.HypervisorPresent.
¿Por qué está en ejecución el hipervisor aunque nunca haya creado una máquina virtual?
En Windows 11, la seguridad basada en virtualización (VBS) está habilitada de forma predeterminada en los dispositivos que cumplen las condiciones —por ejemplo, una instalación limpia en hardware compatible—, y VBS se construye sobre el hipervisor de Windows. Lo mismo ocurre si se usa WSL2 o Windows Sandbox. No es raro que el hipervisor esté en ejecución sin relación con que alguien use máquinas virtuales.
¿Qué es SLAT, y por qué lo exige Hyper-V?
SLAT (Second Level Address Translation) es el mecanismo por el que la CPU traduce las direcciones físicas del invitado en direcciones físicas reales; Intel EPT y AMD RVI son las implementaciones. Sin él el hipervisor tendría que mantener las tablas de traducción en software, lo que no es realista desde el punto de vista del rendimiento, así que el Hyper-V actual lo trata como un requisito duro.
Si activo Hyper-V, ¿VirtualBox y VMware dejarán de funcionar?
Como el hipervisor usa las extensiones de virtualización de la CPU de forma exclusiva, un hipervisor de terceros no puede ejecutarse de la forma tradicional. El VirtualBox y el VMware actuales, sin embargo, tienen un modo que se ejecuta sobre el hipervisor de Windows (mediante Windows Hypervisor Platform), así que las versiones recientes de cada uno pueden coexistir.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.

Contactar
Volver al blog