WSL2 on kenji.blog

Hyper-V против WSL2: сравнение технологий виртуализации на Windows

Sun, 13 Sep 2026 07:00:00 +0900

1. Введение: Эволюция виртуализации в Windows

Технологии виртуализации на платформе Windows претерпели кардинальные изменения за последние несколько десятилетий. Ранее доминировали гипервизоры 2-го типа от сторонних разработчиков (такие как VMware Workstation и VirtualBox), но с момента внедрения Microsoft «Hyper-V» в Windows Server 2008 гипервизоры 1-го типа стали встраиваться и в настольные ОС Windows 10/11.

В последние годы наибольшее внимание разработчиков привлекает «WSL2 (Windows Subsystem for Linux 2)». В то время как WSL1 полагалась на трансляцию системных вызовов, WSL2 использует технологию Hyper-V для создания «легковесной служебной ВМ» (Lightweight Utility VM), обеспечивая полную совместимость с Linux и значительный прирост производительности.

В этой статье мы подробно сравним и объясним с глубокими техническими деталями две мощные технологии виртуализации: полнофункциональную «Hyper-V» и ориентированную на разработчиков «WSL2», рассматривая их архитектуру, производительность (CPU, память, дисковый ввод-вывод), сетевую конфигурацию и оптимальные сценарии использования.

2. Базовая теория гипервизоров и сравнение архитектур

Для понимания технологий виртуализации необходимо разобраться в классификации типов гипервизоров (мониторов виртуальных машин, VMM).

2.1. Различия между гипервизорами 1-го и 2-го типа

Гипервизор — это программный слой, который абстрагирует доступ к оборудованию и позволяет нескольким операционным системам (гостевым ОС) выполняться одновременно на одной физической машине.

Тип 1 (Bare-metal, автономный): Выполняется непосредственно на оборудовании. Концепции хост-ОС не существует (строго говоря, может существовать управляющая ОС с привилегиями), имеет крайне низкие накладные расходы и обеспечивает высокую производительность и безопасность. Примеры: Hyper-V, VMware ESXi, Xen.
Тип 2 (Хостовый): Выполняется как приложение в хост-ОС (например, Windows или macOS). Все обращения к оборудованию проходят через хост-ОС, что увеличивает накладные расходы. Примеры: VMware Workstation, Oracle VirtualBox.

Hyper-V в Windows является чистым гипервизором 1-го типа. При включении Hyper-V фактически сама операционная система Windows, с которой взаимодействует пользователь, начинает работать внутри специальной виртуальной машины, называемой «корневым разделом» (Root Partition).

2.2. Детали архитектуры Hyper-V

Архитектура Hyper-V использует дизайн микроядра и основана на логических единицах изоляции, называемых разделами (Partitions).

graph TD
A["Оборудование (CPU, RAM, Диск, NIC)"] --> B["Windows Hypervisor (Кольцо -1)"]
B --> C["Корневой раздел (Windows OS)"]
B --> D["Дочерний раздел 1 (Windows VM)"]
B --> E["Дочерний раздел 2 (Linux VM)"]
C --> F["VMBus (Шина виртуальных машин)"]
D --> F
E --> F
C --> G["VID (Драйвер инфраструктуры виртуализации)"]
C --> H["VMWP.exe (Рабочий процесс)"]

Windows Hypervisor: Работает в состоянии процессора с наивысшим уровнем привилегий (Кольцо -1 или VMX Root Mode) и отвечает только за выделение памяти и планирование CPU. Он не содержит драйверов устройств.
Корневой раздел (Root Partition): Раздел, в котором работает хост-ОС Windows. Содержит все драйверы устройств и напрямую управляет оборудованием. Также предоставляет функции управления дочерними разделами (WMI-провайдеры, VMWP.exe и др.).
Дочерний раздел (Child Partition): Раздел, в котором работает гостевая ОС. Прямой доступ к оборудованию не разрешен, запросы на ввод-вывод (Synthetic I/O) отправляются в корневой раздел через логическую шину совместного использования памяти, называемую «VMBus».

2.3. WSL2 и устройство Lightweight Utility VM

WSL2 использует ту же базовую технологию гипервизора 1-го типа, что и Hyper-V, но задействует подмножество функций, называемое «Платформа виртуальных машин» (Virtual Machine Platform, VMP), которое отличается от полнофункциональных виртуальных машин Hyper-V.

«Легковесная служебная ВМ» (Lightweight Utility VM), применяемая в WSL2, полностью исключает эмуляцию устаревшего оборудования (такого как виртуальный BIOS или виртуальная материнская плата), присутствующую в традиционных ВМ.

