Глубины виртуализации Windows (часть 3) — виртуальные машины, которые стартуют за секунды: почему WSL2, Windows Sandbox и контейнеры такие лёгкие

Полноценная ВМ тяжела. Почему тогда WSL2 и Windows Sandbox лёгкие? Финальная часть серии объясняет разницу не только из «что изолировано», но и из «что не нужно дублировать».

Когда в диспетчере Hyper-V создаёте ВМ с Windows, на запуск уходят десятки секунд, и несколько гигабайт памяти оказываются заняты. На том же ПК команда wsl возвращает оболочку Linux за считанные секунды, а Windows Sandbox за те же секунды открывает одноразовый рабочий стол.¹

Основа в каждом случае — гипервизор Windows из части 1. В части 2 мы подтвердили, что эта основа умеет строить изоляцию сильнее ядра. Эта статья смотрит отдельно на специализацию WSL2, совместное использование Sandbox и режимы изоляции контейнеров.

«Глубины виртуализации Windows» — все 3 части

Один и тот же гипервизор Windows смотрим в порядке основа → изоляция безопасности → применение к лёгким ВМ.

Предпосылки этой статьи

Как читать эту статью

1. Сначала вывод

Лёгкая ВМ сохраняет линию изоляции (выделенное ядро и границу гипервизора) и облегчает «копию полной гостевой ОС». Sandbox совместно использует сам Windows хоста, WSL2 подменяет гостя небольшим Linux, заточенным под задачу, и в обоих случаях память — не фиксированный резерв, а динамически выделяется и возвращается хосту.

Источник тяжести полноценной ВМ — не изоляция, а дублирование: ещё один образ ОС на диске, ещё один набор страниц ОС в ОЗУ и ещё одна полная загрузка при каждом старте. Лёгкие ВМ срезают это дублирование двумя политиками: «совместно использовать то, что безопасно совместно использовать» (Sandbox) и «если совместно использовать нельзя — собрать заново и меньше» (WSL2).

flowchart TB
    accTitle: Три вида совместного использования, на которых держатся лёгкие ВМ
    accDescr: Образ ОС, который полноценная ВМ дублировала, в Sandbox срезают совместным использованием, а в WSL2 — уменьшением; память, которую по умолчанию выделяют фиксированно (конфигурации Dynamic Memory — исключение), начинает динамически выделяться и возвращаться хосту; запуск заменяют лёгким ядром и минимальной конфигурацией, оставляя только границу изоляции
    heavy["Источник тяжести полноценной ВМ — дублирование"] --> d1["Диск: дубликат образа ОС"]
    heavy --> d2["Память: по умолчанию фиксированный объём"]
    heavy --> d3["Запуск: ещё одна полная загрузка"]
    d1 -->|заменено| s1["Совместное использование (Sandbox) или уменьшение (WSL2)"]
    d2 -->|заменено| s2["Динамически выделяется и возвращается хосту"]
    d3 -->|заменено| s3["Сокращено лёгким ядром и минимальной конфигурацией"]

Рис. 1: Они перестали дублировать, а не изолировать, и это каркас ответа на «тот же гипервизор, и всё же лёгкие».

Дальше смотрим WSL2, Windows Sandbox и контейнеры — и какое именно дублирование срезает каждый из них.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 19, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Что несёт полноценная ВМ

Как база для сравнения — что несёт традиционная ВМ.

• Независимый образ ОС. Она держит каждый файл гостевой ОС внутри виртуального диска. Даже если хост работает на том же Windows, ничего не совместно используется.
• Грубое выделение памяти. Традиционная ВМ по умолчанию выделяет память хоста статическим размером. Есть механизмы вроде Hyper-V Dynamic Memory, которые увеличивают и уменьшают выделение в настроенном диапазоне, но средства подстройки под изменение спроса ограничены.²
• Универсальная полная загрузка. Прошивка, загрузчик и службы стартуют в той же последовательности, что на физической машине.

flowchart TB
    accTitle: Три нагрузки, которые несёт полноценная ВМ
    accDescr: Полноценная ВМ несёт независимый образ ОС, выделение памяти, которое по умолчанию статическое, и универсальную полную загрузку, и это проявляется как стоимость на диске, в ОЗУ и во времени запуска
    fullvm["Полноценная ВМ"] --> b1["Независимый образ ОС"]
    fullvm --> b2["Выделение памяти, которое по умолчанию статическое"]
    fullvm --> b3["Универсальная полная загрузка"]
    b1 -.-> c1["Расходует диск на дубликат"]
    b2 -.-> c2["Склонен удерживать ОЗУ, которой не пользуется"]
    b3 -.-> c3["На запуск уходят десятки секунд"]

