Las profundidades de la virtualización de Windows (parte 3) — Máquinas virtuales que arrancan en segundos: por qué WSL2, Windows Sandbox y los contenedores son tan ligeros

Una máquina virtual completa es pesada, ¿por qué entonces WSL2 y Windows Sandbox son ligeros? La entrega final de la serie explica la diferencia no solo desde «qué se aísla», sino desde «qué no hay que duplicar».

Cuando se crea una máquina virtual de Windows en el Administrador de Hyper-V, tarda decenas de segundos en arrancar y reserva varios gigabytes de memoria. En el mismo PC, escribir wsl devuelve un intérprete de Linux en unos segundos, y Windows Sandbox abre también un escritorio desechable en unos segundos.¹

El fundamento es, en todos los casos, el hipervisor de Windows que vimos en la parte 1. En la parte 2 confirmamos que ese fundamento puede construir un aislamiento más fuerte que el kernel. Este artículo examina por separado la especialización de WSL2, el uso compartido de Sandbox y los modos de aislamiento de los contenedores.

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

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

Requisitos previos de este artículo

Cómo leer este artículo

1. La conclusión, primero

Una máquina virtual ligera conserva la línea de aislamiento (un kernel dedicado y la frontera del hipervisor) y aligera la «copia de un sistema operativo invitado completo». Sandbox comparte el propio Windows del anfitrión, WSL2 sustituye al invitado por un Linux pequeño y hecho a propósito, y en ambos casos la memoria no es una reserva fija sino que se presta y se toma prestada de forma dinámica con el anfitrión.

La fuente del peso de una máquina virtual completa no es el aislamiento en sí, sino la duplicación. Otra imagen de sistema operativo en disco, otra ración de páginas de un sistema operativo en la RAM, y otro arranque completo cada vez que se inicia. Las máquinas virtuales ligeras cortan esa duplicación con dos políticas: «compartir lo que es seguro compartir» (Sandbox) y «si no se puede compartir, reconstruirlo pequeño» (WSL2).

flowchart TB
    accTitle: Tres tipos de uso compartido que sostienen las máquinas virtuales ligeras
    accDescr: La imagen de sistema operativo que una máquina virtual completa duplicaba se corta compartiendo en Sandbox y encogiendo en WSL2, la memoria que es una asignación fija de forma predeterminada (las configuraciones de memoria dinámica son la excepción) se convierte en un préstamo dinámico con el anfitrión, y el arranque se sustituye por un kernel ligero y una configuración mínima, de modo que solo permanece la frontera de aislamiento
    heavy["La fuente del peso de una máquina virtual completa es la duplicación"] --> d1["Disco: una imagen de sistema operativo duplicada"]
    heavy --> d2["Memoria: asignación fija de forma predeterminada"]
    heavy --> d3["Arranque: otro arranque completo"]
    d1 -->|sustituido por| s1["Uso compartido (Sandbox) o encogimiento (WSL2)"]
    d2 -->|sustituido por| s2["Préstamo dinámico con el anfitrión"]
    d3 -->|sustituido por| s3["Acortado por un kernel ligero y una configuración mínima"]

Figura 1: Dejaron de duplicar, no de aislar, y ese es el esqueleto de la respuesta a «el mismo hipervisor, y sin embargo ligero».

