KomuraSoft LLC
Contáctenos
Menú

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

· · Windows, Virtualización, WSL2, Windows Sandbox, Contenedores, Hyper-V

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

Ambos se apoyan en el mismo hipervisor de Windows (parte 1, «¿Dónde se ejecuta realmente su Windows?»). En la parte 2 vimos que este fundamento puede crear un aislamiento más fuerte que el kernel. Entonces, ¿por qué uno es pesado y el otro ligero?

La pregunta que responde la entrega final de la serie es solo una.

Las máquinas virtuales completas son pesadas: ¿por qué WSL2 y Windows Sandbox son tan ligeros?

Los lectores previstos son desarrolladores y operadores que usan WSL2, Windows Sandbox y los contenedores de Windows para desarrollo y validación, y quieren entender su ligereza y sus restricciones desde los mecanismos. Los requisitos previos son Windows 10/11; recorrer el apartado de Windows Sandbox exige una edición Pro, Enterprise o Education (Home y Windows Server no tienen esta función). El conocimiento de fondo es la noción de particiones de la parte 1. La dificultad es intermedia.

1. Conclusión principal

Una máquina virtual ligera conserva la línea de aislamiento (un kernel dedicado y una frontera de 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).

Tres tipos de uso compartido que sostienen las máquinas virtuales ligerasLa imagen de sistema operativo que una máquina virtual completa solía duplicar se corta compartiendo en Sandbox y encogiendo en WSL2; la memoria que es una asignación fija de forma predeterminada (la memoria dinámica es la excepción) se convierte en un préstamo dinámico con el anfitrión; el arranque se sustituye por un kernel ligero y una configuración mínima; solo permanece la frontera de aislamientosustituido porsustituido porsustituido porMV completa: duplicaciónDisco: copia de imagen de SO¿Memoria o arranque?Memoria: fija de forma predeterminadaArranque: arranque completoCompartir（Sandbox）o encoger（WSL2）Préstamo dinámico del anfitriónKernel ligero + mín.

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

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

2. Qué carga una máquina virtual completa

Como línea de base para la comparación, esto es lo que carga una máquina virtual tradicional.

  • Una imagen de sistema operativo independiente. Tiene cada archivo del sistema operativo invitado dentro de un disco virtual. Aunque el anfitrión tenga el mismo Windows, no lo comparte.
  • Asignación de memoria gruesa. El valor predeterminado de una máquina virtual tradicional es asignar memoria del anfitrión con un tamaño estático. Mecanismos como Hyper-V Dynamic Memory pueden crecer y encoger la asignación dentro de un rango configurado, pero los medios de ajustarse a los cambios de demanda son limitados.2
  • Un arranque completo de propósito general. El firmware, el cargador de arranque y el conjunto de servicios arrancan en la misma secuencia que en una máquina física.
Las tres cargas que lleva una máquina virtual completaUna 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 en disco, RAM y tiempo de arranqueMV completaImagen de SO independiente¿Memoria o arranque?Memoria estática de forma predeterminadaArranque de propósito generalDisco extra para una copiaTambién retiene RAM no usadaTarda decenas de segundos

Figura 2: El desglose del coste de una máquina virtual completa se paga no por el aislamiento sino por la generalidad y la duplicación.

Estos no son defectos; son el precio de la generalidad de que «se puede meter cualquier cosa en el invitado». Para un uso como ejecutar un Linux antiguo al lado de Windows Server, esa generalidad es el valor. Pero para un uso como «quiero ejecutar el mismo sistema operativo (o uno predeterminado) que el anfitrión, ahora mismo, para desarrollo o validación», la mayor parte es equipaje desperdiciado. Las máquinas virtuales ligeras sueltan ese equipaje al estrechar el propósito.

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