graph TD
A["Хост-ОС Windows (Пользовательское пространство)"]
B["Файловая система NTFS"]
C["Сервер протокола 9P (Plan 9)"]
D["Легковесная служебная ВМ (Ядро Linux)"]
E["ext4.vhdx (Виртуальный диск)"]
F["Пользовательское пространство Linux (Дистрибутивы WSL2)"]
A --> C
C -->| Кросс-ОС обмен файлами | D
D --> E
D --> F

Главная особенность WSL2 — это скорость запуска и бесшовная интеграция с хост-ОС. Ядро Linux загружается менее чем за секунду, а доступ к файловой системе Windows (NTFS) осуществляется через протокол сетевой файловой системы 9P из Plan 9.

3. Подробный анализ производительности: Вычислительные ресурсы и ввод-вывод

Производительность виртуальной машины выражается как сумма накладных расходов в компонентах CPU, памяти и дискового ввода-вывода.

3.1. CPU и накладные расходы на переключение контекста

Hyper-V и WSL2 используют аппаратную виртуализацию (Intel VT-x / AMD-V). Инструкции процессора в основном выполняются с нативной скоростью, но при выполнении привилегированных инструкций или обработке ввода-вывода возникает прерывание «VM Exit», приводящее к переключению контекста на гипервизор.

Накладные расходы CPU $T_{overhead}$ в этот момент можно описать следующей математической моделью:

$$ T_{overhead} = \sum_{i=1}^{N} (t_{vm\_exit} + t_{hypercall\_process} + t_{vm\_entry}) $$

Где:

$N$: Количество возникновений VM Exit за единицу времени
$t_{vm\_exit}$: Время перехода от гостя к гипервизору
$t_{hypercall\_process}$: Время обработки ввода-вывода или прерываний через VMBus
$t_{vm\_entry}$: Время возврата от гипервизора к гостю

Поскольку в WSL2 отсутствует эмуляция устаревшего оборудования, параметр $t_{hypercall\_process}$ крайне мал и оптимизирован. Поэтому при чистых вычислениях на CPU (например, компиляция ядра или вывод моделей машинного обучения) снижение производительности по сравнению с bare-metal средой составляет в пределах нескольких процентов.

3.2. Механизм выделения памяти

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

Hyper-V (Динамическая память): В зависимости от потребностей гостевой ВМ в памяти корневой раздел динамически выделяет и возвращает память. Однако память, зарезервированная как страничный кэш (page cache) внутри гостевой ОС, обычно не освобождается, пока система не столкнется с нехваткой ресурсов.
WSL2 (Динамическое освобождение памяти): WSL2 имеет собственный механизм, который регулярно возвращает (Reclaim) ненужную память (включая кэш) из ВМ Linux хосту Windows. В ранних версиях WSL2 существовала проблема, когда страничный кэш Linux съедал память Windows (разрастание процесса Vmmem), но сейчас это исправлено патчами ядра.

3.3. Характеристики дискового ввода-вывода (VHDX против ext4.vhdx)

Дисковый ввод-вывод чаще всего становится узким местом в производительности виртуальных машин.

Задержка ввода-вывода (Latency) $L_{total}$ рассчитывается следующим образом:

$$ L_{total} = L_{guest\_fs} + L_{vmbus} + L_{host\_fs} + L_{physical\_disk} $$

В случае Hyper-V: Типичный гость Hyper-V использует виртуальный диск в формате VHDX. Запросы на ввод-вывод от файловой системы внутри гостевой ОС (ext4 или NTFS) проходят через драйвер блочного устройства хранилища VMBus (storvsc) и обрабатываются как доступ к файлу VHDX на NTFS на стороне Windows.

В случае WSL2: Дистрибутивы Linux в WSL2 работают на нативной файловой системе ext4, созданной внутри выделенного файла ext4.vhdx. Файловые операции внутри Linux (например, в директории ~) демонстрируют нативную производительность, эквивалентную Hyper-V, описанному выше. Однако когда осуществляется доступ из Linux в WSL2 к файлам на стороне Windows (например, /mnt/c/), или наоборот, процесс значительно отличается. Для этого кросс-ОС доступа используется 9P (Plan 9 File System Protocol).

$$ L_{cross\_os} = L_{9p\_client} + L_{socket\_transfer} + L_{9p\_server} + L_{ntfs} $$