Рис. 2: Каждая статья разбивки стоимости полноценной ВМ платится за универсальность и дублирование, а не за изоляцию.

Это не дефекты; это цена универсальности — возможности положить в гостя что угодно. Для сценария вроде «запустить старый Linux рядом с Windows Server» эта универсальность как раз ценность. Но когда нужда — «запустить ту же ОС, что на хосте (или фиксированную) прямо сейчас, для разработки или проверки», большая часть — мёртвый груз. Лёгкие ВМ кладут этот багаж, сужая назначение.

3. WSL2 — служебная ВМ с ядром, заточенным под задачу

WSL2 проще всего следить в порядке структура → где живут файлы → возврат памяти. Использовать настоящее ядро Linux и быстро обращаться с файлами на стороне Windows — разные вещи.

3.1. Структура: управляемая ВМ и дистрибутивы внутри неё

WSL2 — механизм, который запускает настоящее ядро Linux внутри лёгкой служебной ВМ.³ Пунктов три.

Ядро настоящее, но специализированное

Это ядро Linux, которое Microsoft собирает из ветки Stable, подогнанное по размеру и производительности под WSL2. При актуальном стандарте, WSL, распространяемом через Microsoft Store, ядро обновляется вместе с самим пакетом WSL и применяется через wsl --update (старое встроенное распространение получало его через Windows Update).⁴

Потому что ядро настоящее, совместимость системных вызовов полная, и инструменты вроде Docker работают как есть.

ВМ остаётся за кадром

WSL управляет созданием, запуском и остановкой ВМ; пользователь просто открывает оболочку. Нет экрана настроек ВМ и нет ощутимого ожидания загрузки.⁴

Дистрибутивы — контейнеры внутри ВМ

Каждый дистрибутив вроде Ubuntu или Debian работает как изолированный контейнер внутри одной управляемой ВМ. Они совместно используют пространство имён сети и ядро, а пространства имён вроде PID, монтирования и пользователя разделены.³

flowchart TB
    accTitle: Архитектура WSL2
    accDescr: Хостовый Windows и лёгкая служебная ВМ сидят рядом на гипервизоре, внутри ВМ работает ядро Linux сборки Microsoft, и каждый дистрибутив работает как изолированный контейнер внутри неё
    hv["Гипервизор"] --> host["Хостовый Windows"]
    hv --> uvm["Лёгкая служебная ВМ"]
    uvm --> lk["Ядро Linux (сборка Microsoft, обновляется через wsl --update)"]
    lk --> u1["Ubuntu (контейнер)"]
    lk --> u2["Debian (контейнер)"]
    host <-->|"Interop (команды, файлы, сеть)"| uvm

Рис. 3: Ответ на «WSL2 — это ВМ?» — «да, но управляемая ВМ, которая остаётся вне поля зрения», и даже при нескольких установленных дистрибутивах ВМ всё ещё одна.

Вот что происходит за кадром в момент, когда вы набираете wsl.

flowchart TB
    accTitle: От запуска команды wsl до оболочки, которая возвращается за секунды
    accDescr: Когда запускается wsl, лёгкая ВМ и ядро Linux стартуют, если служебная ВМ ещё не работает, существующая ВМ используется как есть, если работает, и оболочка возвращается в контейнере дистрибутива
    cmd["Запустить wsl"] --> vmq{"Служебная ВМ уже работает?"}
    vmq -->|Нет| bootvm["Запустить лёгкую ВМ и ядро Linux (секунды)"]
    vmq -->|Да| reuse["Использовать работающую ВМ как есть"]
    bootvm --> shell["Оболочка возвращается внутри контейнера"]
    reuse --> shell

Рис. 4: Ожидание — не больше, чем минимальный старт ВМ, и здесь окупается то, что багаж полной загрузки положили.

3.2. Файловый ввод-вывод: на какой стороне живут файлы, решает всё

Где размещены файлы, всплывает в каждом разговоре о производительности WSL2.

• Операции с файлами на стороне Linux (виртуальный диск ext4) быстрые. Ядро Linux обрабатывает свою файловую систему напрямую, и ускорения до 20 раз относительно WSL1 для распаковки tar и в 2–5 раз для git clone и npm install уже сообщали.⁴
• Операции с файлами на стороне Windows (/mnt/c и подобные) медленнее, потому что идут через общий доступ к файлам через границу ОС. Производительность через файловые системы ОС — одна крупная область, где WSL2 отстаёт от WSL1.⁴