3.1. Estructura: Una máquina virtual gestionada y las distribuciones de dentro

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

  • El kernel es genuino, pero es un producto especializado. Es un kernel de Linux que Microsoft construye a partir de la rama Stable, ya afinado en tamaño y rendimiento para WSL2. En el estándar actual, el WSL distribuido por Microsoft Store, el kernel se actualiza junto con el propio paquete WSL y se aplica con wsl --update (en la distribución anterior incluida en el sistema operativo llegaba a través de Windows Update).4 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 está entre bastidores. Crear, arrancar y detener la máquina virtual lo gestiona WSL; el usuario solo abre un intérprete de comandos. No hay pantalla de ajustes de máquina virtual ni una espera de arranque sentida.4
  • Una distribución es un contenedor dentro de la máquina virtual. Distribuciones como Ubuntu y Debian se ejecutan como contenedores aislados dentro de una 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.3
Arquitectura de WSL2Un Windows anfitrión y una máquina virtual de utilidad ligera se sitúan lado a lado 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 dentro de esaInterop (comandos, archivos, red)HipervisorWindows anfitriónMáquina virtual de utilidad ligeraKernel de Linux (compilación Microsoft; se actualiza con wsl --update)Ubuntu (contenedor)Debian (contenedor)

Figura 3: La respuesta a «¿WSL2 es una máquina virtual?» es «sí, pero una máquina virtual gestionada, entre bastidores», e incluso si se instalan varias distribuciones sigue habiendo una sola máquina virtual.

El momento en que se escribe wsl, el lado de atrás se ve así.

Desde ejecutar el comando wsl hasta que un intérprete de comandos vuelve en unos pocos segundosSi la máquina virtual de utilidad no está en ejecución cuando se ejecuta wsl, arrancan la máquina virtual ligera y el kernel de Linux; si ya está en ejecución se reutilizan; y un intérprete de comandos vuelve en el contenedor de la distribuciónNoSíEjecutar wsl¿Ya está en ejecución la máquina virtual de utilidad?Arrancar la MV ligera y el kernel de Linux (unos segundos)Reutilizar la MV que ya está en ejecuciónVuelve un intérprete dentro del contenedor

Figura 4: La espera es solo un arranque mínimo de máquina virtual, y aquí es donde se ve el efecto de soltar el equipaje de un arranque completo.

3.2. E/S de archivos: En qué lado se pone lo convierte en otra cosa

El tema que siempre sale en las conversaciones sobre el rendimiento de WSL2 es dónde se ponen los archivos.

  • Las operaciones sobre archivos del lado Linux (el disco virtual ext4) son rápidas. Eso se debe a que el kernel de Linux habla con su propio sistema de archivos de forma directa, y se han informado aceleraciones de hasta 20× frente a WSL1 para la extracción de tarball, y de 2–5× para git clone y npm install.4
  • Las operaciones sobre archivos del lado Windows (/mnt/c y similares) se vuelven lentas porque pasan por un uso compartido de archivos que cruza una frontera de sistema operativo. El rendimiento del sistema de archivos entre sistemas operativos es el único gran apartado en el que WSL2 es peor que WSL1.4

Así que la regla es: «poner los archivos del proyecto en el mismo lado de sistema operativo que las herramientas que operan sobre ellos».4 Un repositorio que se maneja con herramientas de compilación de Linux va al lado Linux; una solución que se compila en Visual Studio va al lado Windows.

La bifurcación de los caminos de E/S de archivos de WSL2El acceso al disco virtual ext4 del lado Linux es directo desde el kernel de Linux y por tanto rápido; el acceso a archivos del lado Windows pasa por un uso compartido que cruza una frontera de sistema operativo y por tanto es lentoLado Linux (home, etc.)Lado Windows (/mnt/c, etc.)Operaciones de archivo dentro de WSL2¿En qué lado está el archivo?E/S directa al disco virtual ext4Vía uso compartido que cruza una frontera de SORápido (ejemplos de hasta 20× frente a WSL1)Tiende a ser lentoSolución: poner el archivo en el SO que lo usa

Figura 5: Lo que es lento es el camino, no WSL2, así que cambiar dónde se ponen los archivos a menudo hace desaparecer el problema de rendimiento.

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

