Les profondeurs de la virtualisation Windows (partie 3) — Des machines virtuelles qui démarrent en quelques secondes : pourquoi WSL2, Windows Sandbox et les conteneurs sont si légers

Une machine virtuelle complète est lourde — alors pourquoi WSL2 et Windows Sandbox sont-ils légers ? Le dernier volet de la série explique la différence non seulement à partir de « ce qui est isolé », mais à partir de « ce qui n’a pas à être dupliqué ».

Lorsque vous créez une machine virtuelle Windows dans le Gestionnaire Hyper-V, elle met des dizaines de secondes à démarrer et réserve plusieurs gigaoctets de mémoire. Sur le même PC, taper wsl renvoie un interpréteur Linux en quelques secondes, et Windows Sandbox ouvre aussi un bureau jetable en quelques secondes.¹

Le fondement est dans tous les cas l’hyperviseur Windows vu dans la partie 1. Dans la partie 2, nous avons confirmé que ce fondement peut construire une isolation plus forte que le noyau. Cet article examine séparément la spécialisation de WSL2, le partage de Sandbox et les modes d’isolation des conteneurs.

« Les profondeurs de la virtualisation Windows » — Les 3 parties

Nous regardons le même hyperviseur Windows dans l’ordre fondement → isolation de sécurité → application aux machines virtuelles légères.

Prérequis de cet article

Comment lire cet article

1. La conclusion, d’abord

Une machine virtuelle légère conserve la ligne d’isolation (un noyau dédié et la frontière d’hyperviseur) et allège la « copie d’un OS invité complet ». Sandbox partage le Windows de l’hôte lui-même, WSL2 remplace l’invité par un Linux petit et conçu pour l’usage, et dans les deux cas la mémoire n’est pas une réservation fixe mais se prête et s’emprunte dynamiquement avec l’hôte.

La source du poids d’une machine virtuelle complète n’est pas l’isolation elle-même, mais la duplication. Une autre image d’OS sur le disque, l’équivalent d’un autre OS de pages en RAM, et un autre démarrage complet à chaque lancement. Les machines virtuelles légères coupent cette duplication avec deux politiques : « partager ce qu’il est sûr de partager » (Sandbox) et « si on ne peut pas le partager, le reconstruire petit » (WSL2).

flowchart TB
    accTitle: Trois types de partage qui portent les machines virtuelles légères
    accDescr: L'image d'OS qu'une machine virtuelle complète dupliquait est coupée par le partage dans Sandbox et par le rétrécissement dans WSL2, la mémoire qui est une allocation fixe par défaut (les configurations à mémoire dynamique sont l'exception) devient un prêt et un emprunt dynamiques avec l'hôte, et le démarrage est remplacé par un noyau léger et une configuration minimale, ne laissant que la frontière d'isolation
    heavy["La source du poids d'une machine virtuelle complète est la duplication"] --> d1["Disque : une image d'OS dupliquée"]
    heavy --> d2["Mémoire : allocation fixe par défaut"]
    heavy --> d3["Démarrage : un autre boot complet"]
    d1 -->|remplacé par| s1["Partage (Sandbox) ou rétrécissement (WSL2)"]
    d2 -->|remplacé par| s2["Prêt et emprunt dynamiques avec l'hôte"]
    d3 -->|remplacé par| s3["Raccourci par un noyau léger et une configuration minimale"]

Figure 1 : ils ont cessé de dupliquer, non d’isoler, et c’est le squelette de la réponse à « le même hyperviseur, pourtant léger ».