Поэтому правило: кладите файлы проекта на ту же сторону ОС, что и инструменты, которые с ними работают.⁴ Репозиторий, которым занимаются инструменты сборки Linux, — на сторону Linux; решение, которое собирает Visual Studio, — на сторону Windows.

flowchart TB
    accTitle: Развилка путей файлового ввода-вывода WSL2
    accDescr: Доступ к виртуальному диску ext4 на стороне Linux быстрый, потому что ядро Linux доходит до него напрямую, а доступ к файлам на стороне Windows медленный, потому что идёт через общий доступ через границу ОС
    io["Операция с файлом внутри WSL2"] --> place{"На какой стороне файл?"}
    place -->|"Сторона Linux (домашний каталог и т.п.)"| ext4["Прямой ввод-вывод к виртуальному диску ext4"]
    place -->|"Сторона Windows (/mnt/c и т.п.)"| p9["Через общий доступ через границу ОС"]
    ext4 --> fast["Быстро (в одном примере до 20 раз относительно WSL1)"]
    p9 --> slow["Склонен быть медленным"]
    slow -.-> fix["Исправление: положить файл на ОС, которая им пользуется"]

Рис. 5: Медленный путь, а не WSL2, поэтому просто смена места файлов часто заставляет проблему производительности исчезнуть.

3.3. Память: растёт, уменьшается, но возвращает не всё

Потребление памяти WSL2 (в Диспетчере задач видно как процесс vmmem) — не фиксированный резерв; оно растёт и уменьшается по факту использования.

Возврат памяти, которую процессы освободили

Память, которую процессы освободили, возвращается Windows автоматически при параметре pageReporting, который включён по умолчанию.⁵

Возврат файлового кэша

Страницы, удерживаемые как файловый кэш, когда-то не возвращались Windows, пока ВМ не завершалась.⁴ В актуальном WSL экспериментальный параметр .wslconfig autoMemoryReclaim (по умолчанию dropCache) тоже автоматически возвращает кэш.⁵

В средах, где этот параметр disabled, или на старом WSL кэш длинной сессии может оставаться до завершения ВМ и давить на память хоста.

flowchart TB
    accTitle: Как память WSL2 растёт, уменьшается и возвращается
    accDescr: Растущий спрос внутри WSL2 поднимает потребление памяти ВМ, память, освобождённая процессами, возвращается Windows при pageReporting, который включён по умолчанию, файловый кэш автоматически возвращает autoMemoryReclaim по умолчанию, но если они выключены или WSL старый, она остаётся до завершения ВМ, а wsl shutdown возвращает всё
    grow["Спрос на память внутри WSL2 растёт"] --> vm["Потребление vmmem растёт"]
    vm --> freed{"Эту страницу освободили?"}
    freed -->|"Освободил процесс (при включённом pageReporting)"| ret["Автоматически возвращается Windows"]
    freed -->|Удерживается как файловый кэш| amr["Автоматически возвращает autoMemoryReclaim (по умолчанию)"]
    amr -.-> old2["Остаётся до завершения ВМ, если выключено или WSL старый"]
    old2 --> sd["wsl --shutdown возвращает всё"]

Рис. 6: То, что выглядит как «только растёт», в основном кэш (при выключенном pageReporting остаётся и память, освобождённая процессами), поэтому узнайте пути возврата, прежде чем называть это утечкой.

Задать потолок памяти

Если нужен явный потолок, %UserProfile%\.wslconfig управляет памятью, числом процессоров и подкачкой ВМ целиком.⁵

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

После смены настроек перезапустите ВМ через wsl --shutdown, чтобы они вступили в силу. Это динамическое выделение, где настройка решает потолок, а спрос — фактическое использование, Windows Sandbox, который идёт дальше, проводит ещё дальше.

4. Windows Sandbox — использовать Windows хоста ещё раз

Лёгкость Sandbox раскладывается на три части: совместное использование файлов ОС на диске, совместное использование страниц ОС в ОЗУ и согласование выделения памяти с хостом.

4.1. Динамический базовый образ: полноценный Windows в 500 МБ

Windows Sandbox — одноразовый рабочий стол Windows, изолированный гипервизором. Закроете — всё исчезает; в следующий раз он стартует за секунды из чистого состояния.¹

Первая загадка — диск. Он может загрузить полноценный Windows, и всё же базовый образ Sandbox после установки — всего около 500 МБ, а сжатый для распространения — 30 МБ.² Секрет — динамический базовый образ.