El uso de memoria de WSL2 (se ve como el proceso vmmem en el Administrador de tareas) no es una reserva fija; crece y se encoge con el uso. La memoria que los procesos han liberado se devuelve automáticamente a Windows bajo el ajuste pageReporting, que está habilitado de forma predeterminada.5 Las páginas retenidas como caché de archivos antes no volvían a Windows hasta que salía la máquina virtual.4 En el WSL actual, el ajuste experimental de .wslconfig autoMemoryReclaim (el valor predeterminado es dropCache) también recupera la caché de forma automática.5 En entornos donde este ajuste es disabled, o en WSL antiguo, la caché de una sesión larga puede permanecer hasta que sale la máquina virtual y puede presionar la memoria del anfitrión.

Cómo la memoria de WSL2 crece, se encoge y se devuelveEl crecimiento de la demanda dentro de WSL2 eleva el uso de memoria de la máquina virtual; las páginas liberadas por procesos se devuelven a Windows bajo pageReporting, que está habilitado de forma predeterminada; la caché de archivos la recupera automáticamente autoMemoryReclaim de forma predeterminada; pero con un ajuste deshabilitado o WSL antiguo permanece hasta que sale la máquina virtual, y wsl --shutdown lo devuelve todoLiberada (pageReporting)Retenida como cachéCrece la demanda de memoria dentro de WSL2Crece el uso de vmmem¿Se ha liberado esa página?Devuelta a WindowsautoMemoryReclaim (predet.)Permanece hasta salir (WSL antiguo)wsl --shutdown lo devuelve todo

Figura 6: Lo que parece «solo creció» es principalmente la caché (y, cuando pageReporting está desactivado, también las páginas liberadas por procesos), así que conozca el camino de devolución antes de decidir que es una fuga.

Si se quiere un tope explícito, %UserProfile%\.wslconfig puede controlar la memoria global de la máquina virtual, el número de CPU y el intercambio.5

# %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 —«el tope es un ajuste, el uso real sigue a la demanda»— se lleva aún más lejos en el siguiente tema, Windows Sandbox.

4. Windows Sandbox — Reutilizar el Windows del 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 siguiente vez, arranca en unos pocos segundos desde un estado limpio.1

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

  • La mayoría de los archivos del sistema operativo son inmutables, así que las copias del anfitrión se pueden compartir tal cual.
  • El pequeño número de archivos mutables no se puede compartir, así que se mantiene una copia limpia de ellos dentro de la imagen base.
  • Al arrancar, los archivos inmutables del anfitrión más las copias locales de los archivos mutables se combinan para ensamblar una imagen de Windows completa.2

Dicho de otro modo, Sandbox ni descarga ni almacena una copia de Windows; reutiliza el Windows ya instalado en el anfitrión para arrancar.

Cómo se ensambla una imagen base dinámicaLos archivos inmutables del sistema operativo del Windows anfitrión se comparten; solo los archivos mutables se tienen como copia limpia en la imagen base; y los dos se combinan para ensamblar la imagen de Windows completa de SandboxCompartidos tal cualMantener una copia limpiaEl Windows completo del anfitriónArchivos de SO inmutables (la mayoría)Archivos de SO mutables (una minoría)Imagen de arranque de SandboxArranca como un Windows completoSolo hay que almacenar unos 500 MB

Figura 7: La forma de renunciar a la duplicación de disco no es «poseer otro Windows» sino «ensamblarlo a partir del Windows del anfitrión».

Esa composición es lo que hace posible el siguiente ciclo de vida. Lo que se descarta es el estado local dentro de Sandbox. Si se ha asignado una carpeta escribible del anfitrión en el archivo de configuración .wsb, los cambios ahí permanecen en el anfitrión.6

El ciclo de vida de Windows SandboxArrancar prepara un Windows limpio en unos pocos segundos; tras la validación de aplicaciones o los experimentos se cierra y todo el estado dentro de Sandbox se descarta, de modo que la siguiente vez también arranca limpio; pero los cambios de una carpeta del anfitrión asignada como escribible permanecenSiguiente arranqueArrancar (unos segundos)Un Windows limpioValidación de aplicaciones o experimentosCerrarDescartar todo el estado dentro de SandboxLos cambios de una carpeta escribible asignada permanecen en el anfitrión

Figura 8: Poder volver a limpio cada vez es porque la parte mutable es una copia desechable, y descartarla forma parte del diseño.

4.2. Mapa directo: El mismo ntdll.dll es la misma página física