Доступ через этот протокол 9P имеет высокие накладные расходы на сериализацию, поэтому производительность значительно падает (иногда в 10 и более раз) в сценариях, требующих массового чтения и записи небольших файлов (например, npm install или операции Git в проекте Node.js, расположенном в каталоге Windows). Поэтому при использовании WSL2 железное правило — всегда размещать файлы проекта в нативной файловой системе Linux (внутри ~/).

4. Сетевая структура: NAT, Default Switch, Bridged

Гибкость сетевых функций — одно из главных отличий между Hyper-V и WSL2.

4.1. Сеть WSL2 (На базе NAT)

Сеть WSL2 по умолчанию настроена как «NAT (Network Address Translation)», используя технологию виртуальных коммутаторов Hyper-V. ВМ Linux автоматически получает приватный IP-адрес (например, 172.20.x.x), отличный от адреса хоста Windows. Предусмотрен встроенный механизм переадресации, благодаря которому сервисы (порты), запущенные в WSL2, доступны с хоста Windows через localhost, что позволяет разработчикам тестировать веб-серверы, не задумываясь о сети.

Недавно в предварительных версиях WSL2 был представлен новый сетевой режим «Mirrored» (Зеркальный). Он улучшает поддержку IPv6 и совместимость с VPN-соединениями (настраивается в .wslconfig).

4.2. Виртуальный коммутатор Hyper-V (Virtual Switch)

Hyper-V позволяет создавать сложные сети корпоративного уровня. Через «Диспетчер виртуальных коммутаторов» доступны три основных режима:

Внешняя (External): Привязывает физическую сетевую карту (NIC) хост-машины к виртуальному коммутатору, подключая гостевую ВМ напрямую к физической сети (мостовое соединение). ВМ получает IP-адрес от DHCP-сервера в той же подсети, что и физическая сеть.
Внутренняя (Internal): Разрешает связь только между хост-ОС и ВМ, а также между самими ВМ. Прямой выход во внешнюю сеть невозможен.
Частная (Private): Разрешает связь только между ВМ и блокирует связь с хост-ОС. Используется для создания изолированных тестовых сред.

4.3. Продвинутая настройка сети Hyper-V с помощью PowerShell

Если вам нужно создать кастомизированную NAT-сеть для ВМ в среде разработки или тестирования, PowerShell предоставляет детальный контроль. Ниже приведен пример скрипта для создания внутреннего виртуального коммутатора, настройки на нем NAT и предоставления ВМ доступа в Интернет.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 1. Создание внутреннего виртуального коммутатора
$SwitchName = "HyperV-NatSwitch"
New-VMSwitch -SwitchName $SwitchName -SwitchType Internal

# 2. Настройка IP-адреса для виртуальной NIC хоста (IP, который станет шлюзом)
$GatewayIP = "192.168.100.1"
$NetPrefix = 24
$InterfaceAlias = "vEthernet ($SwitchName)"
New-NetIPAddress -IPAddress $GatewayIP -PrefixLength $NetPrefix -InterfaceAlias $InterfaceAlias

# 3. Настройка сети NAT
$NatName = "HyperV-NatNetwork"
$NatSubnet = "192.168.100.0/24"
New-NetNat -Name $NatName -InternalIPInterfaceAddressPrefix $NatSubnet

# Команда для проверки
Get-NetNat

С помощью этой конфигурации вы можете создать собственный сегмент NAT, который может взаимодействовать с внешним миром через хост, вручную назначив указанному гостю Hyper-V IP-адрес 192.168.100.x и шлюз 192.168.100.1.

5. Варианты использования и практическое руководство по выбору

Учитывая различия в архитектуре и производительности, описанные выше, определим, в каких ситуациях следует применять каждую из технологий.

5.1. Сценарии, когда следует выбрать WSL2

WSL2 специально разработан для «повышения продуктивности разработчиков». Он идеально подходит для следующих целей:

Веб-разработка и облачная (cloud-native) разработка: Разработка контейнеров с использованием Docker Desktop (бэкенд WSL2) или Podman.
Использование инструментов только для Linux: Если вы повседневно используете bash, grep, awk, sed или компиляторы GCC / Clang для Linux.
GUI-приложения (WSLg): Если вы хотите бесшовно запускать приложения X11/Wayland для Linux на рабочем столе Windows.
Машинное обучение и разработка ИИ: Быстрое обучение в TensorFlow или PyTorch с использованием функции проброса GPU (NVIDIA CUDA на WSL).

Примечание: Вы можете столкнуться с ограничениями, если вам нужно глубоко настроить ядро или если вы развертываете сложные сервисы, сильно зависящие от systemd (в настоящее время systemd поддерживается, но по умолчанию может быть отключен или иметь ограничения).