• Большинство файлов ОС неизменяемы и могут совместно использоваться как есть с хоста.
• Только небольшое число изменяемых файлов совместно использовать нельзя, поэтому чистую копию держат внутри базового образа.
• При старте неизменяемые файлы хоста и локальные копии изменяемых файлов собираются в полный образ Windows.²

Иными словами, Sandbox ни скачивает, ни хранит копию Windows; он стартует, повторно используя Windows, уже установленный на хосте.

flowchart TB
    accTitle: Как собирается динамический базовый образ
    accDescr: Неизменяемые файлы ОС хостового Windows совместно используются, только изменяемые файлы держат как чистую копию в базовом образе, и оба собираются в полный образ Windows Sandbox
    hostw["Полноценный Windows хоста"] --> imm["Неизменяемые файлы ОС (подавляющее большинство)"]
    hostw --> mut["Изменяемые файлы ОС (немного)"]
    imm -->|совместно используются как есть| img["Загрузочный образ Sandbox"]
    mut -->|держат чистую копию| img
    img --> boot["Загружается как полноценный Windows"]
    img -.-> size["Хранить нужно только около 500 МБ"]

Рис. 7: Не «держать ещё один Windows», а «собрать один из Windows хоста» — так выглядит отказ от дублирования диска.

Эта сборка как раз и делает возможным следующий жизненный цикл.

Заметьте, что отбрасывается локальное состояние внутри Sandbox.

Если в файле конфигурации .wsb сопоставить записываемую папку с хоста, изменения там остаются на стороне хоста.⁶

flowchart TB
    accTitle: Жизненный цикл Windows Sandbox
    accDescr: Запуск готовит чистый Windows за секунды, после проверки приложения или экспериментов закрытие отбрасывает всё состояние внутри Sandbox, так что следующий старт снова чистый, но изменения в записываемой папке хоста, сопоставленной как записываемая, остаются
    launch["Запуск (секунды)"] --> clean["Чистый Windows"]
    clean --> work["Проверка приложения или эксперименты"]
    work --> close2["Закрыть"]
    close2 --> discard["Отбросить всё состояние внутри Sandbox"]
    discard -.-> mapped["Изменения в сопоставленной записываемой папке остаются на хосте"]
    discard -->|следующий старт| launch

Рис. 8: Он может возвращаться в чистое состояние каждый раз, потому что изменяемая часть — одноразовая копия, и отбросить её — часть проекта.

4.2. Direct map: тот же ntdll.dll — та же физическая страница

Не только диск, но и ОЗУ совместно используется. Потому что Sandbox запускает тот же образ ОС, что и хост, применяется приём под названием «direct map», чтобы для двоичных файлов ОС использовать те же физические страницы памяти, что и хост. Когда ntdll.dll загружается в память внутри Sandbox, он указывает на те же физические страницы, что и тот же двоичный файл, загруженный на хосте.

Это даёт гораздо меньшее потребление памяти, чем традиционная ВМ, не подвергая секреты хоста риску.²

«Совместно использовать одну физическую страницу несколькими пользователями» — та же идея, что совместное использование DLL через объекты секций, которое мы разбирали в части 3 серии про память («Объекты секций и копирование при записи»). Тот механизм совместно использовал между процессами; Sandbox делает это через границу ВМ.

flowchart TB
    accTitle: Совместное использование физических страниц через direct map
    accDescr: Приложение на хосте и приложение внутри Sandbox совместно используют одни физические страницы памяти для двоичных файлов ОС вроде ntdll, снижая потребление памяти
    happ["Приложение на хосте"] --> hva["Виртуальный адрес на стороне хоста"]
    sapp["Приложение внутри Sandbox"] --> sva["Виртуальный адрес на стороне Sandbox"]
    hva --> phys["Та же физическая страница (двоичные файлы ОС вроде ntdll.dll)"]
    sva --> phys
    phys -.-> save["Не нужно дублировать долю ОС в ОЗУ"]

Рис. 9: Direct map берёт идею совместного использования страниц, давно применяемую между процессами, и применяет её через границу ВМ.

4.3. Память выделяется и возвращается: скорее процесс, чем ВМ

В отличие от статического выделения памяти традиционной ВМ, технология контейнеров под Sandbox решает выделение ресурсов динамически в согласовании с хостом. Если хосту не хватает памяти, он может вернуть память у контейнера так же, как возвращает её у обычного процесса.² Hyper-V Dynamic Memory тоже увеличивает и уменьшает выделение ВМ в настроенном диапазоне, но Sandbox идёт на шаг дальше: он совместно использует память на той же ноге, что и собственное управление памятью хоста.