No solo el disco sino también la RAM se comparte. Como Sandbox ejecuta la misma imagen de sistema operativo que el anfitrión, se usa una técnica llamada «mapa directo» para que, en el caso de los binarios del 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 la misma página física que el mismo binario ya cargado en el anfitrión. Sin exponer los secretos del anfitrión a peligro, logra una huella de memoria mucho más pequeña que una máquina virtual tradicional.2

«Compartir la misma página física entre varios usuarios»: esa 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»). Ese mecanismo era uso compartido entre procesos; Sandbox lo hace a través de una frontera de máquina virtual.

Uso compartido de páginas físicas mediante mapa directoUna aplicación del anfitrión y una aplicación dentro de Sandbox comparten la misma página de memoria física para binarios del sistema operativo como ntdll, reduciendo el uso de memoriaUna aplicación del anfitriónDirección virtual del lado anfitriónUna aplicación dentro de SandboxDirección virtual del lado SandboxLa misma página física (binarios de SO como ntdll.dll)No hace falta duplicar la ración de RAM del SO

Figura 9: El mapa directo es la idea de uso compartido de páginas que se ha usado entre procesos, aplicada a través de una frontera de máquina virtual.

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

Frente a la asignación estática de memoria de una máquina virtual tradicional, la tecnología de contenedores sobre la que se sienta Sandbox decide la asignación de recursos de forma dinámica en cooperación con el anfitrión. Si al anfitrión le falta memoria, puede recuperar memoria del contenedor del mismo modo que la recupera de un proceso ordinario.2 Hyper-V Dynamic Memory también crece y encoge la asignación de una máquina virtual dentro de un rango configurado, pero Sandbox va más allá: la diferencia es que presta y toma prestado en el mismo campo que la gestión de memoria del anfitrión.

Cooperación de memoria entre el anfitrión y SandboxEl valor predeterminado de una máquina virtual tradicional es una asignación exclusiva de tamaño estático con medios de ajuste limitados; Sandbox se convierte en un objetivo de recuperación ante la presión de memoria del anfitrión y presta y toma prestada memoria en el mismo campo que los procesos ordinariosSube la presión de memoria del anfitrión¿De dónde recuperamos?Working Sets de procesos ordinariosEl uso de Sandbox (del contenedor)Se asegura memoria libreUna MV tradicional tiene medios de ajuste limitados

Figura 10: En el préstamo de memoria, Sandbox se sitúa del lado del proceso más que del de la máquina virtual, y ofrece memoria cuando el anfitrión está en apuros.

En la parte 1 dijimos «el rendimiento de una máquina virtual también depende del lado anfitrión», pero con las máquinas virtuales ligeras damos un paso más: la propia asignación de memoria es un trabajo conjunto con el anfitrión. La razón de que Sandbox se pueda usar con la sensación de «otra aplicación» más que de «un producto de virtualización pesado» es esta cooperación.

El procedimiento concreto para usar Sandbox para validar una aplicación empresarial se cubre en el anterior «Cómo acelerar la validación de aplicaciones con Windows Sandbox». Este artículo es el mecanismo que hay debajo.

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

5.1. Aislamiento de proceso y aislamiento Hyper-V

Los contenedores de Windows tienen dos modos de aislamiento en tiempo de ejecución. La imagen se comparte; se elige con una marca al arrancar.7

  • Aislamiento de proceso: varios contenedores comparten el kernel con el anfitrión y se aíslan mediante la 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 Object Manager, etc. Es esencialmente 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 en la práctica es un kernel dedicado. La presencia de la máquina virtual pone aislamiento a nivel de hardware entre los contenedores y el anfitrión.7

El aislamiento mediante espacios de nombres se puede describir como una versión a fondo de la técnica que vimos en el artículo de virtualización del registro («Redirección y virtualización del registro en Windows»): «mostrar una realidad distinta bajo la misma API».