5.2. Сценарии, когда следует выбрать Hyper-V

Hyper-V предназначен для «виртуализации инфраструктуры и полной изоляции». Он обязателен для следующих задач:

Запуск ВМ Windows: При запуске различных версий Windows (например, Windows Server или старой Windows 10) в качестве среды тестирования.
Вложенная виртуализация (Nested Virtualization): Если вам нужно запустить виртуальную машину (Hyper-V или KVM) внутри другой виртуальной машины. Это незаменимо для сред тестирования инженеров инфраструктуры.
Сложные сетевые требования: Если вам нужен строгий контроль над конфигурацией сети, например, подключение внешнего моста (подключение к той же локальной сети), тегирование VLAN или назначение нескольких NIC.
Снапшоты (Контрольные точки): Функция сохранения состояния ВМ в определенный момент времени и возможности мгновенного отката в любой момент. Чрезвычайно полезно для разрушительного тестирования программного обеспечения или анализа вредоносных программ.
Фиксированное распределение ресурсов: Если вам нужно строго зафиксировать количество ядер CPU и объем памяти для минимизации влияния на хост-ОС.

6. Рассмотрение пропускной способности ввода-вывода с использованием математических моделей (Приложение)

Для системного инженера при оценке пределов производительности ввода-вывода обеих систем важно теоретически понимать взаимосвязь между пропускной способностью $S$ и размером блока $B$.

Пропускная способность передачи данных $S$ — это объем данных, переданных за единицу времени, которая моделируется следующим образом:

$$ S(B) = \frac{B}{L_{setup} + \frac{B}{R_{max}}} $$

$B$: Размер блока (Байты)
$L_{setup}$: Фиксированная задержка, связанная с настройкой запроса ввода-вывода и переключением контекста
$R_{max}$: Максимальная пропускная способность оборудования при копировании или передаче на устройство

При доступе к файлам через протокол 9P в WSL2 этот параметр $L_{setup}$ становится очень большим (из-за сокет-коммуникаций и сериализации/десериализации протокола). Таким образом, когда размер блока $B$ мал (массовое чтение/запись мелких файлов размером в несколько килобайт), влияние $L_{setup}$ в знаменателе становится доминирующим, и пропускная способность $S$ резко падает. И наоборот, при доступе к VHDX через VMBus в Hyper-V, параметр $L_{setup}$ оптимизирован почти до уровня аппаратных прерываний, что позволяет поддерживать высокие значения IOPS даже для небольших блоков.

Эта математическая реальность является логическим обоснованием лучшей практики, которая гласит: «В WSL2 нельзя размещать файлы проекта на стороне Windows».

7. Заключение: Две сосуществующие технологии виртуализации

Hyper-V и WSL2 — это не ситуация, когда одна технология превосходит другую; это «два решения с разными целями».

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

В современных средах Windows эти две технологии не конкурируют друг с другом, а прекрасно сосуществуют на одной платформе ВМ. Используя их по назначению в зависимости от задачи, вы сделаете Windows самой мощной и гибкой инженерной рабочей станцией в мире.

Идеальное руководство по настройке среды разработки WSL2 (Windows Subsystem for Linux)

Sat, 12 Sep 2026 23:00:00 +0900

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

В этой статье мы подробно, в объёме более 10 000 символов, рассмотрим все этапы создания “идеальной среды разработки”, востребованной профессиональными инженерами: начиная с объяснения архитектуры, лежащей в основе WSL2, и заканчивая настройками для максимальной производительности, созданием комфортной терминальной среды, бесшовной интеграцией с Docker и VS Code, а также расширенными сетевыми настройками.

1. Архитектура WSL2 и эволюция от WSL1

Чтобы полностью раскрыть потенциал WSL2, важно сначала понять её внутреннюю структуру. В оригинальной WSL (WSL1) и WSL2 подходы к запуску бинарных файлов Linux на Windows принципиально отличаются.

WSL1: Слой трансляции системных вызовов

WSL1 использовала механизм трансляции (перевода) системных вызовов Linux в API Windows NT в реальном времени. Поскольку виртуальная машина (ВМ) не использовалась, преимуществом были очень низкие накладные расходы на ресурсы. Однако было сложно полностью эмулировать сложные системные вызовы, такие как операции ввода-вывода файловой системы, что приводило к катастрофическому падению производительности при обработке большого количества мелких файлов, особенно в таких задачах, как npm install в Node.js или операции с репозиториями Git.