flowchart TB
    accTitle: Согласование памяти между хостом и Sandbox
    accDescr: Традиционная ВМ по умолчанию резервирует статический размер с ограниченными средствами подстройки, а Sandbox становится целью возврата в ответ на давление памяти хоста и совместно использует память на той же ноге, что обычные процессы
    pressure["Давление памяти хоста растёт"] --> from{"Откуда возвращать?"}
    from --> proc["Рабочие наборы обычных процессов"]
    from --> sbx["То, чем пользуется Sandbox (контейнер)"]
    proc --> relief["Свободная память обеспечена"]
    sbx --> relief
    relief -.-> contrast["У традиционной ВМ средства подстройки ограничены"]

Рис. 10: Когда речь о совместном использовании памяти, Sandbox стоит на стороне процессов, а не ВМ, и отдаёт память, когда хост под давлением.

В части 1 мы говорили, что производительность ВМ зависит также от стороны хоста; у лёгких ВМ это идёт на шаг дальше, и само выделение памяти становится совместной работой с хостом. Это согласование — почему Sandbox ощущается меньше как «тяжёлое ПО виртуализации» и больше как ещё одно приложение.

Конкретные шаги использования Sandbox для проверки бизнес-приложений разобраны в более ранней статье «Как ускорить проверку приложений в Windows Sandbox». Эта статья покрывает механизм под ним.

5. Контейнеры — где провести линию изоляции

Здесь мы не судим безопасность по имени «контейнер» в одиночку; проверяем делит ли контейнер ядро с хостом или имеет своё ядро.

5.1. Изоляция процессов и изоляция Hyper-V

У контейнеров Windows два режима изоляции времени выполнения. Образ тот же; режим выбираете флагом при старте.⁷

• Изоляция процессов: несколько контейнеров делят ядро с хостом и изолированы виртуализацией по пространствам имён файловой системы, реестра, сетевых портов, пространства идентификаторов процессов, пространства имён диспетчера объектов и так далее. Это почти тот же подход, что контейнеры Linux.
• Изоляция Hyper-V: каждый контейнер работает внутри высоко оптимизированной ВМ и имеет по сути выделенное ядро. Наличие ВМ ставит изоляцию уровня оборудования между контейнерами и между ними и хостом.⁷

Изоляцию по пространствам имён можно видеть как доведённую версию приёма из статьи о виртуализации реестра («Перенаправление и виртуализация реестра в Windows»): показывать другую сущность под тем же API.

flowchart TB
    accTitle: Изоляция процессов против изоляции Hyper-V
    accDescr: При изоляции процессов контейнеры делят ядро с хостом и изолированы пространствами имён, а при изоляции Hyper-V у каждого контейнера выделенное ядро внутри оптимизированной ВМ
    subgraph pi ["Изоляция процессов"]
        c1["Контейнер A"] --> sk1["Ядро, совместно используемое с хостом"]
        c2["Контейнер B"] --> sk1
    end
    subgraph hi ["Изоляция Hyper-V"]
        c3["Контейнер C"] --> k3["Выделенное ядро (внутри оптимизированной ВМ)"]
        c4["Контейнер D"] --> k4["Выделенное ядро (внутри оптимизированной ВМ)"]
    end
    sk1 ~~~ c3

Рис. 11: Даже с тем же образом контейнера, проводится ли линия изоляции над ядром или само ядро отдельно, выбирается при старте.

5.2. Что можно назвать «границей безопасности»

Разница двух режимов — не только о производительности. Microsoft не считает контейнеры с изоляцией процессов надёжной границей безопасности. Контейнеры, которые поддерживают как границу безопасности (с обслуживанием уязвимостей), — изолированные гипервизором, и в враждебных мультитенантных сценариях изоляция Hyper-V — режим, который стоит выбирать.⁸

VBS, который мы видели в части 2, тоже проектировали из допущения «ядро может быть скомпрометировано», отступая к границе гипервизора. Тот же критерий держится в мире контейнеров. Линия, которая ограничивает недоверенный код, проводится на границе гипервизора, а не внутри совместно используемого ядра.