Aislamiento de proceso frente a aislamiento Hyper-VBajo el aislamiento de proceso, los contenedores comparten el kernel con el anfitrión y se aíslan mediante espacios de nombres; bajo el aislamiento Hyper-V, cada contenedor tiene un kernel dedicado dentro de una máquina virtual optimizadaAislamiento Hyper-VAislamiento de procesoKernel dedicado (dentro de una MV optimizada)Contenedor CKernel dedicado (dentro de una MV optimizada)Contenedor DKernel compartido con el anfitriónContenedor AContenedor B

Figura 11: Incluso con la misma imagen de contenedor, si se traza la línea de aislamiento por encima del kernel o se parte el propio kernel es una elección que se hace al arrancar.

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

La diferencia entre estos dos modos no es solo una historia de rendimiento. Microsoft no considera un contenedor aislado por proceso una frontera de seguridad robusta. Los contenedores que se mantienen (con respuesta a vulnerabilidades) como frontera de seguridad son los contenedores aislados por hipervisor, y el aislamiento Hyper-V es el que se debe elegir en un escenario multiinquilino adversario.8

El VBS que vimos en la parte 2 también era un diseño que asume «el kernel puede ser vulnerado» y se retira a una frontera de hipervisor. El mismo criterio se aplica en el mundo de los contenedores. La línea que confina código no de confianza se traza en la frontera del hipervisor, no en el interior de un kernel compartido.

Cómo elegir el aislamiento según cuánto se confía en el códigoSi la carga de trabajo es de confianza, tome densidad y rendimiento con el aislamiento de proceso; si el código no es de confianza o es de otra persona, elija una frontera de hipervisor como un contenedor aislado por Hyper-V, un Windows Sandbox endurecido con la red deshabilitada, o una máquina virtual aisladaSíNo / código de otra persona¿Se puede confiar en ese código?Process isolation (densidad)Elegir frontera hypervisorContenedores aislados por Hyper-VUn Sandbox endurecido o una MV aislada

Figura 12: El modo de aislamiento es una historia de seguridad antes que de rendimiento, y la confianza decide dónde se traza la línea.

Por cierto, ejecutar un contenedor aislado por Hyper-V dentro de una máquina virtual Hyper-V hace el hipervisor dos capas de profundidad: virtualización anidada. Un nivel de anidamiento está admitido en producción en entornos que cumplen las condiciones (un procesador Intel con un anfitrión Windows 10 / Windows Server 2016 o posterior, o un procesador AMD con un anfitrión Windows 11 / Windows Server 2022 o posterior, y la versión de configuración de máquina virtual correspondiente en cada caso), y un requisito previo más es un ajuste que expone las extensiones de virtualización a la máquina virtual exterior (ExposeVirtualizationExtensions en Set-VMProcessor de Hyper-V). Ejecutar WSL2 dentro de una máquina virtual está admitido del mismo modo.9 Que se pueda usar WSL2 o Docker en una máquina virtual de desarrollo en la nube también lo decide si ese tamaño y esa configuración de máquina virtual exponen la virtualización anidada.

La estructura de la virtualización anidadaUna máquina virtual en la nube se sitúa sobre el hipervisor del anfitrión físico, y dentro se ejecuta otro hipervisor (el anidamiento admitido es de un nivel) para admitir WSL2 y contenedores aislados por Hyper-VEl hipervisor del anfitrión físicoMV en la nube (máquina de desarrollo)Hipervisor dentro de la MV (nivel de anidamiento 1)WSL2Contenedor aislado por Hyper-VEl anidamiento admitido es de 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 está admitida de forma oficial solo para un nivel.

5.3. El espectro de aislamiento y ligereza

Alineando el elenco hasta aquí en un solo eje, se ve así.

El espectro de fuerza de aislamiento y ligerezaLos 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 un kernel dedicado (Sandbox aligera compartiendo, WSL2 con un kernel hecho a propósito); una máquina virtual completa es la más pesada pero de propósito generalLigero ← → PesadoContenedores process-isolationWSL2 / Sandbox / Hyper-VMV completa (copia entera)Frontera: espacios de nombresFrontera: hipervisorFrontera: hipervisor + indep.

Figura 14: El grupo de las máquinas virtuales ligeras es la solución intermedia que conservó la frontera del hipervisor y cortó la duplicación; la forma de cortarla se parte en compartir para Sandbox y un kernel hecho a propósito para WSL2.