WSL2: Легковесная служебная ВМ и полноценное ядро Linux

В WSL2 архитектура была полностью переработана: теперь настоящее ядро Linux, собранное Microsoft, работает напрямую на “легковесной служебной ВМ” (Lightweight Utility VM), использующей подмножество архитектуры Hyper-V. Это гарантирует 100% совместимость системных вызовов, а использование виртуального диска (VHDX) с нативной файловой системой Linux ext4 кардинально повысило производительность файлового ввода-вывода по сравнению с WSL1.

Следующая диаграмма Mermaid показывает структурные различия между WSL1 и WSL2.

flowchart TD
subgraph "Среда ОС Windows"
A["Ядро Windows NT"]
A --> F["Файловая система NTFS (Диск C:)"]
end
subgraph "Архитектура WSL2"
B["Гипервизор Hyper-V"]
B --> C["Легковесная служебная ВМ"]
C --> D["Ядро Linux (Microsoft)"]
D --> E["Пространство пользователя Ubuntu (glibc, bash и т.д.)"]
D --> G["Виртуальный диск ext4 (.vhdx)"]
end
A -.->|"Сетевой общий ресурс по протоколу Plan 9 (9P)"| D
style B fill:#f9f,stroke:#333,stroke-width:2px
style D fill:#bbf,stroke:#333,stroke-width:2px

Важный урок из этой структуры: “Доступ к файлам на стороне Linux (внутри VHDX) работает чрезвычайно быстро, но доступ к файлам на стороне Windows (/mnt/c/) очень медленный, так как осуществляется через протокол 9P”. Исходный код проекта обязательно должен располагаться в домашнем каталоге на стороне WSL (~).

2. Математический анализ производительности: Почему WSL2 такая быстрая?

Давайте количественно оценим прирост производительности WSL2 с использованием математической модели. Одной из самых ресурсоемких операций в разработке программного обеспечения является обработка большого количества файлового ввода-вывода (например, установка библиотек или сборка).

Общее время выполнения некоторого процесса $T_{total}$ выражается как сумма времени вычислений процессора $T_{compute}$ и времени дискового ввода-вывода $T_{io}$.

$$ T_{total} = T_{compute} + T_{io} $$

В случае WSL1 возникают накладные расходы на преобразование операций Linux в операции NTFS, поэтому время ввода-вывода моделируется следующим образом. Где $n$ — количество файловых операций, $t_{ntfs\_syscall_i}$ — время выполнения системного вызова на стороне Windows, а $t_{trans_i}$ — накладные расходы слоя трансляции.

$$ T_{wsl1\_io} = \sum_{i=1}^{n} (t_{ntfs\_syscall_i} + t_{trans_i}) $$

С другой стороны, в случае WSL2 ядро напрямую обращается к файловой системе ext4, поэтому накладные расходы составляют лишь незначительную задержку от виртуализации $t_{virt_i}$.

$$ T_{wsl2\_io} = \sum_{i=1}^{n} (t_{ext4_i} + t_{virt_i}) $$

В обычных файловых системах $t_{ext4} \ll t_{ntfs\_syscall} + t_{trans}$, поэтому когда $n$ очень велико (сотни тысяч файловых операций), разница во времени ввода-вывода между WSL1 и WSL2 растет экспоненциально.

Кроме того, если обозначить долю накладных расходов на вычисления CPU в виртуализированной среде как $\rho$, то благодаря современной аппаратной поддержке виртуализации (Intel VT-x / AMD-V) значение $\rho \approx 0.01 \sim 0.03$ (около 1–3%). Следовательно, даже в чисто вычислительных задачах производительность составляет от $97\% \sim 99\%$ и не уступает нативной среде Linux.

3. Установка и базовая настройка

В Windows 10/11 установка WSL2 стала очень простой. Достаточно открыть PowerShell от имени администратора и выполнить следующую команду.

1
2
3
4
5
6


# По умолчанию установит WSL2 и Ubuntu
wsl --install

# Для указания конкретного дистрибутива
# Можно проверить с помощью wsl --list --online
wsl --install -d Ubuntu-24.04

После установки и перезагрузки при первом запуске вам будет предложено создать имя пользователя UNIX и пароль. Этот пользователь не зависит от пользователя Windows и действителен только внутри WSL.

Если вы уже используете WSL1, вы можете конвертировать её в WSL2 с помощью следующей команды:

1
2
3
4
5


# Конвертировать существующий дистрибутив в WSL2
wsl --set-version Ubuntu 2