flowchart TB
    accTitle: Выбор изоляции по тому, насколько коду можно доверять
    accDescr: Доверенная нагрузка берёт плотность и производительность изоляцией процессов, а недоверенный код или чужой код получает границу гипервизора вроде контейнера с изоляцией Hyper-V, ужесточённого Windows Sandbox с отключённой сетью и подобным или изолированной ВМ
    trust{"Этому коду можно доверять?"} -->|Да| dens["Изоляция процессов (сначала плотность и скорость)"]
    trust -->|"Нет, или чужой код"| bound["Выбрать границу гипервизора"]
    bound --> opt1["Контейнер с изоляцией Hyper-V"]
    bound --> opt2["Ужесточённый Sandbox или изолированная ВМ"]

Рис. 12: Режим изоляции — вопрос безопасности раньше, чем производительности, и уровень доверия решает, куда идёт линия.

Примечание: внутри ВМ проверьте требования вложенной виртуализации

Запуск контейнеров с изоляцией Hyper-V внутри ВМ Hyper-V значит два слоя гипервизора: вложенная виртуализация.

Один уровень вложенности поддерживается в продакшене на средах, которые удовлетворяют условиям (хост Windows 10 / Windows Server 2016 или новее для процессоров Intel, хост Windows 11 / Windows Server 2022 или новее для процессоров AMD, плюс соответствующая версия конфигурации ВМ в каждом случае), и дополнительно требует настройки, которая открывает расширения виртуализации внешней ВМ (ExposeVirtualizationExtensions у Set-VMProcessor для Hyper-V).

Запуск WSL2 внутри ВМ поддерживается так же.⁹ Можно ли пользоваться WSL2 или Docker на ВМ разработки в облаке, тоже зависит от того, открывает ли этот размер и конфигурация ВМ вложенную виртуализацию.

flowchart TB
    accTitle: Структура вложенной виртуализации
    accDescr: Облачная ВМ сидит на гипервизоре физического хоста, а внутри неё работает ещё один гипервизор (вложенность поддерживается только на один уровень), чтобы поддержать WSL2 и контейнеры с изоляцией Hyper-V
    phys3["Гипервизор физического хоста"] --> cvm["Облачная ВМ (машина разработки)"]
    cvm --> nhv["Гипервизор внутри ВМ (первый уровень вложенности)"]
    nhv --> w2["WSL2"]
    nhv --> hvc["Контейнер с изоляцией Hyper-V"]
    nhv -.-> limit["Вложенность поддерживается только на один уровень"]

Рис. 13: Причина, по которой wsl работает внутри облачной ВМ, в том, что вложенная виртуализация официально поддерживается ровно на один уровень.

5.3. Спектр изоляции и лёгкости

Выстроив всё, что покрыто до сих пор, на одной оси, получаем следующее.

flowchart TB
    accTitle: Спектр силы изоляции и лёгкости
    accDescr: Контейнеры с изоляцией процессов самые лёгкие, но делят ядро; WSL2, Sandbox и контейнеры с изоляцией Hyper-V — лёгкие ВМ с выделенным ядром (Sandbox облегчён совместным использованием хоста, WSL2 — ядром, заточенным под задачу); полноценная ВМ самая тяжёлая, но универсальная
    ax["Лёгкое ← → Тяжёлое"] ~~~ p1
    p1["Контейнер с изоляцией процессов (совместно используемое ядро)"] --> p2["WSL2, Sandbox, изоляция Hyper-V (лёгкие ВМ с выделенным ядром)"]
    p2 --> p3["Полноценная ВМ (запускает что угодно, держит каждое дублирование)"]
    p1 -.-> n1["Граница: пространства имён"]
    p2 -.-> n2["Граница: гипервизор"]
    p3 -.-> n3["Граница: гипервизор + полная независимость"]

Рис. 14: Лёгкие ВМ — середина, которая сохранила границу гипервизора, срезав дублирование; как они срезают, различается: совместное использование у Sandbox и ядро, заточенное под задачу, у WSL2.

6. Посмотрите сами

Лёгкость и совместное использование можно наблюдать на своей машине.

6.1. Время запуска WSL2 и рост и уменьшение памяти

С открытым Диспетчером задач попробуйте следующее.

# Ощущение времени запуска (первый раз поднимает ВМ, со второго ещё быстрее)
Measure-Command { wsl -e true }

# Потребление памяти ВМ WSL2 (vmmem / Virtual Machine Memory)
Get-Process -Name vmmem* | Select-Object Name, WorkingSet64

# Завершить всю ВМ и посмотреть, как память возвращается
wsl --shutdown

Запустите большую сборку или файловую операцию внутри WSL2 — vmmem растёт; wsl --shutdown возвращает всё сразу, и это можно наблюдать.

6.2. Различия скорости от размещения файлов WSL2