A continuación miramos WSL2, Windows Sandbox y los contenedores en ese orden, y qué duplicación corta cada uno.

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 (19 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

2. Lo que carga una máquina virtual completa

Como base de comparación, esto es lo que carga una máquina virtual tradicional.

• Una imagen de sistema operativo independiente. Guarda cada archivo del sistema operativo invitado dentro de un disco virtual. Aunque el anfitrión ejecute el mismo Windows, no se comparte nada.
• Una asignación de memoria gruesa. Una máquina virtual tradicional asigna memoria del anfitrión a un tamaño estático de forma predeterminada. Hay mecanismos como la memoria dinámica de Hyper-V que hacen crecer y encoger la asignación dentro de un intervalo configurado, pero los medios de ajustarse a los cambios de demanda son limitados.²
• Un arranque completo de propósito general. El firmware, el cargador de arranque y los servicios arrancan en la misma secuencia que en una máquina física.

flowchart TB
    accTitle: Las tres cargas que lleva una máquina virtual completa
    accDescr: Una máquina virtual completa lleva una imagen de sistema operativo independiente, una asignación de memoria que es estática de forma predeterminada y un arranque completo de propósito general, y eso se manifiesta como costes de disco, RAM y tiempo de arranque
    fullvm["Máquina virtual completa"] --> b1["Imagen de sistema operativo independiente"]
    fullvm --> b2["Asignación de memoria estática de forma predeterminada"]
    fullvm --> b3["Arranque completo de propósito general"]
    b1 -.-> c1["Consume disco por el duplicado"]
    b2 -.-> c2["Tiende a retener RAM que no está usando"]
    b3 -.-> c3["Tarda decenas de segundos en arrancar"]

Figura 2: Cada partida del desglose de costes de una máquina virtual completa se paga por la generalidad y la duplicación, no por el aislamiento.

No son defectos; son el precio de la generalidad de poder meter cualquier cosa en el invitado. Para un uso como ejecutar un Linux antiguo junto a Windows Server, esa generalidad es exactamente el valor. Pero cuando la necesidad es «ejecutar ahora mismo el mismo sistema operativo que el anfitrión (o uno fijo), para desarrollo o validación», la mayor parte es peso muerto. Las máquinas virtuales ligeras dejan ese equipaje al estrechar su propósito.

3. WSL2 — Una máquina virtual de utilidad que lleva un kernel hecho a propósito

WSL2 se sigue con más claridad en el orden estructura → dónde viven los archivos → devolver memoria. Usar un kernel de Linux genuino y tratar con rapidez los archivos del lado Windows son dos asuntos distintos.

3.1. Estructura: una máquina virtual gestionada y las distribuciones en su interior

WSL2 es un mecanismo que ejecuta un kernel de Linux genuino dentro de una máquina virtual de utilidad ligera.³ Hay tres puntos.

El kernel es genuino, pero especializado

Es un kernel de Linux que Microsoft construye a partir de la rama Stable, ajustado en tamaño y rendimiento para WSL2. Con el estándar actual, el WSL distribuido por Microsoft Store, el kernel se actualiza junto con el propio paquete de WSL y se aplica con wsl --update (la distribución antigua integrada en Windows lo recibía a través de Windows Update).⁴

Como es un kernel genuino, la compatibilidad de llamadas al sistema es completa, y herramientas como Docker se ejecutan tal cual.

La máquina virtual se queda entre bastidores

WSL gestiona la creación, el arranque y la parada de la máquina virtual; el usuario solo abre un intérprete. No hay pantalla de ajustes de máquina virtual ni espera perceptible de un arranque.⁴

Las distribuciones son contenedores dentro de la máquina virtual

Cada distribución, como Ubuntu o Debian, se ejecuta como un contenedor aislado dentro de una sola máquina virtual gestionada. Comparten el espacio de nombres de red y el kernel, mientras que espacios de nombres como PID, montaje y usuario están separados.³

flowchart TB
    accTitle: Arquitectura de WSL2
    accDescr: El Windows anfitrión y una máquina virtual de utilidad ligera se sientan uno al lado del otro sobre el hipervisor, un kernel de Linux construido por Microsoft se ejecuta dentro de la máquina virtual, y cada distribución se ejecuta como un contenedor aislado en su interior
    hv["Hipervisor"] --> host["Windows anfitrión"]
    hv --> uvm["Máquina virtual de utilidad ligera"]
    uvm --> lk["Kernel de Linux (compilación de Microsoft, actualizado con wsl --update)"]
    lk --> u1["Ubuntu (contenedor)"]
    lk --> u2["Debian (contenedor)"]
    host <-->|"Interoperabilidad (comandos, archivos, red)"| uvm

Figura 3: La respuesta a «¿WSL2 es una máquina virtual?» es «sí, pero una máquina virtual gestionada que permanece fuera de la vista», y aunque se instalen varias distribuciones sigue habiendo una sola máquina virtual.

Esto es lo que ocurre entre bastidores en el momento en que se escribe wsl.

flowchart TB
    accTitle: Desde ejecutar el comando wsl hasta que vuelve un intérprete en unos segundos
    accDescr: Cuando se ejecuta wsl, se arrancan la máquina virtual ligera y el kernel de Linux si la máquina virtual de utilidad aún no está en ejecución, se usa la máquina virtual existente tal cual si ya lo está, y un intérprete vuelve en el contenedor de la distribución
    cmd["Ejecutar wsl"] --> vmq{"¿La máquina virtual de utilidad ya está en ejecución?"}
    vmq -->|No| bootvm["Arrancar la máquina virtual ligera y el kernel de Linux (unos segundos)"]
    vmq -->|Sí| reuse["Usar la máquina virtual en ejecución tal cual"]
    bootvm --> shell["Un intérprete vuelve dentro del contenedor"]
    reuse --> shell

Figura 4: La espera no es más que un arranque mínimo de máquina virtual, y aquí se nota el efecto de haber dejado el equipaje de un arranque completo.

3.2. E/S de archivos: de qué lado viven los archivos lo cambia todo

Dónde se colocan los archivos aparece en toda conversación sobre el rendimiento de WSL2.

• Las operaciones sobre archivos del lado Linux (el disco virtual ext4) son rápidas. El kernel de Linux trata su propio sistema de archivos de forma directa, y se han informado aceleraciones de hasta 20× respecto a WSL1 al extraer tarballs y de 2 a 5× en git clone y npm install.⁴
• Las operaciones sobre archivos del lado Windows (/mnt/c y similares) son más lentas porque pasan por un uso compartido de archivos que cruza la frontera de sistema operativo. El rendimiento entre sistemas de archivos de sistemas operativos es el único punto importante en el que WSL2 queda por detrás de WSL1.⁴

Así que la regla es: coloque los archivos del proyecto en el mismo lado de sistema operativo que las herramientas que los operan.⁴ Un repositorio que tratan las herramientas de compilación de Linux va al lado Linux; una solución que se compila en Visual Studio va al lado Windows.

flowchart TB
    accTitle: La bifurcación de las rutas de E/S de archivos de WSL2
    accDescr: El acceso al disco virtual ext4 del lado Linux es rápido porque el kernel de Linux lo alcanza de forma directa, mientras que el acceso a los archivos del lado Windows es lento porque pasa por un uso compartido de archivos que cruza la frontera de sistema operativo
    io["Operación de archivo dentro de WSL2"] --> place{"¿De qué lado está el archivo?"}
    place -->|"Lado Linux (directorio personal, etc.)"| ext4["E/S directa al disco virtual ext4"]
    place -->|"Lado Windows (/mnt/c, etc.)"| p9["A través de un uso compartido que cruza la frontera de SO"]
    ext4 --> fast["Rápido (hasta 20x respecto a WSL1 en un ejemplo)"]
    p9 --> slow["Tiende a ser lento"]
    slow -.-> fix["Remedio: colocar el archivo en el SO que lo usa"]

Figura 5: Lo que es lento es la ruta, no WSL2, así que a menudo basta con cambiar dónde viven los archivos para que desaparezca el problema de rendimiento.

3.3. Memoria: crece, se encoge, pero no lo devuelve todo

El uso de memoria de WSL2 (visible como el proceso vmmem en el Administrador de tareas) no es una reserva fija; crece y se encoge con el uso.

Devolver la memoria que los procesos han liberado

La memoria que los procesos han liberado se devuelve a Windows de forma automática bajo el ajuste pageReporting, que está habilitado de forma predeterminada.⁵

Recuperar la caché de archivos

Las páginas retenidas como caché de archivos antes no volvían a Windows hasta que se apagaba la máquina virtual.⁴ En el WSL actual, el ajuste experimental autoMemoryReclaim de .wslconfig (valor predeterminado dropCache) también recupera la caché de forma automática.⁵

En entornos donde este ajuste está en disabled, o en WSL antiguo, la caché de una sesión larga puede permanecer hasta que se apaga la máquina virtual y presionar la memoria del anfitrión.

flowchart TB
    accTitle: Cómo la memoria de WSL2 crece, se encoge y se devuelve
    accDescr: La demanda creciente dentro de WSL2 eleva el uso de memoria de la máquina virtual, la memoria liberada por procesos se devuelve a Windows bajo pageReporting que está habilitado de forma predeterminada, la caché de archivos la recupera de forma automática autoMemoryReclaim de forma predeterminada, pero con estos ajustes deshabilitados o en WSL antiguo permanece hasta que se apaga la máquina virtual, y wsl shutdown lo devuelve todo
    grow["La demanda de memoria crece dentro de WSL2"] --> vm["El uso de vmmem crece"]
    vm --> freed{"¿Se ha liberado esa página?"}
    freed -->|"Liberada por un proceso (con pageReporting habilitado)"| ret["Devuelta a Windows de forma automática"]
    freed -->|Retenida como caché de archivos| amr["Recuperada de forma automática por autoMemoryReclaim (predeterminado)"]
    amr -.-> old2["Permanece hasta que se apaga la VM si está deshabilitado o en WSL antiguo"]
    old2 --> sd["wsl --shutdown lo devuelve todo"]

Figura 6: Lo que parece «solo crece» es sobre todo la caché (con pageReporting deshabilitado, también permanece la memoria que liberan los procesos), así que conozca las rutas de devolución antes de llamarlo una fuga.

Fijar un tope de memoria

Si quiere un tope explícito, %UserProfile%\.wslconfig controla la memoria, el número de procesadores y el intercambio de la máquina virtual en conjunto.⁵

# %UserProfile%\.wslconfig
[wsl2]
memory=8GB
processors=4
swap=2GB

Tras cambiar los ajustes, reinicie la máquina virtual con wsl --shutdown para que surtan efecto. Esta asignación dinámica, en la que un ajuste decide el tope y la demanda decide el uso real, la lleva aún más lejos Windows Sandbox, que viene a continuación.

4. Windows Sandbox — Usar el Windows del anfitrión una vez más

La ligereza de Sandbox se descompone en tres partes: compartir archivos de sistema operativo en disco, compartir páginas de sistema operativo en RAM y coordinar la asignación de memoria con el anfitrión.

4.1. Imagen base dinámica: un Windows completo en 500 MB

Windows Sandbox es un escritorio de Windows desechable aislado por el hipervisor. Ciérrelo y todo desaparece; la vez siguiente arranca en unos segundos desde un estado prístino.¹

El primer enigma es el disco. Puede arrancar un Windows completo, y sin embargo la imagen base de Sandbox es de solo unos 500 MB tras la instalación y 30 MB comprimidos para la distribución.² El secreto es la imagen base dinámica.

• La mayoría de los archivos de sistema operativo son inmutables (immutable) y se pueden compartir tal cual desde el anfitrión.
• Solo el pequeño número de archivos mutables (mutable) no se puede compartir, así que se guarda una copia limpia de ellos dentro de la imagen base.
• Al arrancar, los archivos inmutables del anfitrión y las copias locales de los archivos mutables se combinan en una imagen de Windows completa.²

En otras palabras, Sandbox ni descarga ni almacena una copia de Windows; arranca reutilizando el Windows ya instalado en el anfitrión.

flowchart TB
    accTitle: Cómo se ensambla la imagen base dinámica
    accDescr: Los archivos de sistema operativo inmutables del Windows del anfitrión se comparten, solo los archivos mutables se conservan como copia limpia en la imagen base, y ambos se combinan en la imagen de Windows completa de Sandbox
    hostw["El Windows completo del anfitrión"] --> imm["Archivos de SO inmutables (la gran mayoría)"]
    hostw --> mut["Archivos de SO mutables (unos pocos)"]
    imm -->|compartidos tal cual| img["Imagen de arranque de Sandbox"]
    mut -->|copia limpia conservada| img
    img --> boot["Arranca como un Windows completo"]
    img -.-> size["Solo hay que almacenar unos 500 MB"]

Figura 7: No «tener otro Windows», sino «ensamblar uno a partir del Windows del anfitrión» es la forma que toma el abandono de la duplicación en disco.

Precisamente esta composición es lo que hace posible el ciclo de vida siguiente.

Lo que se descarta es el estado local dentro de Sandbox.

Si se asigna una carpeta escribible desde el anfitrión en el archivo de configuración .wsb, los cambios hechos allí permanecen en el lado del anfitrión.⁶

flowchart TB
    accTitle: El ciclo de vida de Windows Sandbox
    accDescr: El arranque prepara un Windows prístino en unos segundos, tras validar aplicaciones o experimentar el cierre descarta todo el estado dentro de Sandbox de modo que el siguiente arranque vuelve a ser prístino, pero los cambios en una carpeta del anfitrión asignada como escribible permanecen
    launch["Arranque (unos segundos)"] --> clean["Un Windows prístino"]
    clean --> work["Validación de aplicaciones o experimentos"]
    work --> close2["Cerrar"]
    close2 --> discard["Descartar todo el estado dentro de Sandbox"]
    discard -.-> mapped["Los cambios en una carpeta escribible asignada permanecen en el anfitrión"]
    discard -->|siguiente arranque| launch

Figura 8: Puede volver a un estado prístino cada vez porque la parte mutable es una copia desechable, y descartarla forma parte del diseño.

4.2. Direct Map: el mismo ntdll.dll es la misma página física

No solo el disco, también se comparte la RAM. Como Sandbox ejecuta la misma imagen de sistema operativo que el anfitrión, se usa una técnica llamada «Direct Map» para que, en el caso de los binarios de sistema operativo, use las mismas páginas de memoria física que el anfitrión. Cuando ntdll.dll se carga en memoria dentro de Sandbox, apunta a las mismas páginas físicas que el mismo binario cargado en el anfitrión.

Esto logra una huella de memoria mucho más pequeña que una máquina virtual tradicional sin exponer los secretos del anfitrión a riesgo.²

«Compartir la misma página física entre varios usuarios» es la misma idea que el uso compartido de DLL mediante objetos de sección, que seguimos en la parte 3 de la serie de memoria («Objetos de sección y copia en escritura»). Aquel mecanismo compartía entre procesos; Sandbox lo hace cruzando la frontera de la máquina virtual.

flowchart TB
    accTitle: Uso compartido de páginas físicas mediante Direct Map
    accDescr: Una aplicación en el anfitrión y una aplicación dentro de Sandbox comparten las mismas páginas de memoria física para binarios de sistema operativo como ntdll, lo que reduce el uso de memoria
    happ["Aplicación en el anfitrión"] --> hva["Dirección virtual del lado del anfitrión"]
    sapp["Aplicación dentro de Sandbox"] --> sva["Dirección virtual del lado de Sandbox"]
    hva --> phys["La misma página física (binarios de SO como ntdll.dll)"]
    sva --> phys
    phys -.-> save["No hace falta duplicar la parte de SO de la RAM"]

Figura 9: Direct Map toma la idea de compartir páginas, usada desde hace tiempo entre procesos, y la aplica cruzando la frontera de la máquina virtual.

4.3. Prestar y tomar prestada memoria: más como un proceso que como una máquina virtual

En contraste con la asignación de memoria estática de una máquina virtual tradicional, la tecnología de contenedores que hay debajo de Sandbox decide la asignación de recursos de forma dinámica, en coordinación con el anfitrión. Si al anfitrión le falta memoria, puede recuperarla del contenedor igual que la recupera de un proceso ordinario.² La memoria dinámica de Hyper-V también hace crecer y encoger la asignación de una máquina virtual dentro de un intervalo configurado, pero Sandbox da un paso más: comparte memoria en el mismo terreno que la propia gestión de memoria del anfitrión.

flowchart TB
    accTitle: Coordinación de memoria entre el anfitrión y Sandbox
    accDescr: Una máquina virtual tradicional reserva un tamaño estático de forma predeterminada con medios de ajuste limitados, mientras que Sandbox se convierte en objetivo de recuperación ante la presión de memoria del anfitrión y comparte memoria en el mismo terreno que los procesos ordinarios
    pressure["Sube la presión de memoria del anfitrión"] --> from{"¿De dónde recuperar?"}
    from --> proc["Los Working Set de los procesos ordinarios"]
    from --> sbx["Lo que está usando Sandbox (el contenedor)"]
    proc --> relief["Se asegura memoria libre"]
    sbx --> relief
    relief -.-> contrast["Una máquina virtual tradicional tiene medios de ajuste limitados"]

Figura 10: En el uso compartido de memoria, Sandbox se sitúa del lado de los procesos y no de las máquinas virtuales, y cede memoria cuando el anfitrión está bajo presión.

En la parte 1 dijimos que el rendimiento de una máquina virtual también depende del lado del anfitrión; con las máquinas virtuales ligeras esto va un paso más allá, y la propia asignación de memoria se convierte en un trabajo conjunto con el anfitrión. Esa coordinación es la razón de que Sandbox se sienta menos como «software de virtualización pesado» y más como una aplicación más.

Los pasos concretos para usar Sandbox en la validación de aplicaciones de negocio se cubren en el artículo anterior «Cómo acelerar la validación de aplicaciones con Windows Sandbox». Este artículo cubre el mecanismo de debajo.

5. Contenedores — Dónde trazar la línea de aislamiento

Aquí no juzgamos la seguridad solo por el nombre «contenedor»; comprobamos si el contenedor comparte el kernel con el anfitrión o tiene un kernel propio.

5.1. Aislamiento de procesos y aislamiento Hyper-V

Los contenedores de Windows tienen dos modos de aislamiento en tiempo de ejecución. La imagen es la misma; el modo se elige con un indicador al arrancar.⁷

• Aislamiento de procesos: varios contenedores comparten el kernel con el anfitrión y se aíslan mediante virtualización por espacio de nombres del sistema de archivos, el registro, los puertos de red, el espacio de identificadores de proceso, el espacio de nombres del Administrador de objetos, y así sucesivamente. Es casi el mismo enfoque que los contenedores de Linux.
• Aislamiento Hyper-V: cada contenedor se ejecuta dentro de una máquina virtual muy optimizada y tiene lo que equivale a un kernel dedicado. La presencia de la máquina virtual pone un aislamiento a nivel de hardware entre los contenedores y entre ellos y el anfitrión.⁷

El aislamiento por espacios de nombres se puede ver como la versión a fondo de la técnica del artículo sobre la virtualización del registro («Redirección y virtualización del registro en Windows»): mostrar una entidad distinta bajo la misma API.

flowchart TB
    accTitle: Aislamiento de procesos frente al aislamiento Hyper-V
    accDescr: Bajo aislamiento de procesos, los contenedores comparten el kernel con el anfitrión y se aíslan por espacios de nombres, mientras que bajo aislamiento Hyper-V cada contenedor tiene un kernel dedicado dentro de una máquina virtual optimizada
    subgraph pi ["Aislamiento de procesos"]
        c1["Contenedor A"] --> sk1["Kernel compartido con el anfitrión"]
        c2["Contenedor B"] --> sk1
    end
    subgraph hi ["Aislamiento Hyper-V"]
        c3["Contenedor C"] --> k3["Kernel dedicado (dentro de una MV optimizada)"]
        c4["Contenedor D"] --> k4["Kernel dedicado (dentro de una MV optimizada)"]
    end
    sk1 ~~~ c3

Figura 11: Incluso con la misma imagen de contenedor, si la línea de aislamiento se traza por encima del kernel o el propio kernel queda separado se elige al arrancar.

5.2. Cuál se puede llamar «frontera de seguridad»

La diferencia entre los dos modos no se queda en el rendimiento. Microsoft no considera los contenedores aislados por proceso una frontera de seguridad robusta. Los contenedores que se mantienen como frontera de seguridad (con corrección de vulnerabilidades) son los aislados por hipervisor, y en escenarios de multiinquilino hostil el modo a elegir es el aislamiento Hyper-V.⁸

El VBS que vimos en la parte 2 también se diseñó sobre la premisa de que «el kernel se puede comprometer», replegándose a la frontera del hipervisor. El mismo criterio vale en el mundo de los contenedores. La línea que encierra código no confiable se traza en la frontera del hipervisor, no dentro de un kernel compartido.

flowchart TB
    accTitle: Elegir el aislamiento según cuánto se puede confiar en el código
    accDescr: Una carga de trabajo de confianza toma densidad y rendimiento con aislamiento de procesos, mientras que el código no confiable o el código de otra persona recibe una frontera de hipervisor como un contenedor aislado por Hyper-V, un Windows Sandbox endurecido con la red y similares deshabilitados, o una máquina virtual aislada
    trust{"¿Se puede confiar en ese código?"} -->|Sí| dens["Aislamiento de procesos (densidad y velocidad primero)"]
    trust -->|"No, o código de otra persona"| bound["Elegir una frontera de hipervisor"]
    bound --> opt1["Contenedor aislado por Hyper-V"]
    bound --> opt2["Sandbox endurecido o MV aislada"]

Figura 12: El modo de aislamiento es un asunto de seguridad antes que de rendimiento, y el grado de confianza decide dónde va la línea.

Nota: dentro de una máquina virtual, comprobar los requisitos de la virtualización anidada

Ejecutar contenedores aislados por Hyper-V dentro de una máquina virtual Hyper-V significa dos capas de hipervisor: virtualización anidada.

Un nivel de anidamiento se admite en producción en entornos que cumplen las condiciones (un anfitrión Windows 10 / Windows Server 2016 o posterior para procesadores Intel, un anfitrión Windows 11 / Windows Server 2022 o posterior para procesadores AMD, más la versión de configuración de máquina virtual correspondiente en cada caso), y además exige el ajuste que expone las extensiones de virtualización a la máquina virtual exterior (ExposeVirtualizationExtensions en Set-VMProcessor para Hyper-V).

Ejecutar WSL2 dentro de una máquina virtual se admite de la misma forma.⁹ Poder usar WSL2 o Docker en una máquina virtual de desarrollo en la nube depende igualmente de si el tamaño y la configuración de esa máquina virtual exponen la virtualización anidada.

flowchart TB
    accTitle: La estructura de la virtualización anidada
    accDescr: Una máquina virtual en la nube se sienta sobre el hipervisor del anfitrión físico, y en su interior se ejecuta otro hipervisor (el anidamiento se admite solo para un nivel) que sostiene WSL2 y los contenedores aislados por Hyper-V
    phys3["Hipervisor del anfitrión físico"] --> cvm["Máquina virtual en la nube (máquina de desarrollo)"]
    cvm --> nhv["Hipervisor dentro de la MV (primer nivel de anidamiento)"]
    nhv --> w2["WSL2"]
    nhv --> hvc["Contenedor aislado por Hyper-V"]
    nhv -.-> limit["El anidamiento se admite solo para un nivel"]

Figura 13: La razón de que wsl se ejecute dentro de una máquina virtual en la nube es que la virtualización anidada se admite oficialmente para exactamente un nivel.

5.3. El espectro de aislamiento y ligereza

Alinear todo lo cubierto hasta aquí en un solo eje da lo siguiente.

flowchart TB
    accTitle: El espectro de fuerza de aislamiento y ligereza
    accDescr: Los contenedores aislados por proceso son los más ligeros pero comparten el kernel, WSL2, Sandbox y los contenedores aislados por Hyper-V son máquinas virtuales ligeras con kernel dedicado (Sandbox aligerada por el uso compartido con el anfitrión, WSL2 por un kernel hecho a propósito), y una máquina virtual completa es la más pesada pero de propósito general
    ax["Ligero ← → Pesado"] ~~~ p1
    p1["Contenedor aislado por proceso (kernel compartido)"] --> p2["WSL2, Sandbox, aislamiento Hyper-V (MV ligeras con kernel dedicado)"]
    p2 --> p3["Máquina virtual completa (ejecuta cualquier cosa, tiene cada duplicado)"]
    p1 -.-> n1["Frontera: espacios de nombres"]
    p2 -.-> n2["Frontera: hipervisor"]
    p3 -.-> n3["Frontera: hipervisor + independencia completa"]

Figura 14: Las máquinas virtuales ligeras son el término medio que conservó la frontera del hipervisor al recortar la duplicación; cómo la recortan difiere, con uso compartido en Sandbox y un kernel hecho a propósito en WSL2.

6. Comprobarlo con sus propios ojos

La ligereza y el uso compartido se pueden observar en su propia máquina.

6.1. Tiempo de arranque de WSL2 y crecimiento y encogimiento de la memoria

Con el Administrador de tareas abierto, pruebe lo siguiente.

# Tiempo de arranque percibido (la primera ejecución arranca la MV; las posteriores son aún más rápidas)
Measure-Command { wsl -e true }

# Uso de memoria de la máquina virtual WSL2 (vmmem / Virtual Machine Memory)
Get-Process -Name vmmem* | Select-Object Name, WorkingSet64

# Apagar toda la máquina virtual y ver cómo vuelve la memoria
wsl --shutdown

Ejecute una compilación grande o una operación de archivos dentro de WSL2 y vmmem crece; wsl --shutdown lo devuelve todo de una vez, y se puede observar.

6.2. Diferencias de velocidad por la colocación de archivos de WSL2

Coloque el mismo repositorio en el lado Linux (~/repo) y en el lado Windows (/mnt/c/repo), compare el tiempo de git status o de una extracción, y la diferencia de la sección 3.2 aparece en números.

6.3. Aumento de memoria del lado del anfitrión al arrancar Sandbox

Arranque Sandbox y observe el aumento de memoria en el Administrador de tareas del anfitrión. Que se quede mucho más pequeño de lo que sugeriría «un segundo Windows completo» es el efecto del uso compartido.

Para profundizar en el desglose de memoria del lado del anfitrión, es una referencia útil el artículo de herramientas Sysinternals que cubre el uso de RAMMap y VMMap («Process Explorer / Handle / VMMap en la práctica»).

Son, no obstante, herramientas para clasificar procesos y memoria física del lado del anfitrión; no observan de forma directa el uso compartido con el propio invitado.

6.4. Diferencias entre los modos de aislamiento de los contenedores de Windows

Si tiene un entorno de contenedores de Windows, arranque la misma imagen con docker run --isolation=process y con --isolation=hyperv, y compare el tiempo de arranque y lo que muestra el Administrador de tareas (bajo aislamiento de procesos, los procesos del contenedor aparecen en la lista de procesos del anfitrión) para hacerse una idea de dónde se sitúa la línea de aislamiento.⁷

El aislamiento de procesos, sin embargo, exige que coincidan las versiones del anfitrión y de la imagen, y en un sistema operativo cliente se limita al uso de desarrollo y prueba. El aislamiento Hyper-V admite una gama más amplia de combinaciones, así que haga la comparación con un par compatible.¹⁰

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

7.1. «WSL2 es lento»

Lo que es lento no es WSL2, sino la ruta de E/S de archivos que cruza la frontera de sistema operativo. En muchos casos, simplemente mover el proyecto al lado Linux transforma la experiencia.⁴ A la inversa, colocar en el lado Linux archivos que tocan las herramientas de Windows es una desventaja por la misma razón. Decida por «ponerlo en el mismo sistema operativo que lo que lo usa».

7.2. «Que vmmem se agrande es una fuga de memoria»

La memoria de WSL2 crece y se encoge con la demanda, y la memoria liberada se devuelve. En el WSL actual, autoMemoryReclaim (valor predeterminado dropCache) también recupera la caché de archivos de forma automática, así que «se quedó grande» suele resolverse solo con el tiempo.⁵

Si aun así permanece, compruebe que autoMemoryReclaim no está en disabled y que pageReporting, que devuelve la memoria liberada, no se ha desactivado (y que no está en un WSL más antiguo); luego fije un tope explícito con memory en .wslconfig o devuelva todo con wsl --shutdown al final de una sesión.

El enfoque para decidir si es una fuga es el mismo que en la introducción de la serie de memoria, «¿Qué representa realmente el «uso de memoria» de Windows?».

7.3. «Está en un contenedor, así que es seguro»

Los contenedores aislados por proceso comparten el kernel, y según el criterio de Microsoft no son una frontera de seguridad.⁸ Para ejecutar código no confiable o muestras, elija un aislamiento que tenga frontera de hipervisor: un contenedor aislado por Hyper-V, Windows Sandbox o una máquina virtual dedicada.

Una frontera de hipervisor, sin embargo, no es un salvoconducto universal.

Los ajustes predeterminados de Windows Sandbox tienen la conexión de red habilitada, lo que puede exponer una aplicación no confiable a su red interna.¹ Si lo usa para ejecutar muestras, o bien refuerce el aislamiento deshabilitando la red y la redirección del portapapeles en el archivo de configuración .wsb, o bien use una máquina virtual dedicada en una red aislada.

8. Resumen — Cierre de la serie

Los puntos clave de la parte 3.

• La ligereza de las máquinas virtuales ligeras es el resultado de «dejar de duplicar», no de «debilitar el aislamiento».
• WSL2 ejecuta un kernel de Linux genuino en una máquina virtual de utilidad ligera gestionada, y las distribuciones se aíslan como contenedores dentro de esa máquina virtual.³ La regla de rendimiento es colocar los archivos en el sistema operativo que los usa; la memoria crece y se encoge de forma dinámica, y .wslconfig controla el tope.⁴⁵
• Windows Sandbox comparte los archivos de sistema operativo inmutables del anfitrión mediante la imagen base dinámica y las páginas físicas de los binarios de sistema operativo aplicables mediante Direct Map, de modo que no guarda ninguna copia de un Windows completo.² Los unos 500 MB de archivos mutables y la memoria de las aplicaciones que se ejecutan dentro siguen haciendo falta por separado.
• El modo de aislamiento de los contenedores se elige al arrancar, y el lado que se puede llamar frontera de seguridad es el aislamiento Hyper-V.⁷⁸

Y poner toda la serie en una página da esto.

• Parte 1: debajo de Windows hay una capa de hipervisor, y el propio sistema operativo anfitrión se ejecuta como partición raíz. Esa capa arbitra de forma directa la CPU y la memoria (SLAT), y la E/S de los dispositivos sintéticos la media la partición raíz (VSP) al otro lado de VMBus.
• Parte 2: esa capa se usa no solo para aislar las máquinas virtuales entre sí, sino también para trazar dentro del mismo sistema operativo una frontera más fuerte que el kernel (VTL). La seguridad predeterminada de Windows 11 se construye encima.
• Parte 3: sobre la misma capa, recortar la duplicación es lo que hace posible «una máquina virtual que arranca en segundos». La línea de aislamiento se conserva, y se ha convertido en una herramienta cotidiana.

flowchart TB
    accTitle: Toda la serie en una imagen
    accDescr: El hipervisor directamente sobre el hardware es la parte 1, la separación de VTL0 y VTL1 dentro del Windows anfitrión es la parte 2, y la ligereza de WSL2, Sandbox y el aislamiento Hyper-V sobre la misma capa es la parte 3, con los contenedores aislados por proceso compartiendo el kernel del anfitrión, Sandbox aligerada por el uso compartido y WSL2 por un kernel hecho a propósito
    hw3["Hardware"] --> hv3["Hipervisor (parte 1)"]
    hv3 --> rp3["Windows anfitrión (la separación VTL es la parte 2)"]
    hv3 --> lw3["WSL2, Sandbox, aislamiento Hyper-V (parte 3)"]
    rp3 --> pc3["Contenedor aislado por proceso (kernel compartido)"]
    lw3 -.-> mech3["Sandbox se aligera por el uso compartido, WSL2 por un kernel hecho a propósito"]

Figura 15: Apile las tres partes y tiene el panorama de conjunto de lo que hay debajo del Windows de hoy.

La virtualización ya no es una técnica de sala de servidores, ni una técnica solo para quienes levantan máquinas virtuales. Debajo de su Windows, sostiene en silencio tanto la seguridad como la experiencia de desarrollo. Ahí es donde estamos.

Artículos relacionados

• Las profundidades de la virtualización de Windows (parte 1) — ¿Dónde se ejecuta realmente su Windows? El hipervisor y las particiones
• Las profundidades de la virtualización de Windows (parte 2) — Memoria que ni el kernel puede ver: cómo funcionan VBS, HVCI y Credential Guard
• Las entrañas de la memoria de Windows (parte 3) — Objetos de sección y copia en escritura
• Cómo acelerar la validación de aplicaciones con Windows Sandbox
• Redirección y virtualización del registro en Windows

Áreas de consultoría relacionadas

En KomuraSoft LLC nos encargamos de poner en marcha entornos de desarrollo que usan WSL2 y contenedores, de diseñar entornos de validación para aplicaciones Windows y de investigar el rendimiento y la compatibilidad en entornos virtualizados.

• Desarrollo de aplicaciones Windows
• Investigación de fallos y análisis de causas
• Aprovechamiento de activos existentes y soporte de 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.

¿WSL2 es una máquina virtual?

Sí. WSL2 ejecuta un kernel de Linux genuino construido por Microsoft dentro de una máquina virtual de utilidad ligera. WSL gestiona la máquina virtual entre bastidores, de modo que el diseño nunca hace que el usuario piense en ajustes de máquina virtual ni en esperar un arranque. Cada distribución de Linux se ejecuta como un contenedor aislado dentro de esta máquina virtual gestionada.

¿Por qué las operaciones de archivo bajo /mnt/c son lentas en WSL2?

Porque el acceso desde el kernel de Linux de WSL2 al sistema de archivos del lado Windows pasa por un uso compartido de archivos que cruza la frontera de sistema operativo. Las operaciones sobre el sistema de archivos de Linux (un disco virtual ext4) son rápidas, así que la regla es mantener los archivos del proyecto en el mismo lado de sistema operativo que las herramientas que trabajan con ellos.

¿Un uso grande de memoria del proceso vmmem es una fuga?

En la mayoría de los casos no. La memoria de WSL2 crece y se encoge con el uso, y la memoria que los procesos han liberado se devuelve a Windows bajo el ajuste pageReporting, que está habilitado de forma predeterminada. La caché de archivos, también, la recupera automáticamente el WSL actual mediante autoMemoryReclaim en .wslconfig (el valor predeterminado es dropCache). En entornos donde estos ajustes se han deshabilitado, o en WSL antiguo, la memoria puede permanecer hasta que se apaga la máquina virtual; en ese caso fije un tope con el ajuste memory, o devuélvala con wsl --shutdown.

¿Cómo puede Windows Sandbox arrancar un Windows completo desde unos pocos cientos de megabytes de disco?

Mediante un mecanismo llamado imagen base dinámica. Comparte los archivos inmutables del sistema operativo del Windows ya instalado en el anfitrión y mantiene una copia limpia solo del pequeño número de archivos mutables. Así ensambla una imagen completa y arrancable sin almacenar una copia completa de Windows.

¿Los contenedores son más seguros que las máquinas virtuales?

Depende del modo de aislamiento. Los contenedores aislados por proceso comparten el kernel con el anfitrión, y Microsoft no considera esto una frontera de seguridad robusta. Cuando se maneja código adversario, hay que elegir el aislamiento Hyper-V, que da a cada contenedor un kernel dedicado.

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.