# Установить WSL2 по умолчанию для новых дистрибутивов
wsl --set-default-version 2

4. Секреты управления ресурсами: .wslconfig и wsl.conf

Одной из главных ловушек WSL2 является “безграничное потребление памяти (разрастание процесса Vmmem)”. Поскольку WSL2 использует страничный кэш ядра Linux, каждая операция ввода-вывода безостановочно поглощает память хоста (Windows). Чтобы предотвратить это, обязательно нужно ограничить ресурсы через файлы конфигурации.

Конфигурационные файлы WSL2 разделены на два типа: .wslconfig (влияет на всю Windows) и wsl.conf (влияет на внутреннюю часть каждого дистрибутива).

4.1. .wslconfig (на стороне Windows)

Создайте файл в каталоге профиля пользователя Windows (C:\Users\<Имя_пользователя>\.wslconfig), чтобы управлять выделением ресурсов для ВМ.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# C:\Users\<Имя_пользователя>\.wslconfig
[wsl2]
# Максимальный объем памяти, выделяемый ВМ. Рекомендуется около 50%–75% от общей памяти хоста.
memory=16GB

# Количество используемых ядер процессора (если не указано, используются все ядра).
processors=8

# Размер файла подкачки (swap).
swap=8GB

# Расположение файла подкачки (если хотите сэкономить место на диске C).
# swapfile=D:\\wsl\\swap.vhdx

# Включить переадресацию localhost (для доступа к WSL из Windows через localhost).
localhostForwarding=true

# Автоматически освобождать память (только для Windows 11).
# Динамически освобождает страничный кэш, предотвращая разрастание Vmmem.
autoMemoryReclaim=dropcache

[experimental]
# Расширенные сетевые функции, доступные в Windows 11 22H2 и новее.
# Включает поддержку IPv6 и использование одного и того же IP-адреса между WSL и Windows.
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

4.2. wsl.conf (на стороне Linux)

Отредактируйте /etc/wsl.conf внутри WSL, чтобы управлять поведением конкретного дистрибутива.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# /etc/wsl.conf (Редактируется внутри WSL)
[network]
# Отключить автоматическую генерацию /etc/resolv.conf при запуске WSL.
# Полезно, если вы хотите установить собственный DNS (например, 8.8.8.8).
generateResolvConf=false

# Установить собственное имя хоста.
hostname=WSL-DevNode

[automount]
# Настройки монтирования дисков Windows.
enabled=true
options="metadata,uid=1000,gid=1000,umask=022"
# Изменить точку монтирования диска C с /mnt/c на /c (сокращает пути).
root=/

[boot]
# Включить systemd (WSL 0.67.6 и новее).
# Позволяет нативно запускать snap и различные демоны (например, Docker).
systemd=true

[user]
# Пользователь для входа по умолчанию.
default=kenji

Чтобы применить эти настройки, необходимо выполнить команду wsl --shutdown в PowerShell, полностью остановить ВМ WSL, а затем перезапустить её.

5. Идеальная терминальная среда: Zsh + Powerlevel10k

bash по умолчанию не способствует высокой продуктивности. Мы создадим мощную строку приглашения, объединив Zsh, который может похвастаться мощным автодополнением и отличной читаемостью, со сверхбыстрой темой “Powerlevel10k”.

5.1. Установка и настройка Windows Terminal

Установите “Windows Terminal” из Microsoft Store. Откройте настройки JSON (settings.json), установите WSL (Ubuntu) в качестве профиля по умолчанию и измените шрифт на Nerd Font, подходящий для разработки (например, HackGen Console NF или MesloLGS NF).

5.2. Установка Zsh и Oh My Zsh

Выполните следующие команды в терминале WSL:

1
2
3
4
5
6


# Обновление пакетов и установка Zsh
sudo apt update && sudo apt upgrade -y
sudo apt install -y zsh git curl

# Запуск скрипта установки Oh My Zsh
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

5.3. Установка Powerlevel10k и плагинов

Мы установим плагины для дальнейшего расширения Zsh (подсветка синтаксиса и автодополнение ввода) и тему Powerlevel10k.

1
2
3
4
5
6
7
8


# Powerlevel10k
git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k

# zsh-autosuggestions
git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

# zsh-syntax-highlighting
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

Отредактируйте ~/.zshrc, чтобы включить тему и плагины:

1
2
3
4
5


# Изменения в ~/.zshrc
ZSH_THEME="powerlevel10k/powerlevel10k"

# Добавьте в массив плагинов
plugins=(git zsh-autosuggestions zsh-syntax-highlighting)

