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

Nunca ha creado una sola máquina virtual, y sin embargo Información del sistema (msinfo32) en Windows 11 muestra «Seguridad basada en virtualización: En ejecución». ¿Qué significa esa indicación?

En ese PC, el propio Windows anfitrión ya se ejecuta sobre un hipervisor. En Windows 11, VBS está habilitada de forma predeterminada en las configuraciones que cumplen las condiciones, por ejemplo una instalación limpia en hardware compatible, y esa base se usa aunque nunca se cree una máquina virtual.¹ WSL2 y Windows Sandbox usan el mismo hipervisor de Windows.

La parte 1 explica dónde termina ejecutándose el Windows anfitrión cuando se activa Hyper-V, a través de la división de papeles entre la CPU, la memoria y la E/S de dispositivos. Es la entrega que primero endereza la idea de «software de máquinas virtuales sentado encima de Windows».

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

Miramos el mismo hipervisor de Windows en el orden base → aislamiento de seguridad → aplicación a máquinas virtuales ligeras.

Requisitos previos de este artículo

Cómo leer este artículo

El mapa de conocimiento que sigue es una lista de relaciones. Si es la primera lectura, siga el texto desde la sección 1, el panorama.

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (22 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

1. Primero la conclusión

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.² El Windows anfitrión entra en la partición raíz; las máquinas virtuales entran en 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.

flowchart TB
    accTitle: Estructura general tras activar Hyper-V
    accDescr: El 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 virtuales
    hw["Hardware físico"] --> hv["Hipervisor"]
    hv --> root["Partición raíz (Windows anfitrión)"]
    hv --> child1["Particiones hijas (máquinas virtuales)"]
    root -.-> stack["Tiene la pila de administración de la virtualización y los controladores"]

Figura 1: Hyper-V no es «software de máquinas virtuales 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 antes y 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

En la discusión de la CPU distinguimos los anillos que separan el kernel de las aplicaciones de los modos de ejecución que separan el hipervisor de los invitados. La pregunta de esta sección es: el kernel invitado también se ejecuta en el anillo 0, ¿por qué no hay colisión?

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.

flowchart TB
    accTitle: El problema de varios kernels de SO que exigen el anillo 0
    accDescr: Tanto 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ísica
    k1["Kernel anfitrión (asume anillo 0)"] --> want["Exige el control de la CPU física"]
    k2["Kernel invitado (asume anillo 0)"] --> want
    want --> conflict["Los anillos tradicionales por sí solos no lo concilian"]
    conflict --> need["Hace 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.² 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.²

flowchart TB
    accTitle: El flujo de la ejecución del invitado y el VM Exit
    accDescr: El 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 operaciones configuradas como interceptación y las excepciones provocan un VM Exit que transfiere el control al hipervisor, que luego vuelve al invitado mediante VM Entry
    guest["Ejecución en modo invitado (incluye un kernel anillo 0)"] --> op{"¿Operación que necesita intervención? (interceptaciones/excepciones configuradas)"}
    op -->|No| cont["Seguir ejecutando tal cual"]
    op -->|Sí| exitEv["VM Exit (la CPU transfiere el control)"]
    exitEv --> hvp["El hipervisor lo gestiona"]
    hvp --> entry["Volver al invitado mediante VM Entry"]
    entry --> guest

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.³ 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.

flowchart TB
    accTitle: La diferencia entre hipervisores de tipo 1 y tipo 2
    accDescr: En 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 encima
    subgraph t2 ["Tipo 2 (hospedado)"]
        hw2["Hardware"] --> hostos["SO anfitrión"]
        hostos --> hv2["Hipervisor"]
        hv2 --> vm2["Máquina virtual"]
    end
    subgraph t1 ["Tipo 1 (Hyper-V)"]
        hw1["Hardware"] --> hv1["Hipervisor"]
        hv1 --> root1["Partición raíz (SO anfitrión)"]
        hv1 --> vm1["Máquina virtual"]
    end
    vm2 ~~~ hw1

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 sobre la capa un peldaño por debajo.

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

flowchart TB
    accTitle: Orden de arranque tras activar Hyper-V
    accDescr: Tras encender, el hipervisor arranca primero durante el arranque, el Windows anfitrión sube después como partición raíz encima, y las máquinas virtuales, VBS y similares arrancan a continuación
    poweron["Encendido e inicio del arranque"] --> bhv["El hipervisor arranca primero"]
    bhv --> broot["El Windows anfitrión arranca como partición raíz"]
    broot --> blater["Máquinas virtuales, VBS, WSL2, etc. arrancan encima"]
    broot -.-> feel["La experiencia del usuario no cambia"]

Figura 5: La inversión del orden ya ha terminado 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

Miremos de cerca las particiones, las «cajas» del panorama. Lo que queremos separar aquí es la mediación de CPU y memoria, que el hipervisor asume de forma directa, de la E/S de dispositivos, que la partición raíz media normalmente.

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

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

Acceso directo a 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 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 (no está disponible en Windows de cliente).⁴

La pila de administración de la virtualización

VMMS (Virtual Machine Management Service), que rige la creación, el arranque y la detención de máquinas virtuales, y el proceso de trabajo que arranca por cada máquina virtual (vmwp.exe) se ejecutan en modo usuario en la partición raíz.⁵ 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 el hipervisor está en ejecución por VBS o WSL2.

El derecho a crear particiones hijas

La partición raíz crea particiones hijas a través de la API de hiperllamadas (la interfaz de llamada hacia el hipervisor).²

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 defectos 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.

flowchart TB
    accTitle: División de papeles entre la partición raíz y las particiones hijas
    accDescr: La 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 hiperllamadas; una partición hija ve solo dispositivos virtuales en la configuración habitual, y bajo Discrete Device Assignment en Windows Server accede de forma directa al dispositivo asignado
    subgraph rootp ["Partición raíz"]
        vmms["VMMS y procesos de trabajo"]
        drv["Controladores de dispositivo físicos"]
    end
    subgraph childp ["Partición hija"]
        gos["SO invitado"]
        vdev["En la configuración habitual, solo son visibles los dispositivos virtuales"]
    end
    vmms -->|Crear y administrar mediante hiperllamadas| childp
    hv2["Hipervisor (se limita a mediar CPU y memoria)"] --- rootp
    hv2 --- childp

Figura 6: Poner los controladores de dispositivo y la pila de administración del lado de la partición raíz es lo que mantiene delgado el 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 la sección anterior). Lo que puede ver son procesadores virtuales, un espacio de memoria que parece propio y dispositivos virtuales. Las solicitudes a dispositivos virtuales se reenvían a la partición raíz a través de VMBus o del hipervisor.²

La asignación de tiempo de CPU y la traducción de memoria mediante SLAT, en cambio, las asume 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.

flowchart TB
    accTitle: El mundo visto desde una partición hija
    accDescr: Lo que ve el sistema operativo invitado son procesadores virtuales, un espacio de memoria privado de la partición y dispositivos virtuales; las solicitudes a dispositivos virtuales se reenvían a la partición raíz a través de VMBus y similares, el tiempo de CPU y la traducción de memoria las asume 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 asignados
    gos2["SO invitado en la partición hija"] --> vcpu["Procesadores virtuales"]
    gos2 --> gpa2["Espacio de memoria privado"]
    gos2 --> vdev2["Dispositivos virtuales"]
    vdev2 -->|"A través de VMBus y similares"| rootx["Reenviado a la partición raíz"]
    gos2 -.->|No visible de forma directa| phys2["CPU físicas, RAM y dispositivos reales"]
    phys2 -.-> dda2["En una configuración DDA (Windows Server), solo se accede de forma directa a los dispositivos asignados"]
    vcpu ~~~ phys2

Figura 7: En la configuración habitual de dispositivos virtuales, todo lo que ve el invitado es una ventana virtual y el camino hacia 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 Win32 y el tratamiento de fallos de página los sigue procesando el kernel de Windows de dentro de la partición raíz, como hasta ahora. El hipervisor interviene solo cuando se da con una interceptación configurada o una excepción.

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

Con la memoria separamos la dirección que el invitado considera «física» de la ubicación real en RAM. Tenga presente el orden GVA → GPA → SPA y quién gestiona cada traducción.

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.

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.² Mapear GPA sobre la ubicación real en RAM (SPA) es el trabajo del hipervisor.

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

Si esta traducción de segundo nivel se hiciera solo en software, el hipervisor tendría 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. Por eso 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.⁴

flowchart TB
    accTitle: Traducción de direcciones de dos niveles mediante SLAT
    accDescr: Una dirección virtual del invitado se traduce a una dirección física del invitado por la tabla de páginas del SO invitado, luego se traduce de nuevo a una dirección física del sistema por SLAT, que gestiona el hipervisor, y llega a la RAM real
    gva["Dirección virtual del invitado (GVA)"] -->|Tabla de páginas del SO invitado| gpa["Dirección física del invitado (GPA)"]
    gpa -->|"SLAT (tablas de traducción EPT/RVI)"| spa["Dirección física del sistema (SPA)"]
    spa --> ram["RAM física"]
    gpa -.-> note["Una capa que el invitado tan 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 las máquinas virtuales. La 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 de un límite de seguridad. La razón por la que se puede crear memoria que ni el kernel puede ver es que el hipervisor tiene esta traducción de segundo nivel. Este es un hilo conductor de toda la serie, así que recuerde un solo punto: «el gestor de las tablas de traducción es el hipervisor».

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

La E/S de dispositivos toma un camino distinto del tiempo de CPU y de la traducción de memoria. Comparamos el método que imita hardware real con el método que usa un camino dedicado a la virtualización.

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 en software hardware real (un controlador IDE antiguo, por ejemplo). La compatibilidad es alta porque los controladores incluidos del sistema operativo invitado funcionan tal cual, pero se produce un VM Exit cada vez que el invitado golpea un puerto de E/S, y el rendimiento no escala.

flowchart TB
    accTitle: Por qué la E/S a un dispositivo emulado es lenta
    accDescr: Cada vez que el invitado opera un puerto de E/S, el control pasa al lado del hipervisor mediante un VM Exit, el dispositivo se imita en software y el control vuelve al invitado, así que el ida y vuelta se repite y es lento
    gio["El invitado opera un puerto de E/S"] --> vex["Se produce un VM Exit"]
    vex --> emu2["El dispositivo se imita en software"]
    emu2 --> back["Volver al invitado mediante VM Entry"]
    back -->|Se repite en la siguiente operación de puerto| gio

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 pensado para la virtualización

Por eso Hyper-V tiene un mecanismo de «dispositivo sintético» diseñado bajo el supuesto de la virtualización. Hay tres actores.²

• VMBus: un canal de comunicación lógico entre particiones. Proporciona comunicación entre particiones de alta velocidad que usa memoria compartida.³
• VSP (Virtualization Service Provider): un servicio que reside del lado de la partición raíz, recibe las solicitudes de dispositivo de la hija y las tiende hacia la pila de dispositivo/backend del lado raíz. Una solicitud puede llegar a un dispositivo físico, o puede ser tratada por 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 las solicitudes al VSP a través de VMBus.

Ejemplo: Cómo el WriteFile de un invitado llega al anfitrión

Una solicitud de almacenamiento del sistema operativo invitado fluye en el siguiente orden.

1. El WriteFile de la aplicación invitada desciende por la pila de E/S del kernel invitado.
2. En el fondo, llega al VSC en lugar de al hardware real.
3. El VSC pone la solicitud en VMBus y se la entrega al VSP de la partición raíz.
4. El VSP hace fluir la solicitud hacia la pila de E/S del lado raíz. En una configuración de disco virtual (VHDX), se trata como una escritura al 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 aumenta la eficiencia al eludir la capa de emulación de dispositivos.²

flowchart TB
    accTitle: Camino de E/S de un dispositivo sintético
    accDescr: Una solicitud de E/S de una aplicación en 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 que el VSP tiende puede llegar a un dispositivo real a través de un controlador de dispositivo físico, o ser tratada por un backend del lado anfitrión como un disco virtual o un conmutador virtual
    app["Aplicación en la partición hija"] --> gk["Pila de E/S del kernel invitado"]
    gk --> vsc["VSC (controlador de dispositivo sintético)"]
    vsc -->|VMBus| vsp["VSP (lado de la partición raíz)"]
    vsp --> rio["Pila de E/S del lado raíz"]
    rio --> pdrv["Controlador de dispositivo físico"]
    rio --> hb["Backend del lado anfitrión (disco virtual, conmutador virtual, etc.)"]
    pdrv --> dev["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.

En otras palabras, si la E/S de disco o la red de una máquina virtual es rápida no depende 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 por la que la observación del lado anfitrión es indispensable al investigar un problema de rendimiento de una máquina virtual es que el camino pasa de hecho por el anfitrión.

flowchart TB
    accTitle: Dispositivos emulados frente a dispositivos sintéticos
    accDescr: Un dispositivo emulado imita hardware real para que funcionen los controladores incluidos del invitado, pero es lento; un dispositivo sintético es un controlador de propósito específico que asume VMBus y es rápido
    dev2{"Dispositivo mostrado a la partición hija"} --> emu["Dispositivo emulado"]
    dev2 --> syn["Dispositivo sintético"]
    emu -.-> emuP["Imita hardware real; compatibilidad primero"]
    emuP -.-> emuC["Necesita intervención en cada E/S; lento"]
    syn -.-> synP["Diseñado en torno a VMBus; rápido"]
    synP -.-> synC["Exige un controlador coincidente en el invitado"]

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

6. Por qué esto no es asunto de otros, aunque nunca se use una máquina virtual

6.1. VBS, WSL2 y Sandbox usan la misma base

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.¹ Los detalles están en la parte 2.
• WSL2. Ejecuta un kernel Linux real dentro de una máquina virtual de utilidad ligera.⁶
• Windows Sandbox. Un entorno Windows desechable aislado por el hipervisor.⁷ Ambos se cubren en la parte 3.

flowchart TB
    accTitle: Funciones cotidianas que se asientan sobre el mismo hipervisor
    accDescr: No solo las máquinas virtuales de Hyper-V, sino también VBS, que está habilitada de forma predeterminada en dispositivos que cumplen condiciones como una instalación limpia, más WSL2 y Windows Sandbox, se construyen todos sobre el mismo hipervisor de Windows
    base["Hipervisor de Windows"] --> f1["Máquinas virtuales de Hyper-V"]
    base --> f2["VBS (habilitada de forma predeterminada en instalaciones limpias y similares)"]
    base --> f3["WSL2"]
    base --> f4["Windows Sandbox"]
    f2 -.-> daily["Por qué se ejecuta incluso en PC que nunca usan una máquina virtual"]

Figura 12: Hay una sola base, y en este diagrama se cae el supuesto de que «la virtualización es una historia para quienes usan máquinas virtuales».

6.2. Coexistencia con software de virtualización de terceros

Otra cosa con la que se tropieza 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 por sí 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 sentándose encima del hipervisor de Windows.⁸ 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 a veces se observan como «después de activar Hyper-V (o VBS), el software de virtualización empezó a comportarse de otra forma».

flowchart TB
    accTitle: Quién posee las extensiones de virtualización de la CPU, y el camino para el software de virtualización de terceros
    accDescr: Mientras 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 a través de Windows Hypervisor Platform, mientras que las implementaciones que no admiten WHP no pueden ejecutarse o quedan limitadas
    vt["Extensiones de virtualización de la CPU (VT-x/AMD-V)"] --> hvon{"¿Está en ejecución el hipervisor de Windows?"}
    hvon -->|No| direct["El software de terceros puede usarlas de forma directa"]
    hvon -->|Sí| own["El hipervisor tiene el uso exclusivo"]
    own --> whp["Windows Hypervisor Platform"]
    whp --> third["El software de terceros compatible con WHP se ejecuta encima"]
    third -.-> nowhp["Las implementaciones no compatibles no pueden ejecutarse, 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 comprobar en su propio PC si hay un hipervisor en ejecución.

7.1. Comprobar el hipervisor y VBS con PowerShell

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

# Si se está ejecutando sobre un hipervisor
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent

# Estado de VBS (misma fuente que «Seguridad basada en virtualización» en 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»).⁹

Una precaución. Todo lo que dice HypervisorPresent es «si se está ejecutando 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.

7.2. Distinguir «en ejecución» de «requisitos previos» en systeminfo

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

systeminfo

Mire «Requisitos de Hyper-V» al final de la salida. En una máquina donde el hipervisor aún no está en ejecución, los requisitos individuales, como la compatibilidad con SLAT y si las extensiones de virtualización están habilitadas, se listan uno a uno. En una máquina donde el hipervisor ya está en ejecución, en lugar de los requisitos aparece una sola línea: «Se ha detectado un hipervisor. No se mostrarán las características requeridas para Hyper-V.»⁴

Esa sola línea es por tanto una declaración de que su Windows se ejecuta sobre algún hipervisor. Como con HypervisorPresent, hay que leerla 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 «Sí», eso solo significa que el lado del hardware está listo. La característica Hyper-V en sí está disponible en las ediciones Pro, Enterprise y Education, y no está en Home.¹⁰

7.3. Al comprobar en pantalla, distinga qué elemento está comprobando

En la interfaz gráfica, compruebe la fila «Seguridad basada en virtualización» en «Resumen del sistema» de 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, lo cual es información distinta de si un hipervisor está en ejecución.

flowchart TB
    accTitle: Cómo comprobar si el hipervisor está en ejecución
    accDescr: Si 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 de requisitos de Hyper-V, aún no está en ejecución, así que se comprueba cada requisito como SLAT, las extensiones del modo de supervisión de máquina virtual y DEP, pero todo Sí solo significa que el lado del hardware está listo y la característica Hyper-V también tiene un requisito de edición
    start2["Ejecutar systeminfo"] --> q1{"¿Qué muestra el campo Requisitos de Hyper-V?"}
    q1 -->|Se ha detectado un hipervisor| running["El hipervisor está en ejecución (dentro de la raíz en un PC físico)"]
    q1 -->|Se listan los requisitos| notyet["El hipervisor aún no está en ejecución"]
    notyet --> q2{"¿Todos los requisitos en Sí?"}
    q2 -->|Todos en Sí| can["El lado del hardware está listo"]
    can -.-> ed["Hyper-V también necesita Pro/Enterprise/Education"]
    q2 -->|Algunos No| uefi["Comprobar los elementos correspondientes en UEFI/BIOS y similares"]

Figura 14: El campo «Requisitos de Hyper-V» 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 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 característica 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 investigue 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 característica está habilitada.

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 «Se ha detectado un hipervisor» 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.

flowchart TB
    accTitle: Tres comprobaciones fáciles de confundir
    accDescr: El 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 muestra el estado de ejecución; cada uno responde a una pregunta distinta
    q3{"¿Qué quiere saber?"} --> a3["¿Están habilitadas las extensiones de virtualización en el firmware?"]
    q3 --> b3["¿Se ha instalado la característica Hyper-V?"]
    q3 --> c3["¿Está el hipervisor en ejecución ahora mismo?"]
    a3 -.-> a3t["El panel de CPU del Administrador de tareas"]
    b3 -.-> b3t["El cuadro de diálogo Características de Windows"]
    c3 -.-> c3t["systeminfo y HypervisorPresent"]

Figura 15: Son tres preguntas independientes, e inferir las otras dos a partir de una sola 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 dispositivos sintéticos 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 las máquinas virtuales es observar desde ambos lados: el invitado y el anfitrión (la partición raíz).

9. Resumen

• Al activar Hyper-V, el hipervisor se ejecuta directamente sobre el hardware y el Windows anfitrión se ejecuta como partición raíz.²
• El kernel del sistema operativo invitado sigue ejecutándose en el anillo 0, y solo las operaciones configuradas como interceptación, 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 hiperllamadas.²
• La memoria se convierte en una traducción de dos niveles GVA→GPA→SPA, y el segundo nivel lo asume en hardware SLAT (EPT/RVI). El Hyper-V actual exige SLAT.⁴
• La E/S de dispositivos está dominada por 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.²
• 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.¹ El estado de ejecución se puede comprobar con HypervisorPresent y systeminfo.

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

flowchart TB
    accTitle: El panorama de la parte 1
    accDescr: El 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 se media con una traducción SLAT de dos niveles, la E/S de dispositivos sintéticos se reenvía por VMBus y la trata el VSP de la partición raíz, y los dispositivos emulados y Discrete Device Assignment tienen otros caminos
    up["Partición raíz y particiones hijas"] --> hvS["Hipervisor"]
    hvS --> cpuS["CPU: asigna procesadores virtuales"]
    hvS --> memS["Memoria: traducción de dos niveles mediante SLAT"]
    hvS --> devS["Dispositivos: E/S sintética reenviada por VMBus"]
    cpuS -.-> cpuN["VM Exit solo en la intervención"]
    devS --> vspS["Lo trata el VSP del lado raíz"]
    devS -.-> devN["Los dispositivos emulados y DDA toman otros caminos"]

Figura 16: La programación de la CPU y la traducción de memoria las asume 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».

Retomamos 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

• Interioridades de la memoria de Windows (1.ª parte) — El instante en que una dirección virtual se convierte en RAM física: el ciclo completo de un fallo de página
• ¿Qué representa realmente el «uso de memoria» de Windows? — Cómo interpretar correctamente Working Set, Private Bytes, Commit y el archivo de paginación
• Cómo acelerar la validación de aplicaciones con Windows Sandbox
• Configuración de la programación del procesador en Windows — Servicios en segundo plano y núcleos P/E

Áreas de consultoría relacionadas

KomuraSoft LLC se ocupa 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.

• Desarrollo de aplicaciones Windows
• Investigación de defectos y análisis de causas
• Aprovechamiento de activos existentes y apoyo a la migración
• Contacto

Referencias

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 el dominio 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 «Se ha detectado un hipervisor» en systeminfo, o compruebe HypervisorPresent en Win32_ComputerSystem.

¿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 con independencia de 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 ya 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.