6. Compruébelo usted mismo

La ligereza y el uso compartido son cosas que se pueden observar en una máquina delante de uno.

Tiempo de arranque y el sube y baja de la memoria (WSL2). Con el Administrador de tareas abierto, pruebe lo siguiente.

# Felt startup time (the first run starts the VM; the second and later are faster still)
Measure-Command { wsl -e true }

# Memory usage of the WSL2 VM (vmmem / Virtual Machine Memory)
Get-Process -Name vmmem* | Select-Object Name, WorkingSet64

# End the whole VM and watch the memory come back
wsl --shutdown

Si se hace una compilación grande o una operación de archivos dentro de WSL2, vmmem crece, y se puede observar que se devuelve de golpe con wsl --shutdown.

La diferencia de velocidad según dónde se pongan los archivos (WSL2). Ponga el mismo repositorio en el lado Linux (~/repo) y en el lado Windows (/mnt/c/repo) y compare el tiempo de git status o de una extracción, y la diferencia de la sección 3.2 aparece en números.

Fondo para el mapa directo (Sandbox). Arranque Sandbox y mire el incremento de memoria en el Administrador de tareas del anfitrión. Que el incremento se quede muy por debajo de lo que «otro Windows» llevaría a imaginar es el efecto del uso compartido contando su historia. Para profundizar en el desglose de memoria del lado anfitrión, el artículo de las herramientas Sysinternals que cubre cómo usar RAMMap y VMMap («Process Explorer / Handle / VMMap en la práctica») es útil. Estas son, sin embargo, herramientas para mirar la clasificación de procesos y de memoria física del lado anfitrión; no observan de forma directa el uso compartido con el propio invitado.

Modos de aislamiento de contenedores (Docker / contenedores de Windows). Si tiene un entorno de contenedores de Windows, arranque la misma imagen con docker run --isolation=process y --isolation=hyperv y compare el tiempo de arranque y cómo se ve en el Administrador de tareas (bajo el aislamiento de proceso, los procesos de dentro del contenedor aparecen en la lista de procesos del anfitrión), y se puede sentir dónde se sitúa la línea de aislamiento.7 El aislamiento de proceso, sin embargo, presupone que las versiones del anfitrión y de la imagen coinciden, y en un sistema operativo cliente se limita al uso de desarrollo y prueba. El aislamiento Hyper-V permite un conjunto más amplio de combinaciones, así que haga la comparación en un par compatible.10

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 el camino de E/S de archivos que cruza una frontera de sistema operativo. Hay muchos casos en los que simplemente mover el proyecto al lado Linux hace que la sensación sea otra cosa.4 A la inversa, poner en el lado Linux archivos que van a tocar herramientas de Windows es igualmente desfavorable por la misma razón. Juzgue por «ponerlo en el mismo sistema operativo que el lado que lo usa».

7.2. «Que vmmem crezca mucho es una fuga de memoria»

La memoria de WSL2 crece y se encoge con la demanda, y las porciones liberadas se devuelven. En el WSL actual, la caché de archivos también la recupera automáticamente autoMemoryReclaim (el valor predeterminado es dropCache), así que «se quedó grande» a menudo se resuelve con el tiempo.5 Si aún permanece, confirme que autoMemoryReclaim no se ha puesto en disabled y que pageReporting, que se encarga de devolver las porciones liberadas, no se ha apagado (o que no está en WSL antiguo), luego o bien haga explícito el tope con memory en .wslconfig o bien devuelva todo con wsl --shutdown en un límite de sesión. La forma de pensar para distinguir una fuga de lo que no lo es es la misma que en la entrega introductoria de la serie de memoria, «¿Qué representa realmente el «uso de memoria» de Windows?».

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

Un contenedor aislado por proceso comparte el kernel, y según el criterio de Microsoft no es una frontera de seguridad.8 Para ejecutar código no de confianza o una muestra, elija un aislamiento que tenga una frontera de hipervisor, como un contenedor aislado por Hyper-V, Windows Sandbox o una máquina virtual dedicada. Una frontera de hipervisor, sin embargo, no es una exención general. Los ajustes predeterminados de Windows Sandbox tienen la conectividad de red habilitada, y pueden exponer una aplicación no de confianza a la red interna.1 Si lo usa para ejecutar una muestra, fortalezca el aislamiento deshabilitando la red y la redirección del portapapeles en el archivo de configuración .wsb, o use una máquina virtual dedicada en una red aislada.