Ci-dessous, nous regardons WSL2, Windows Sandbox et les conteneurs dans cet ordre, et quelle duplication chacun d’eux coupe.

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (19 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

2. Ce qu’une machine virtuelle complète emporte

Comme point de comparaison, voici ce qu’emporte une machine virtuelle classique.

• Une image d’OS indépendante. Elle tient chaque fichier de l’OS invité dans un disque virtuel. Même si l’hôte exécute le même Windows, rien n’est partagé.
• Une allocation mémoire grossière. Une machine virtuelle classique alloue la mémoire de l’hôte à une taille statique par défaut. Il existe des mécanismes comme la mémoire dynamique d’Hyper-V qui font croître et décroître l’allocation dans une plage configurée, mais les moyens de s’ajuster aux changements de demande sont limités.²
• Un démarrage complet à usage général. Le microprogramme, le chargeur d’amorçage et les services démarrent dans la même séquence que sur une machine physique.

flowchart TB
    accTitle: Les trois charges qu'emporte une machine virtuelle complète
    accDescr: Une machine virtuelle complète emporte une image d'OS indépendante, une allocation mémoire statique par défaut et un démarrage complet à usage général, et cela apparaît comme des coûts de disque, de RAM et de temps de démarrage
    fullvm["Machine virtuelle complète"] --> b1["Image d'OS indépendante"]
    fullvm --> b2["Allocation mémoire statique par défaut"]
    fullvm --> b3["Démarrage complet à usage général"]
    b1 -.-> c1["Consomme du disque pour le duplicata"]
    b2 -.-> c2["Tend à retenir de la RAM qu'elle n'utilise pas"]
    b3 -.-> c3["Met des dizaines de secondes à démarrer"]

Figure 2 : chaque poste du détail des coûts d’une machine virtuelle complète se paie pour la généralité et la duplication, non pour l’isolation.

Ce ne sont pas des défauts ; c’est le prix de la généralité de pouvoir tout mettre dans l’invité. Pour un usage tel qu’exécuter un vieux Linux à côté de Windows Server, cette généralité est exactement la valeur. Mais lorsque le besoin est « exécuter tout de suite le même OS que l’hôte (ou un OS fixé), pour le développement ou la validation », l’essentiel devient un poids mort. Les machines virtuelles légères déposent ce bagage en resserrant leur usage.

3. WSL2 — Une machine virtuelle utilitaire qui porte un noyau conçu pour l’usage

WSL2 se lit le plus clairement dans l’ordre structure → où vivent les fichiers → restitution de la mémoire. Utiliser un véritable noyau Linux et traiter rapidement les fichiers côté Windows sont deux affaires distinctes.

3.1. Structure : une machine virtuelle gérée et les distributions à l’intérieur

WSL2 est un mécanisme qui exécute un véritable noyau Linux à l’intérieur d’une machine virtuelle utilitaire légère.³ Trois points comptent.

Le noyau est véritable, mais spécialisé

C’est un noyau Linux que Microsoft construit à partir de la branche Stable, réglé en taille et en performances pour WSL2. Avec le standard actuel, le WSL distribué via le Microsoft Store, le noyau est mis à jour avec le paquet WSL lui-même et appliqué par wsl --update (l’ancienne distribution intégrée à Windows le recevait via Windows Update).⁴

Parce que c’est un véritable noyau, la compatibilité des appels système est complète, et des outils comme Docker s’exécutent tels quels.

La machine virtuelle reste en coulisse

WSL gère la création, le démarrage et l’arrêt de la machine virtuelle ; l’utilisateur n’ouvre qu’un interpréteur. Il n’y a ni écran de réglages de machine virtuelle ni attente perceptible d’un démarrage.⁴

Les distributions sont des conteneurs dans la machine virtuelle

Chaque distribution, Ubuntu ou Debian par exemple, s’exécute comme un conteneur isolé à l’intérieur d’une seule machine virtuelle gérée. Elles partagent l’espace de noms réseau et le noyau, tandis que les espaces de noms tels que PID, montage et utilisateur sont séparés.³

flowchart TB
    accTitle: Architecture de WSL2
    accDescr: Le Windows hôte et une machine virtuelle utilitaire légère siègent côte à côte sur l'hyperviseur, un noyau Linux construit par Microsoft s'exécute dans la machine virtuelle, et chaque distribution s'exécute comme un conteneur isolé à l'intérieur
    hv["Hyperviseur"] --> host["Windows hôte"]
    hv --> uvm["Machine virtuelle utilitaire légère"]
    uvm --> lk["Noyau Linux (build Microsoft, mis à jour par wsl --update)"]
    lk --> u1["Ubuntu (conteneur)"]
    lk --> u2["Debian (conteneur)"]
    host <-->|"Interopérabilité (commandes, fichiers, réseau)"| uvm

Figure 3 : la réponse à « WSL2 est-il une machine virtuelle ? » est « oui, mais une machine virtuelle gérée qui reste hors de vue », et même avec plusieurs distributions installées il n’y a toujours qu’une machine virtuelle.

Voici ce qui se passe en coulisse au moment où vous tapez wsl.

flowchart TB
    accTitle: De l'exécution de la commande wsl à un interpréteur qui revient en quelques secondes
    accDescr: Lorsque wsl s'exécute, la machine virtuelle légère et le noyau Linux sont démarrés si la machine virtuelle utilitaire ne tourne pas encore, la machine virtuelle existante est utilisée telle quelle si elle tourne, et un interpréteur revient dans le conteneur de la distribution
    cmd["Exécuter wsl"] --> vmq{"La machine virtuelle utilitaire tourne-t-elle déjà ?"}
    vmq -->|Non| bootvm["Démarrer la machine virtuelle légère et le noyau Linux (quelques secondes)"]
    vmq -->|Oui| reuse["Utiliser la machine virtuelle en cours telle quelle"]
    bootvm --> shell["Un interpréteur revient dans le conteneur"]
    reuse --> shell

Figure 4 : l’attente n’est rien de plus qu’un démarrage minimal de machine virtuelle, et c’est là que se paie le dépôt du bagage d’un boot complet.

3.2. E/S fichiers : le côté où vivent les fichiers change tout

L’emplacement des fichiers revient dans toute discussion sur les performances de WSL2.

• Les opérations sur les fichiers du côté Linux (le disque virtuel ext4) sont rapides. Le noyau Linux traite son propre système de fichiers directement, et des accélérations allant jusqu’à 20× par rapport à WSL1 pour l’extraction de tarballs et de 2 à 5× pour git clone et npm install ont été rapportées.⁴
• Les opérations sur les fichiers du côté Windows (/mnt/c et analogues) sont plus lentes parce qu’elles passent par un partage de fichiers qui traverse la frontière d’OS. Les performances entre systèmes de fichiers d’OS sont le seul grand point où WSL2 reste derrière WSL1.⁴

La règle est donc : placez les fichiers de projet du même côté d’OS que les outils qui les manipulent.⁴ Un dépôt traité par des outils de build Linux va du côté Linux ; une solution construite dans Visual Studio va du côté Windows.

flowchart TB
    accTitle: La fourche des chemins d'E/S fichiers de WSL2
    accDescr: L'accès au disque virtuel ext4 du côté Linux est rapide parce que le noyau Linux l'atteint directement, tandis que l'accès aux fichiers du côté Windows est lent parce qu'il passe par un partage de fichiers qui traverse la frontière d'OS
    io["Opération sur fichier dans WSL2"] --> place{"De quel côté est le fichier ?"}
    place -->|"Côté Linux (répertoire personnel, etc.)"| ext4["E/S directe vers le disque virtuel ext4"]
    place -->|"Côté Windows (/mnt/c, etc.)"| p9["Via un partage qui traverse la frontière d'OS"]
    ext4 --> fast["Rapide (jusqu'à 20x par rapport à WSL1 dans un exemple)"]
    p9 --> slow["Tend à être lent"]
    slow -.-> fix["Remède : placer le fichier sur l'OS qui l'utilise"]

Figure 5 : ce qui est lent, c’est le chemin, pas WSL2, donc changer simplement l’emplacement des fichiers fait souvent disparaître le problème de performance.

3.3. Mémoire : elle croît, elle décroît, mais elle ne restitue pas tout

L’usage mémoire de WSL2 (visible comme le processus vmmem dans le Gestionnaire des tâches) n’est pas une réservation fixe ; il croît et décroît avec l’usage.

Restituer la mémoire que les processus ont libérée

La mémoire que les processus ont libérée est renvoyée automatiquement à Windows sous le réglage pageReporting, activé par défaut.⁵

Récupérer le cache de fichiers

Les pages tenues comme cache de fichiers ne revenaient autrefois à Windows qu’à l’arrêt de la machine virtuelle.⁴ Dans WSL actuel, le réglage expérimental autoMemoryReclaim de .wslconfig (valeur par défaut dropCache) récupère aussi le cache automatiquement.⁵

Dans les environnements où ce réglage est disabled, ou sur un WSL plus ancien, le cache d’une longue session peut rester jusqu’à l’arrêt de la machine virtuelle et mettre la mémoire de l’hôte sous pression.

flowchart TB
    accTitle: Comment la mémoire de WSL2 croît, décroît et est restituée
    accDescr: La demande croissante dans WSL2 élève l'usage mémoire de la machine virtuelle, la mémoire libérée par les processus est renvoyée à Windows sous pageReporting activé par défaut, le cache de fichiers est récupéré automatiquement par autoMemoryReclaim par défaut, mais avec ces réglages désactivés ou sur un WSL plus ancien il reste jusqu'à l'arrêt de la machine virtuelle, et wsl shutdown restitue tout
    grow["La demande mémoire croît dans WSL2"] --> vm["L'usage de vmmem croît"]
    vm --> freed{"Cette page a-t-elle été libérée ?"}
    freed -->|"Libérée par un processus (avec pageReporting activé)"| ret["Renvoyée automatiquement à Windows"]
    freed -->|Tenue comme cache de fichiers| amr["Récupérée automatiquement par autoMemoryReclaim (défaut)"]
    amr -.-> old2["Reste jusqu'à l'arrêt de la VM si désactivé ou sur un WSL plus ancien"]
    old2 --> sd["wsl --shutdown restitue tout"]

Figure 6 : ce qui ressemble à « ça ne fait que croître » est surtout le cache (avec pageReporting désactivé, la mémoire libérée par les processus reste aussi), donc apprenez les chemins de restitution avant d’appeler cela une fuite.

Fixer un plafond mémoire

Si vous voulez un plafond explicite, %UserProfile%\.wslconfig contrôle la mémoire, le nombre de processeurs et le swap de la machine virtuelle dans son ensemble.⁵

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

Après avoir changé les réglages, redémarrez la machine virtuelle avec wsl --shutdown pour qu’ils prennent effet. Cette allocation dynamique, où un réglage décide du plafond et la demande décide de l’usage réel, est poussée encore plus loin par Windows Sandbox, qui vient ensuite.

4. Windows Sandbox — Réutiliser le Windows de l’hôte une fois de plus

La légèreté de Sandbox se décompose en trois parties : le partage des fichiers d’OS sur le disque, le partage des pages d’OS en RAM et la coordination de l’allocation mémoire avec l’hôte.

4.1. Image de base dynamique : un Windows complet en 500 Mo

Windows Sandbox est un bureau Windows jetable isolé par l’hyperviseur. Fermez-le et tout disparaît ; la fois suivante, il démarre en quelques secondes depuis un état vierge.¹

Le premier puzzle est le disque. Il peut démarrer un Windows complet, et pourtant l’image de base de Sandbox ne fait qu’environ 500 Mo après installation et 30 Mo compressés pour la distribution.² Le secret est l’image de base dynamique.

• La plupart des fichiers d’OS sont immuables (immutable) et peuvent être partagés tels quels depuis l’hôte.
• Seul le petit nombre de fichiers mutables (mutable) ne peut pas être partagé, donc une copie propre en est conservée dans l’image de base.
• Au démarrage, les fichiers immuables de l’hôte et les copies locales des fichiers mutables sont combinés en une image Windows complète.²

Autrement dit, Sandbox ne télécharge ni ne stocke une copie de Windows ; il démarre en réutilisant le Windows déjà installé sur l’hôte.

flowchart TB
    accTitle: Comment l'image de base dynamique est assemblée
    accDescr: Les fichiers d'OS immuables du Windows de l'hôte sont partagés, seuls les fichiers mutables sont conservés comme copie propre dans l'image de base, et les deux sont combinés en l'image Windows complète de Sandbox
    hostw["Le Windows complet de l'hôte"] --> imm["Fichiers d'OS immuables (la grande majorité)"]
    hostw --> mut["Fichiers d'OS mutables (quelques-uns)"]
    imm -->|partagés tels quels| img["Image de démarrage de Sandbox"]
    mut -->|copie propre conservée| img
    img --> boot["Démarre comme un Windows complet"]
    img -.-> size["Seuls environ 500 Mo doivent être stockés"]

Figure 7 : non pas « tenir un autre Windows », mais « en assembler un à partir du Windows de l’hôte » est la forme que prend l’abandon de la duplication disque.

C’est précisément cette composition qui rend possible le cycle de vie suivant.

Ce qui est jeté, c’est l’état local à l’intérieur de Sandbox.

Si vous mappez un dossier inscriptible depuis l’hôte dans le fichier de configuration .wsb, les modifications qui y sont faites restent côté hôte.⁶

flowchart TB
    accTitle: Cycle de vie de Windows Sandbox
    accDescr: Le démarrage prépare un Windows vierge en quelques secondes, après validation d'applications ou expériences la fermeture jette tout l'état dans Sandbox de sorte que le démarrage suivant est à nouveau vierge, mais les modifications d'un dossier hôte mappé en écriture restent
    launch["Démarrage (quelques secondes)"] --> clean["Un Windows vierge"]
    clean --> work["Validation d'applications ou expériences"]
    work --> close2["Fermer"]
    close2 --> discard["Jeter tout l'état dans Sandbox"]
    discard -.-> mapped["Les modifications d'un dossier inscriptible mappé restent sur l'hôte"]
    discard -->|démarrage suivant| launch

Figure 8 : revenir à un état vierge à chaque fois est possible parce que la partie mutable est une copie jetable, et jeter fait partie de la conception.

4.2. Direct Map : le même ntdll.dll est la même page physique

Non seulement le disque, mais aussi la RAM est partagée. Parce que Sandbox exécute la même image d’OS que l’hôte, une technique appelée « Direct Map » est utilisée pour que, s’agissant des binaires d’OS, il utilise les mêmes pages de mémoire physique que l’hôte. Lorsque ntdll.dll est chargé en mémoire dans Sandbox, il pointe vers les mêmes pages physiques que le même binaire chargé sur l’hôte.

Cela atteint une empreinte mémoire bien plus petite qu’une machine virtuelle classique, sans exposer les secrets de l’hôte à un risque.²

« Partager la même page physique entre plusieurs utilisateurs » — c’est la même idée que le partage de DLL par objets section, que nous avons suivi dans la partie 3 de la série mémoire (« Objets section et copie sur écriture »). Ce mécanisme-là partageait entre processus ; Sandbox le fait en traversant la frontière de machine virtuelle.

flowchart TB
    accTitle: Partage de pages physiques par Direct Map
    accDescr: Une application sur l'hôte et une application dans Sandbox partagent les mêmes pages de mémoire physique pour des binaires d'OS tels que ntdll, ce qui réduit l'usage mémoire
    happ["Application sur l'hôte"] --> hva["Adresse virtuelle côté hôte"]
    sapp["Application dans Sandbox"] --> sva["Adresse virtuelle côté Sandbox"]
    hva --> phys["La même page physique (binaires d'OS tels que ntdll.dll)"]
    sva --> phys
    phys -.-> save["Plus besoin de dupliquer la part d'OS de la RAM"]

Figure 9 : Direct Map reprend l’idée du partage de pages longtemps utilisée entre processus et l’applique en traversant la frontière de machine virtuelle.

4.3. Prêter et emprunter de la mémoire : davantage comme un processus que comme une machine virtuelle

Contrairement à l’allocation mémoire statique d’une machine virtuelle classique, la technique de conteneur sous Sandbox décide l’allocation des ressources dynamiquement, en coordination avec l’hôte. Si l’hôte manque de mémoire, il peut récupérer de la mémoire du conteneur exactement comme il en récupère d’un processus ordinaire.² La mémoire dynamique d’Hyper-V fait aussi croître et décroître l’allocation d’une machine virtuelle dans une plage configurée, mais Sandbox va plus loin : elle partage la mémoire sur le même terrain que la propre gestion mémoire de l’hôte.

flowchart TB
    accTitle: Coordination mémoire entre l'hôte et Sandbox
    accDescr: Une machine virtuelle classique réserve une taille statique par défaut avec des moyens d'ajustement limités, tandis que Sandbox devient une cible de récupération en réponse à la pression mémoire de l'hôte et partage la mémoire sur le même terrain que les processus ordinaires
    pressure["La pression mémoire de l'hôte monte"] --> from{"Où récupérer ?"}
    from --> proc["Les Working Set des processus ordinaires"]
    from --> sbx["Ce que Sandbox (le conteneur) utilise"]
    proc --> relief["De la mémoire libre est assurée"]
    sbx --> relief
    relief -.-> contrast["Une machine virtuelle classique a des moyens d'ajustement limités"]

Figure 10 : pour le partage de mémoire, Sandbox se tient du côté des processus plutôt que des machines virtuelles, et cède de la mémoire lorsque l’hôte est sous pression.

Dans la partie 1, nous avons dit que les performances d’une machine virtuelle dépendent aussi du côté hôte ; avec les machines virtuelles légères, cela va un pas plus loin, et l’allocation mémoire elle-même devient un travail commun avec l’hôte. Cette coordination est la raison pour laquelle Sandbox se sent moins comme « un logiciel de virtualisation lourd » et davantage comme une application de plus.

Les étapes concrètes pour utiliser Sandbox à la validation d’applications métier sont traitées dans l’article antérieur « Accélérer la validation des applications avec Windows Sandbox ». Cet article couvre le mécanisme en dessous.

5. Conteneurs — Où tracer la ligne d’isolation

Ici, nous ne jugeons pas la sécurité au seul nom « conteneur » ; nous vérifions si le conteneur partage le noyau avec l’hôte ou s’il a un noyau à lui.

5.1. Isolation de processus et isolation Hyper-V

Les conteneurs Windows ont deux modes d’isolation à l’exécution. L’image est la même ; vous choisissez le mode par un indicateur au démarrage.⁷

• Isolation de processus : plusieurs conteneurs partagent le noyau avec l’hôte et sont isolés par une virtualisation par espace de noms du système de fichiers, du registre, des ports réseau, de l’espace d’identifiants de processus, de l’espace de noms du Gestionnaire d’objets, et ainsi de suite. C’est presque la même approche que les conteneurs Linux.
• Isolation Hyper-V : chaque conteneur s’exécute à l’intérieur d’une machine virtuelle hautement optimisée et a ce qui équivaut à un noyau dédié. La présence de la machine virtuelle place une isolation au niveau matériel entre les conteneurs et entre eux et l’hôte.⁷

L’isolation par espaces de noms peut se voir comme la version aboutie de la technique de l’article sur la virtualisation du registre (« Redirection et virtualisation du registre sous Windows ») : montrer une autre entité sous la même API.

flowchart TB
    accTitle: Isolation de processus face à l'isolation Hyper-V
    accDescr: Sous isolation de processus, les conteneurs partagent le noyau avec l'hôte et sont isolés par des espaces de noms, sous isolation Hyper-V chaque conteneur a un noyau dédié dans une machine virtuelle optimisée
    subgraph pi ["Isolation de processus"]
        c1["Conteneur A"] --> sk1["Noyau partagé avec l'hôte"]
        c2["Conteneur B"] --> sk1
    end
    subgraph hi ["Isolation Hyper-V"]
        c3["Conteneur C"] --> k3["Noyau dédié (dans une VM optimisée)"]
        c4["Conteneur D"] --> k4["Noyau dédié (dans une VM optimisée)"]
    end
    sk1 ~~~ c3

Figure 11 : même avec la même image de conteneur, c’est au démarrage que l’on choisit si la ligne d’isolation est tracée au-dessus du noyau ou si le noyau lui-même est séparé.

5.2. Lequel peut s’appeler « frontière de sécurité »

La différence entre les deux modes ne s’arrête pas aux performances. Microsoft ne considère pas les conteneurs à isolation de processus comme une frontière de sécurité robuste. Les conteneurs maintenus comme frontière de sécurité (avec correction des vulnérabilités) sont ceux isolés par l’hyperviseur, et dans les scénarios multi-locataires hostiles, l’isolation Hyper-V est le mode à choisir.⁸

Le VBS vu dans la partie 2 était lui aussi conçu sur la prémisse « le noyau peut être compromis », en se repliant sur la frontière d’hyperviseur. Le même critère vaut dans le monde des conteneurs. La ligne qui confine le code non fiable se trace à la frontière d’hyperviseur, non à l’intérieur d’un noyau partagé.

flowchart TB
    accTitle: Choisir l'isolation selon le degré de confiance du code
    accDescr: Une charge de travail de confiance prend la densité et les performances avec l'isolation de processus, tandis que le code non fiable ou le code d'autrui reçoit une frontière d'hyperviseur telle qu'un conteneur isolé Hyper-V, un Windows Sandbox durci avec le réseau et analogues désactivés, ou une machine virtuelle isolée
    trust{"Ce code est-il digne de confiance ?"} -->|Oui| dens["Isolation de processus (densité et vitesse d'abord)"]
    trust -->|"Non, ou code d'autrui"| bound["Choisir une frontière d'hyperviseur"]
    bound --> opt1["Conteneur isolé Hyper-V"]
    bound --> opt2["Sandbox durci ou VM isolée"]

Figure 12 : le mode d’isolation est une affaire de sécurité avant d’être une affaire de performances, et le degré de confiance décide où passe la ligne.

Note : à l’intérieur d’une machine virtuelle, vérifier les exigences de la virtualisation imbriquée

Exécuter des conteneurs isolés Hyper-V à l’intérieur d’une machine virtuelle Hyper-V signifie deux couches d’hyperviseur : de la virtualisation imbriquée.

Un niveau d’imbrication est pris en charge en production sur les environnements qui remplissent les conditions (un hôte Windows 10 / Windows Server 2016 ou ultérieur pour les processeurs Intel, un hôte Windows 11 / Windows Server 2022 ou ultérieur pour les processeurs AMD, plus la version de configuration de machine virtuelle correspondante dans chaque cas), et il exige en outre le réglage qui expose les extensions de virtualisation à la machine virtuelle extérieure (ExposeVirtualizationExtensions sur Set-VMProcessor pour Hyper-V).

Exécuter WSL2 à l’intérieur d’une machine virtuelle est pris en charge de la même façon.⁹ Pouvoir utiliser WSL2 ou Docker sur une machine virtuelle de développement dans le nuage dépend de même de ce que la taille et la configuration de cette machine virtuelle exposent la virtualisation imbriquée.

flowchart TB
    accTitle: La structure de la virtualisation imbriquée
    accDescr: Une machine virtuelle en nuage siège sur l'hyperviseur de l'hôte physique, et à l'intérieur un autre hyperviseur (l'imbrication n'est prise en charge que pour un niveau) s'exécute pour porter WSL2 et les conteneurs isolés Hyper-V
    phys3["Hyperviseur de l'hôte physique"] --> cvm["Machine virtuelle en nuage (machine de développement)"]
    cvm --> nhv["Hyperviseur dans la VM (premier niveau d'imbrication)"]
    nhv --> w2["WSL2"]
    nhv --> hvc["Conteneur isolé Hyper-V"]
    nhv -.-> limit["L'imbrication n'est prise en charge que pour un niveau"]

Figure 13 : la raison pour laquelle wsl s’exécute dans une machine virtuelle en nuage est que la virtualisation imbriquée est officiellement prise en charge pour exactement un niveau.

5.3. Le spectre de l’isolation et de la légèreté

Aligner tout ce qui a été couvert jusqu’ici sur un seul axe donne ce qui suit.

flowchart TB
    accTitle: Le spectre de la force d'isolation et de la légèreté
    accDescr: Les conteneurs à isolation de processus sont les plus légers mais partagent le noyau, WSL2, Sandbox et les conteneurs isolés Hyper-V sont des machines virtuelles légères à noyau dédié (Sandbox allégée par le partage avec l'hôte, WSL2 par un noyau conçu pour l'usage), et une machine virtuelle complète est la plus lourde mais à usage général
    ax["Léger ← → Lourd"] ~~~ p1
    p1["Conteneur à isolation de processus (noyau partagé)"] --> p2["WSL2, Sandbox, isolation Hyper-V (VM légères à noyau dédié)"]
    p2 --> p3["Machine virtuelle complète (exécute tout, tient chaque duplicata)"]
    p1 -.-> n1["Frontière : espaces de noms"]
    p2 -.-> n2["Frontière : hyperviseur"]
    p3 -.-> n3["Frontière : hyperviseur + indépendance complète"]

Figure 14 : les machines virtuelles légères sont la solution intermédiaire qui a conservé la frontière d’hyperviseur tout en coupant la duplication ; la façon de couper diffère, avec le partage pour Sandbox et un noyau conçu pour l’usage pour WSL2.

6. Le vérifier de vos propres yeux

La légèreté et le partage s’observent sur votre propre machine.

6.1. Temps de démarrage de WSL2 et croissance et décroissance de la mémoire

Laissez le Gestionnaire des tâches ouvert et essayez ce qui suit.

# Temps de démarrage perçu (le premier lancement démarre la VM ; les suivants sont encore plus rapides)
Measure-Command { wsl -e true }

# Usage mémoire de la machine virtuelle WSL2 (vmmem / Virtual Machine Memory)
Get-Process -Name vmmem* | Select-Object Name, WorkingSet64

# Arrêter toute la machine virtuelle et observer le retour de la mémoire
wsl --shutdown

Exécutez un gros build ou une opération sur fichiers dans WSL2 et vmmem grandit ; wsl --shutdown restitue tout d’un coup, et vous pouvez l’observer.

6.2. Écarts de vitesse selon le placement des fichiers de WSL2

Placez le même dépôt du côté Linux (~/repo) et du côté Windows (/mnt/c/repo), comparez le temps de git status ou d’une extraction, et l’écart de la section 3.2 apparaît en chiffres.

6.3. Augmentation mémoire côté hôte au démarrage de Sandbox

Démarrez Sandbox et observez l’augmentation mémoire dans le Gestionnaire des tâches de l’hôte. Qu’elle reste bien plus petite que ce que « un second Windows complet » laisserait imaginer raconte l’effet du partage.

Pour creuser davantage la répartition mémoire côté hôte, l’article sur les outils Sysinternals qui couvre l’usage de RAMMap et de VMMap (« Process Explorer / Handle / VMMap en pratique ») est une référence utile.

Ce sont toutefois des outils pour classer les processus et la mémoire physique côté hôte ; ils n’observent pas directement le partage avec l’invité lui-même.

6.4. Différences entre les modes d’isolation des conteneurs Windows

Si vous avez un environnement de conteneurs Windows, démarrez la même image avec docker run --isolation=process et avec --isolation=hyperv, puis comparez le temps de démarrage et ce que montre le Gestionnaire des tâches (sous isolation de processus, les processus dans le conteneur apparaissent dans la liste des processus de l’hôte) pour sentir où siège la ligne d’isolation.⁷

L’isolation de processus, toutefois, exige que les versions de l’hôte et de l’image correspondent, et sur un OS client elle est limitée à un usage de développement et de test. L’isolation Hyper-V admet une plus large gamme de combinaisons, donc faites la comparaison avec une paire compatible.¹⁰

7. Trois lectures erronées à éviter en pratique

7.1. « WSL2 est lent »

Ce qui est lent, ce n’est pas WSL2, mais le chemin d’E/S fichiers qui traverse la frontière d’OS. Dans de nombreux cas, simplement déplacer le projet du côté Linux transforme le ressenti.⁴ Inversement, placer du côté Linux des fichiers que les outils Windows touchent est un désavantage pour la même raison. Décidez par « le placer sur le même OS que ce qui l’utilise ».

7.2. « Que vmmem grossisse est une fuite mémoire »

La mémoire de WSL2 croît et décroît avec la demande, et la mémoire libérée est restituée. Sur WSL actuel, autoMemoryReclaim (valeur par défaut dropCache) récupère aussi le cache de fichiers automatiquement, donc « ça est resté grand » se résout souvent de lui-même avec le temps.⁵

S’il reste malgré tout, vérifiez que autoMemoryReclaim n’est pas disabled et que pageReporting, qui restitue la mémoire libérée, n’a pas été désactivé (et que vous n’êtes pas sur un WSL plus ancien) ; puis soit fixez un plafond explicite avec memory dans .wslconfig, soit restituez tout avec wsl --shutdown à la fin d’une session.

L’approche pour décider s’il s’agit d’une fuite est la même que dans l’introduction de la série mémoire, « Que représente réellement la « mémoire utilisée » sous Windows ? ».

7.3. « C’est dans un conteneur, donc c’est sûr »

Les conteneurs à isolation de processus partagent le noyau, et selon le critère de Microsoft ils ne sont pas une frontière de sécurité.⁸ Pour exécuter du code non fiable ou des échantillons, choisissez une isolation qui a une frontière d’hyperviseur : un conteneur isolé Hyper-V, Windows Sandbox, ou une machine virtuelle dédiée.

Une frontière d’hyperviseur, toutefois, n’est pas un laissez-passer universel.

Les réglages par défaut de Windows Sandbox ont la connexion réseau activée, ce qui peut exposer une application non fiable à votre réseau interne.¹ Si vous l’utilisez pour exécuter des échantillons, soit renforcez l’isolation en désactivant le réseau et la redirection du Presse-papiers dans le fichier de configuration .wsb, soit utilisez une machine virtuelle dédiée sur un réseau isolé.

8. Synthèse — Clore la série

Les points clés de la partie 3.

• La légèreté des machines virtuelles légères est le résultat de « cesser de dupliquer », non de « affaiblir l’isolation ».
• WSL2 exécute un véritable noyau Linux dans une machine virtuelle utilitaire légère gérée, et les distributions sont isolées comme conteneurs à l’intérieur de cette machine virtuelle.³ La règle de performance est de placer les fichiers sur l’OS qui les utilise ; la mémoire croît et décroît dynamiquement, et .wslconfig contrôle le plafond.⁴⁵
• Windows Sandbox partage les fichiers d’OS immuables de l’hôte via l’image de base dynamique et les pages physiques des binaires d’OS concernés via Direct Map, de sorte qu’il ne tient aucune copie d’un Windows complet.² Les quelque 500 Mo de fichiers mutables et la mémoire des applications que vous y exécutez restent nécessaires à part.
• Le mode d’isolation des conteneurs se choisit au démarrage, et le côté qui peut s’appeler frontière de sécurité est l’isolation Hyper-V.⁷⁸

Et mettre toute la série sur une page donne ceci.

• Partie 1 : sous Windows il y a une couche d’hyperviseur, et l’OS hôte lui-même s’exécute comme partition racine. Cette couche arbitre directement le processeur et la mémoire (SLAT), et l’E/S des périphériques synthétiques est médiatisée par la partition racine (VSP) au bout de VMBus.
• Partie 2 : cette couche sert non seulement à isoler les machines virtuelles les unes des autres, mais aussi à tracer à l’intérieur du même OS une frontière plus forte que le noyau (VTL). La sécurité par défaut de Windows 11 est construite dessus.
• Partie 3 : sur la même couche, couper la duplication est ce qui rend possible « une machine virtuelle qui démarre en quelques secondes ». La ligne d’isolation est conservée, et elle est devenue un outil du quotidien.

flowchart TB
    accTitle: Toute la série en une image
    accDescr: L'hyperviseur directement sur le matériel est la partie 1, la séparation de VTL0 et VTL1 dans le Windows hôte est la partie 2, et la légèreté de WSL2, Sandbox et de l'isolation Hyper-V sur la même couche est la partie 3, les conteneurs à isolation de processus partageant le noyau de l'hôte, Sandbox allégé par le partage et WSL2 par un noyau conçu pour l'usage
    hw3["Matériel"] --> hv3["Hyperviseur (partie 1)"]
    hv3 --> rp3["Windows hôte (la séparation VTL est la partie 2)"]
    hv3 --> lw3["WSL2, Sandbox, isolation Hyper-V (partie 3)"]
    rp3 --> pc3["Conteneur à isolation de processus (noyau partagé)"]
    lw3 -.-> mech3["Sandbox allégé par le partage, WSL2 par un noyau conçu pour l'usage"]

Figure 15 : empilez les trois parties et vous avez le tableau d’ensemble de ce qui se trouve sous le Windows d’aujourd’hui.

La virtualisation n’est plus une technique de salle serveurs, ni une technique seulement pour ceux qui dressent des machines virtuelles. Sous votre Windows, elle soutient en silence à la fois la sécurité et l’expérience de développement. Voilà où nous en sommes.

Articles connexes

• Les profondeurs de la virtualisation Windows (partie 1) — Où s’exécute réellement votre Windows ? L’hyperviseur et les partitions
• Les profondeurs de la virtualisation Windows (partie 2) — Une mémoire invisible même au noyau : comment fonctionnent VBS, HVCI et Credential Guard
• Les profondeurs de la mémoire Windows (partie 3) — Objets section et copie sur écriture
• Accélérer la validation des applications avec Windows Sandbox
• Redirection et virtualisation du registre sous Windows

Domaines de conseil associés

KomuraSoft LLC prend en charge la mise en place d’environnements de développement qui utilisent WSL2 et les conteneurs, la conception d’environnements de validation pour les applications Windows, et l’investigation des performances et de la compatibilité en environnement virtualisé.

• Développement d’applications Windows
• Investigation de bugs et analyse des causes
• Migration d’actifs hérités
• Nous contacter

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

WSL2 est-il une machine virtuelle ?

Oui. WSL2 exécute un véritable noyau Linux construit par Microsoft à l'intérieur d'une machine virtuelle utilitaire légère. WSL gère la machine virtuelle en coulisse, de sorte que la conception ne fait jamais penser l'utilisateur aux réglages de machine virtuelle ni à l'attente d'un démarrage. Chaque distribution Linux s'exécute comme un conteneur isolé à l'intérieur de cette machine virtuelle gérée.

Pourquoi les opérations sur fichiers sous /mnt/c sont-elles lentes dans WSL2 ?

Parce que l'accès depuis le noyau Linux de WSL2 au système de fichiers côté Windows passe par un partage de fichiers qui traverse la frontière d'OS. Les opérations sur le système de fichiers Linux (un disque virtuel ext4) sont rapides, donc la règle est de garder les fichiers de projet du même côté d'OS que les outils qui travaillent dessus.

Une utilisation mémoire importante du processus vmmem est-elle une fuite ?

Dans la plupart des cas, ce n'est pas une fuite. La mémoire de WSL2 croît et décroît avec l'usage, et la mémoire que les processus ont libérée est renvoyée à Windows sous le réglage pageReporting, activé par défaut. Le cache de fichiers, lui aussi, est récupéré automatiquement par WSL actuel via autoMemoryReclaim dans .wslconfig (la valeur par défaut est dropCache). Dans les environnements où ces réglages ont été désactivés, ou sur un WSL plus ancien, la mémoire peut rester jusqu'à l'arrêt de la machine virtuelle ; dans ce cas, fixez un plafond avec le réglage memory, ou renvoyez-la avec wsl --shutdown.

Comment Windows Sandbox peut-il démarrer un Windows complet à partir de quelques centaines de mégaoctets de disque ?

Grâce à un mécanisme appelé image de base dynamique. Il partage les fichiers d'OS immuables du Windows déjà installé sur l'hôte et conserve une copie propre du petit nombre de fichiers mutables. Cela assemble une image complète amorçable sans stocker une copie entière de Windows.

Les conteneurs sont-ils plus sûrs que les machines virtuelles ?

Cela dépend du mode d'isolation. Les conteneurs à isolation de processus partagent le noyau avec l'hôte, et Microsoft ne considère pas ceci comme une frontière de sécurité robuste. Lorsque vous manipulez du code adverse, il faut choisir l'isolation Hyper-V, qui donne à chaque conteneur un noyau dédié.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.