Положите тот же репозиторий на сторону Linux (~/repo) и на сторону Windows (/mnt/c/repo), сравните время git status или распаковки — и разница из раздела 3.2 проявится числами.

6.3. Рост памяти на стороне хоста при старте Sandbox

Запустите Sandbox и смотрите рост памяти в Диспетчере задач хоста. То, что он остаётся гораздо меньше, чем предполагал бы «целый второй Windows», — эффект совместного использования.

Чтобы копнуть дальше в разбивку памяти на стороне хоста, полезна статья об инструментах Sysinternals, которая покрывает, как пользоваться RAMMap и VMMap («Process Explorer / Handle / VMMap на практике»).

Однако это инструменты для классификации процессов и физической памяти на стороне хоста; они не наблюдают напрямую само совместное использование с гостем.

6.4. Различия режимов изоляции контейнеров Windows

Если у вас есть среда контейнеров Windows, запустите тот же образ через docker run --isolation=process и через --isolation=hyperv, затем сравните время запуска и то, что показывает Диспетчер задач (при изоляции процессов процессы внутри контейнера появляются в списке процессов хоста), чтобы почувствовать, где сидит линия изоляции.⁷

Однако изоляция процессов требует совпадения версий хоста и образа, а на клиентской ОС ограничена использованием для разработки и теста. Изоляция Hyper-V допускает более широкий диапазон сочетаний, поэтому сравнение делайте на совместимой паре.¹⁰

7. Три ложных прочтения, которых избегать на практике

7.1. «WSL2 медленный»

Медленный не WSL2, а путь файлового ввода-вывода через границу ОС. Во многих случаях просто перенести проект на сторону Linux преображает опыт.⁴ Наоборот, класть файлы, которые трогают инструменты Windows, на сторону Linux — недостаток по той же причине. Решайте по «класть на ту же ОС, что и то, что им пользуется».

7.2. «Рост vmmem — это утечка памяти»

Память WSL2 растёт и уменьшается по спросу, и освобождённая память возвращается. На актуальном WSL autoMemoryReclaim (по умолчанию dropCache) также автоматически возвращает файловый кэш, поэтому «осталось большим» обычно разрешается со временем.⁵

Если всё ещё остаётся, проверьте, что autoMemoryReclaim не disabled и что pageReporting, который возвращает освобождённую память, не выключен (и что вы не на старом WSL); затем либо задайте явный потолок через memory в .wslconfig, либо верните всё через wsl --shutdown в конце сессии.

Подход к решению, утечка ли это, тот же, что во вводной части серии про память, «Как читать «использование памяти» в Windows».

7.3. «Это в контейнере, значит безопасно»

Контейнеры с изоляцией процессов делят ядро, и по стандарту Microsoft это не граница безопасности.⁸ Для запуска недоверенного кода или образцов выбирайте изоляцию, у которой есть граница гипервизора: контейнер с изоляцией Hyper-V, Windows Sandbox или выделенная ВМ.

Граница гипервизора, однако, не универсальный пропуск.

Настройки Windows Sandbox по умолчанию имеют включённую сеть, что может выставить недоверенное приложение во внутреннюю сеть.¹ Если пользуетесь им для запуска образцов, либо усильте изоляцию, отключив сеть и перенаправление буфера обмена в файле конфигурации .wsb, либо используйте выделенную ВМ в изолированной сети.

8. Итог — закрытие серии

Ключевые пункты части 3.

• Лёгкость лёгких ВМ — результат «перестали дублировать», а не «ослабили изоляцию».
• WSL2 запускает настоящее ядро Linux в управляемой лёгкой служебной ВМ, а дистрибутивы изолированы как контейнеры внутри этой ВМ.³ Правило производительности — класть файлы на ОС, которая ими пользуется; память растёт и уменьшается динамически, а .wslconfig управляет потолком.⁴⁵
• Windows Sandbox совместно использует неизменяемые файлы ОС хоста через динамический базовый образ и физические страницы применимых двоичных файлов ОС через direct map, поэтому не держит копию полноценного Windows.² Около 500 МБ изменяемых файлов и память приложений, которые вы запускаете внутри, всё равно нужны отдельно.
• Режим изоляции контейнера выбирается при старте, и сторона, которую можно назвать границей безопасности, — изоляция Hyper-V.⁷⁸

И вся серия на одной странице даёт это.