8. Resumen — Cerrar la serie

Los puntos de la parte 3.

  • La ligereza de una máquina virtual ligera 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.3 La regla de rendimiento es poner los archivos en el sistema operativo que los usa, y la memoria crece y se encoge de forma dinámica, con el tope controlable en .wslconfig.45
  • Windows Sandbox comparte los archivos inmutables del sistema operativo del anfitrión mediante una imagen base dinámica y también comparte las páginas físicas de los binarios del sistema operativo objetivo mediante el mapa directo, así que no tiene una copia de un Windows completo.2 Aún hacen falta unos 500 MB para los archivos mutables, más la memoria de las aplicaciones que se ejecutan dentro.
  • El modo de aislamiento de contenedores se elige al arrancar, y el lado al que se puede llamar frontera de seguridad es el aislamiento Hyper-V.78

Y si ponemos toda la serie en una sola página, se ve así.

  • Parte 1: Hay una capa de hipervisor bajo Windows, y el propio sistema operativo anfitrión se ejecuta como partición raíz. El arbitraje de la CPU y de la memoria (SLAT) lo hace de forma directa esta capa, y la E/S de los dispositivos sintéticos la media la partición raíz (VSP) más allá de VMBus.
  • Parte 2: Esa capa se usa no solo para aislar las máquinas virtuales entre sí sino también para trazar una frontera más fuerte que el kernel (VTL) dentro del mismo sistema operativo. La seguridad predeterminada de Windows 11 se construye encima de esto.
  • Parte 3: En la misma capa, cortar la duplicación es lo que hace posible «una máquina virtual que arranca en segundos». Se conserva la línea de aislamiento, y se ha convertido en una herramienta cotidiana.
Un cuadro de toda la serieEl hipervisor directamente sobre el hardware es la parte 1; la división de VTL0 y VTL1 dentro del Windows anfitrión es la parte 2; la ligereza de WSL2, Sandbox y el aislamiento Hyper-V en la misma capa es la parte 3; los contenedores aislados por proceso comparten el kernel del anfitrión; Sandbox aligera compartiendo, WSL2 con un kernel hecho a propósitoHardwareHipervisor (parte 1)Windows anfitrión (VTL = parte 2)WSL2 / Sandbox / Hyper-V (p.3)Contenedores process-isolationSandbox comparte; WSL2 kernel dedicado

Figura 15: Apile las tres entregas y tiene el panorama general del suelo bajo el Windows actual.

La virtualización ya no es una tecnología de sala de servidores, ni una tecnología solo para quienes levantan máquinas virtuales. En el suelo bajo su Windows, sostiene en silencio tanto la seguridad como la experiencia de desarrollo: ahí es donde estamos ahora.

Artículos relacionados

Áreas de consultoría relacionadas

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