Сохраните изменения и выполните source ~/.zshrc, запустится мастер настройки Powerlevel10k (p10k configure). Следуйте инструкциям на экране, чтобы настроить строку приглашения на свой вкус (стиль приглашения, наличие иконок, отображаемая информация и т.д.). Имя ветки Git и статус, версия Node.js, время выполнения команд будут отображаться в реальном времени, что значительно повысит эффективность разработки.

6. VS Code Remote - Бесшовная интеграция с WSL

В разработке на WSL2 механизм бесшовного доступа к файлам внутри WSL из IDE (Visual Studio Code), установленной на Windows, обеспечивается расширением “Remote - WSL”.

Объяснение архитектуры

Следующая диаграмма последовательности показывает, как VS Code взаимодействует с WSL2.

sequenceDiagram
autonumber
participant U as "Разработчик"
participant V as "VS Code UI (Windows)"
participant S as "VS Code Server (WSL2)"
participant F as "Файловая система ext4 (WSL2)"
U->>V: "Ввести `code .` в терминале WSL"
V->>S: "Установить RPC-соединение через Vsock"
Note over V,S: Общение через сокеты Hyper-V вместо TCP/IP
S->>F: "Чтение исходных файлов / Запуск линтера"
F-->>S: "Возврат данных и результатов анализа"
S-->>V: "Потоковая передача результатов Language Server в интерфейс"
V-->>U: "Отображение подсветки синтаксиса и ошибок"

VS Code на стороне Windows работает как простой “тонкий клиент (UI)”, в то время как все тяжелые процессы, такие как Language Server, отладчик и выполнение терминала, обрабатываются “сервером VS Code” на стороне WSL. Благодаря этому вы можете поддерживать чистоту среды на стороне WSL без необходимости устанавливать Node.js или Python на Windows.

Обязательные настройки VS Code

Из раздела “Расширения” в VS Code установите “WSL” (ms-vscode-remote.remote-wsl). После этого просто перейдите в директорию вашего проекта в терминале WSL и выполните code ., и VS Code на стороне Windows запустится с открытой директорией.

Важное замечание (проблема символов переноса строки): Символы переноса строки в Windows и Linux отличаются (в Windows — CRLF, в Linux — LF). При разработке в WSL обязательно унифицируйте настройки core.autocrlf в Git и настройки файлов по умолчанию в VS Code на LF. Игнорирование этого приведет к загадочным ошибкам при выполнении скриптов оболочки или запуске контейнеров Docker.

1
2


# Настройка символов переноса строки Git на стороне WSL
git config --global core.autocrlf input

Также добавьте следующее в settings.json (Удаленные настройки) VS Code:

1
2
3
4


{
 "files.eol": "\n",
 "terminal.integrated.defaultProfile.linux": "zsh"
}

7. Docker Desktop и оптимизация интеграции с WSL2

В среде WSL2 существует два основных подхода к использованию Docker:

Установить Docker Desktop for Windows и включить функцию интеграции WSL2.
Установить нативный Docker Engine напрямую внутри WSL2 (например, Ubuntu).

Подход 1: Docker Desktop (рекомендуется)

Этот вариант рекомендуется в большинстве случаев из-за простоты управления через GUI и прозрачного доступа к контейнерам между Windows и WSL. Проверьте следующие настройки (Settings) в Docker Desktop:

Установите галочку General -> Use the WSL 2 based engine.
Перейдите в Resources -> WSL Integration -> установите галочку на Enable integration with my default WSL distro и включите переключатель для используемого дистрибутива (Ubuntu).

Теперь команду docker можно будет вызывать прямо из терминала WSL2, а связь с демоном Docker будет осуществляться через специальную легковесную ВМ (docker-desktop и docker-desktop-data), управляемую Docker Desktop.

Подход 2: Прямая установка нативного Docker Engine

Если у вас есть корпоративные сетевые ограничения (например, чтобы избежать платы за Docker Desktop) или вы хотите минимизировать накладные расходы до предела, включите systemd в /etc/wsl.conf и установите Docker напрямую, как на обычном сервере Ubuntu.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# Фрагмент официальной инструкции по установке Docker для WSL2 Ubuntu с включенным systemd
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Добавление репозитория
echo \
 "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
 "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
 sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Добавьте текущего пользователя в группу docker (чтобы запускать команды без sudo)
sudo usermod -aG docker $USER

После перезагрузки systemctl start docker будет работать точно так же, как в нативной среде Linux, обеспечивая высокую производительность.