• Часть 1: Под Windows есть слой гипервизора, и хостовая ОС сама работает как корневой раздел. Этот слой напрямую арбитрирует ЦП и память (SLAT), а ввод-вывод синтетических устройств посредничает корневой раздел (VSP) на дальнем конце VMBus.
• Часть 2: Этот слой используется не только чтобы изолировать ВМ друг от друга, но и чтобы провести границу сильнее ядра (VTL) внутри той же ОС. Безопасность Windows 11 по умолчанию построена поверх него.
• Часть 3: На том же слое срезание дублирования делает возможной «виртуальную машину, которая загружается за секунды». Линия изоляции сохранена, и это стало повседневным инструментом.

flowchart TB
    accTitle: Вся серия на одной картине
    accDescr: Гипервизор непосредственно на оборудовании — часть 1, разделение VTL0 и VTL1 внутри хостового Windows — часть 2, а лёгкость WSL2, Sandbox и изоляции Hyper-V на том же слое — часть 3, при этом контейнеры с изоляцией процессов делят ядро хоста, Sandbox облегчён совместным использованием, а WSL2 — ядром, заточенным под задачу
    hw3["Оборудование"] --> hv3["Гипервизор (часть 1)"]
    hv3 --> rp3["Хостовый Windows (разделение VTL — часть 2)"]
    hv3 --> lw3["WSL2, Sandbox, изоляция Hyper-V (часть 3)"]
    rp3 --> pc3["Контейнер с изоляцией процессов (совместно используемое ядро)"]
    lw3 -.-> mech3["Sandbox облегчён совместным использованием, WSL2 — ядром, заточенным под задачу"]

Рис. 15: Сложите три части — и получите общую картину того, что лежит под сегодняшним Windows.

Виртуализация больше не технология серверной, и не только для тех, кто поднимает ВМ. Под вашим Windows она тихо поддерживает и безопасность, и опыт разработки. Так обстоят дела сегодня.

Похожие статьи

• Глубины виртуализации Windows (часть 1) — где на самом деле работает ваш Windows: гипервизор и разделы
• Глубины виртуализации Windows (часть 2) — память, которую не видит даже ядро: как устроены VBS, HVCI и Credential Guard
• Глубины памяти Windows (часть 3) — объекты секций и копирование при записи: как устроены DLL и проецирование файлов
• Как ускорить проверку приложений в Windows Sandbox
• Перенаправление и виртуализация реестра в Windows

Смежные области консультирования

KomuraSoft LLC занимается настройкой сред разработки, которые используют WSL2 и контейнеры, проектированием сред проверки Windows-приложений и расследованием производительности и совместимости в виртуализованных средах.

• Разработка Windows-приложений
• Расследование сбоев и анализ причин
• Использование и миграция существующих активов
• Связаться с нами

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

WSL2 — это виртуальная машина?

Да. WSL2 запускает настоящее ядро Linux сборки Microsoft внутри лёгкой служебной ВМ. Самой ВМ управляет WSL за кадром, поэтому пользователю не приходится думать о настройках ВМ и ждать загрузки. Каждый дистрибутив Linux работает как изолированный контейнер внутри этой управляемой ВМ.

Почему операции с файлами в /mnt/c в WSL2 медленные?

Потому что доступ из ядра Linux WSL2 к файловой системе Windows идёт через общий доступ к файлам через границу ОС. Операции на файловой системе Linux (виртуальный диск ext4) быстрые, поэтому файлы проекта стоит держать на той же стороне ОС, что и инструменты, которые с ними работают.

Большое потребление памяти процессом vmmem — это утечка?

В большинстве случаев нет. Память WSL2 растёт и уменьшается по факту использования, а память, которую процессы освободили, возвращается Windows при включённом по умолчанию pageReporting. Кэш файлов в актуальном WSL тоже автоматически освобождает autoMemoryReclaim в .wslconfig (по умолчанию dropCache). Если эти параметры выключены или WSL старый, память может оставаться до завершения ВМ; тогда задайте верхнюю границу параметром memory или верните её командой wsl --shutdown.

Как Windows Sandbox запускает полноценный Windows с нескольких сотен мегабайт на диске?

Через динамический базовый образ. Неизменяемые файлы ОС берутся из Windows, уже установленного на хосте, а чистую копию держат только для небольшого числа изменяемых файлов. Так собирается полный загружаемый образ, не храня вторую копию Windows целиком.

Контейнеры безопаснее виртуальных машин?

Зависит от режима изоляции. При изоляции процессов контейнеры делят ядро с хостом, и Microsoft не считает это надёжной границей безопасности. Если запускаете недоверенный код, нужна изоляция Hyper-V: у каждого контейнера тогда своё выделенное ядро.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.