Referencias

  1. Microsoft Learn, Windows Sandbox. Sobre que Windows Sandbox arranca en unos pocos segundos como una máquina virtual desechable y descarta todo al cerrarse; sobre que ejecuta un kernel separado con el hipervisor de Microsoft para aislarlo del anfitrión; y sobre que la conectividad de red está habilitada de forma predeterminada y se puede deshabilitar en el archivo de configuración. ↩ ↩2 ↩3

  2. Microsoft Learn, Windows Sandbox architecture. Sobre que una imagen base dinámica ensambla una imagen de Windows completa a partir de un uso compartido de los archivos inmutables del sistema operativo del anfitrión más una copia limpia de los archivos mutables (unos 500 MB tras la instalación); sobre que un contenedor asigna de forma dinámica en cooperación con el anfitrión, frente a la asignación estática de memoria de una máquina virtual tradicional, de modo que el anfitrión puede recuperar memoria; y sobre que el mapa directo hace que los binarios del sistema operativo como ntdll.dll usen las mismas páginas físicas que el anfitrión. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  3. Microsoft Learn, What is the Windows Subsystem for Linux?. Sobre que WSL2 ejecuta un kernel de Linux dentro de una máquina virtual de utilidad ligera; sobre que cada distribución se ejecuta como un contenedor aislado, compartiendo el espacio de nombres de red y el kernel mientras separa espacios de nombres como PID, montaje y usuario. ↩ ↩2 ↩3

  4. Microsoft Learn, Comparing WSL Versions. Sobre que el kernel de WSL2 lo construye Microsoft a partir de la rama Stable; sobre que el WSL distribuido por Store recibe actualizaciones como un paquete desligado de la imagen del sistema operativo y las aplica con wsl --update (en la distribución anterior incluida, a través de Windows Update); sobre ejemplos de rendimiento como hasta 20× para la extracción de tarball; sobre que WSL1 es más rápido para el rendimiento del sistema de archivos entre sistemas operativos, así que los archivos deben colocarse en el sistema operativo que los usa; y sobre que la memoria crece y se encoge con las porciones liberadas devueltas, mientras que la caché puede no volver hasta que sale la máquina virtual. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  5. Microsoft Learn, Advanced settings configuration in WSL. Sobre poder fijar el tope global de memoria de la máquina virtual WSL2, el número de procesadores, el intercambio y pageReporting (habilitado de forma predeterminada; se encarga de detectar y devolver la memoria no usada) en la sección [wsl2] de .wslconfig; y sobre que el ajuste experimental autoMemoryReclaim tiene como valor predeterminado dropCache, de modo que la memoria de caché se recupera automáticamente. ↩ ↩2 ↩3 ↩4 ↩5

  6. Microsoft Learn, Use and configure Windows Sandbox. Sobre que MappedFolders en el archivo de configuración .wsb puede compartir una carpeta del anfitrión como de solo lectura o escribible. ↩

  7. Microsoft Learn, Isolation Modes. Sobre que el aislamiento de proceso de los contenedores de Windows comparte el kernel con el anfitrión y aísla mediante espacios de nombres; sobre que el aislamiento Hyper-V tiene lo que en la práctica es un kernel dedicado dentro de una máquina virtual optimizada; y sobre que la misma imagen se puede ejecutar en cualquiera de los dos modos mediante una marca al arrancar. ↩ ↩2 ↩3 ↩4

  8. Microsoft Learn, Secure Windows containers. Sobre que solo los contenedores aislados por hipervisor se tratan como frontera de seguridad; sobre que los contenedores aislados por proceso no se consideran una frontera de seguridad robusta; y sobre que el aislamiento por hipervisor es el que se debe elegir en un escenario multiinquilino adversario. ↩ ↩2 ↩3

  9. Microsoft Learn, What is Nested Virtualization?. Sobre que ejecutar contenedores aislados por Hyper-V dentro de una máquina virtual Hyper-V (un nivel de anidamiento) está admitido en producción; sobre que los requisitos son un procesador Intel con Windows Server 2016 / Windows 10 o posterior, o un procesador AMD con Windows Server 2022 / Windows 11 o posterior, más la versión de configuración de máquina virtual correspondiente en cada caso; sobre que exponer las extensiones de virtualización a la máquina virtual exterior (ExposeVirtualizationExtensions) es un requisito previo; y sobre que ejecutar WSL2 dentro de una máquina virtual Hyper-V está admitido. ↩

  10. Microsoft Learn, Windows container version compatibility. Sobre que el aislamiento de proceso presupone que las versiones del anfitrión y de la imagen del contenedor coinciden; sobre que el aislamiento Hyper-V puede ejecutar una imagen de una versión de sistema operativo distinta de la del anfitrión; y sobre que el aislamiento de proceso en un sistema operativo cliente se limita al uso de desarrollo y prueba. ↩

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. La máquina virtual la gestiona WSL entre bastidores, así 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 una 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 es una fuga. 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. Las páginas de caché de archivos, también, las 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 sale 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 de solo el pequeño número de archivos mutables. Eso le permite ensamblar 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, hace falta el aislamiento Hyper-V, que da a cada contenedor su propio 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.

Contactar
Volver al blog