8. Интеграция SSH ключей: Бесшовная аутентификация в Windows и WSL

При клонировании через SSH в Git или подключении к удаленным серверам управлять отдельными SSH-ключами для Windows и WSL очень неудобно. Чтобы совместить безопасность и удобство, мы настроим мост (переадресацию) от SSH-агента, работающего на стороне Windows (или менеджера паролей, такого как 1Password), в сторону WSL.

Здесь мы рассмотрим самый современный и безопасный подход: использование функции SSH-агента 1Password или OpenSSH Authentication Agent для Windows и переадресацию их в UNIX-сокет домена в WSL2 с помощью npiperelay и socat.

Переадресация сокета ssh-agent

Обычно SSH-агент в Windows предоставляется как Named Pipe (именованный канал), и его нужно преобразовать в файл сокета для WSL. Это легко сделать с помощью wsl-ssh-agent или функций, предлагаемых 1Password.

В настройках 1Password перейдите в “Developer” и включите “Использовать SSH-агент”. Затем добавьте следующие настройки в ~/.zshrc или ~/.bashrc на стороне WSL, чтобы автоматически привязывать сокет при входе в систему.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Добавление в ~/.zshrc (Пример при использовании SSH-агента 1Password)
export SSH_AUTH_SOCK=$HOME/.ssh/agent.sock
# Если сокет не существует при запуске WSL или процесс не привязан, используйте socat и npiperelay для переадресации
ALREADY_RUNNING=$(ps -aux | grep "[n]piperelay.exe -ei -s //./pipe/openssh-ssh-agent" | wc -l)
if [ $ALREADY_RUNNING -eq 0 ]; then
 if [ -S $SSH_AUTH_SOCK ]; then
 rm $SSH_AUTH_SOCK
 fi
 # Запустите socat в фоновом режиме, чтобы соединить Named Pipe Windows с UNIX-сокетом WSL
 (setsid socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork EXEC:"npiperelay.exe -ei -s //./pipe/openssh-ssh-agent",nofork &) >/dev/null 2>&1
fi

*Вам потребуется предварительно установить npiperelay.exe в Windows и добавить его в переменную среды PATH.

После завершения настройки при выполнении команды ssh-add -l в терминале WSL вы увидите список публичных ключей SSH, зарегистрированных в 1Password или на стороне Windows. Это позволяет безопасно проходить аутентификацию без необходимости копировать файлы секретных ключей внутрь WSL.

9. Обслуживание: Оптимизация (сжатие) раздутого VHDX

Один из самых больших недостатков WSL2 заключается в том, что “размер файла виртуального диска (.vhdx) в Windows не уменьшается автоматически даже после удаления образов Docker или удаления файлов”. В течение длительной разработки размер файла ext4.vhdx может вырасти до десятков или сотен гигабайт.

Чтобы освободить дисковое пространство, необходимо регулярно оптимизировать (Compact) VHDX со стороны Windows.

Сначала полностью завершите работу WSL:
1

wsl --shutdown
Откройте PowerShell с правами администратора и выполните следующую команду diskpart или команду Optimize-VHD из модуля Hyper-V (последняя доступна, только если включен Hyper-V).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Если доступен модуль Hyper-V
Optimize-VHD -Path "$env:LOCALAPPDATA\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx" -Mode Full

# При использовании diskpart
diskpart
# Введите команды интерактивно в открывшемся окне
DISKPART> select vdisk file="C:\Users\<Имя_пользователя>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx"
DISKPART> attach vdisk readonly
DISKPART> compact vdisk
DISKPART> detach vdisk
DISKPART> exit

Регулярно выполняя эту операцию, вы сможете вернуть впустую израсходованное пространство на диске C.

10. Заключение

WSL2 полностью переросла рамки “просто бонуса Linux для Windows” и превратилась в мощную платформу разработки, не уступающую, а порой и превосходящую MacOS или нативные компьютеры на Linux.

Применив все описанные здесь настройки (оптимизацию ресурсов через .wslconfig, улучшение терминала с помощью Zsh + Powerlevel10k, прозрачный доступ с помощью VS Code Remote, а также настройку интеграции SSH и обслуживание VHDX), вы получите “идеальную среду разработки” — быструю, безопасную и не вызывающую стресса.

Настройка среды требует некоторых усилий, но как только всё будет настроено, ваша продуктивность как инженера обязательно возрастет. Не стесняйтесь использовать это руководство в качестве основы и исследовать дальнейшие настройки в соответствии с требованиями ваших проектов и вашими предпочтениями.