WSL проти VirtualBox: коли WSL — неправильний інструмент

Проведіть лінію рішення: що ви насправді обираєте

Люди формулюють це як «WSL проти VirtualBox». Але це не фактичний вибір. Справжній вибір:

• Пісочниця для зручності проти керованої системи. WSL — це пісочниця для зручності, тісно інтегрована з Windows. VirtualBox дає вам керовану системну межу.
• Інтеграція з акцентом на Windows проти поведінки з акцентом на Linux. WSL оптимізований під цикл розробки на Windows. VirtualBox оптимізований під «поводиться як Linux на залізі», бо це саме так.
• Спільна доля проти явної долі. WSL більше залежить від хоста Windows: шляхи I/O файлів, проміжні мережеві шари, поведінка при тиску пам’яті, ритм оновлень, втручання корпоративних інструментів безпеки. VirtualBox також впливає хост, але радіус ураження легше проаналізувати.

Якщо ваше навантаження потребує контролю ядра, низькорівневих мережевих можливостей, передбачуваної семантики зберігання або можливості ставитися до гостьової системи як до окремої машини — за замовчуванням обирайте VM. Якщо ваше навантаження — переважно userland-інструменти і вам важлива інтеграція з Windows — за замовчуванням обирайте WSL.

Прагматичне правило: якщо ви плануєте відкривати баги, що починаються словами «На Linux це працює», вам, ймовірно, потрібен VirtualBox. Якщо план — «мені потрібні тільки shell, git і компілятор», обирайте WSL.

Факти та історичний контекст (те, що часто забувають)

• WSL 1 не був VM. Він транслював Linux-системні виклики у виклики Windows NT. Це робило його хитрим, швидким в деяких випадках і фундаментально несумісним в інших.
• WSL 2 перейшов на справжнє Linux-ядро. Це великий поворот: WSL 2 запускає ядро Linux, надане Microsoft, у легкій VM з використанням компонентів Hyper-V.
• VirtualBox старший за WSL на десятиліття. VirtualBox починався в Innotek, потім Sun, потім Oracle. Він достатньо старий, щоб вирішити рутинні проблеми, як-от «завантажити гостьову систему з передбачуваними пристроями».
• Hyper-V і VirtualBox мають спільну історію. Протягом років вони конкурували за функції апаратної віртуалізації. Сучасний VirtualBox може працювати на хостах із увімкненим Hyper-V, але продуктивність і взаємодії функцій все ще можуть бути… пікантними.
• Файлова модель WSL навмисно розділена. Linux-файли, що зберігаються всередині віртуального диска WSL, поводяться інакше, ніж Windows-файли, змонтовані під /mnt/c. Ця відмінність не косметична; це лінія продуктивності й коректності.
• Корпоративні інструменти безпеки змінили правила гри. Endpoint-protection та DLP-агенти інспектують операції з файлами й мережевий трафік. Шляхи інтеграції WSL можуть підсилювати це навантаження так, як не робить образ VM-диска.
• VirtualBox став стандартною підкладкою для dev-VM для покоління розробників. Інструменти як Vagrant популяризували «одна VM на проект». Це очікування добре співпадає з VirtualBox і менш органічно з WSL.
• Підтримка systemd у WSL з’явилася пізніше. Ранні користувачі WSL мусили тимчасово вирішувати питання ініціалізації. Сучасний WSL може запускати systemd, але це не перетворює миттєво WSL на «сервер».
• Мережеві очікування розійшлися. VirtualBox дає класичні режими NIC (NAT, bridged, host-only). WSL 2 використовує NAT-мережу з Windows як посередником, що впливає на вхідні підключення і видимість пакетів.

Архітектурні відмінності, що мають значення

WSL 2: легка VM, яка не хоче відчувати себе VM

WSL 2 запускає ядро Linux у керованій VM. Microsoft зробив складну роботу, щоб вам не доводилося думати про BIOS, контролери дисків і послідовності завантаження. У цьому і привабливість. Але той самий «керований» підхід означає, що ви не отримуєте доступу до багатьох важливих налаштувань, які мають значення під час діагностики продуктивності, мережі або зберігання.

Основні відмінності, які ви відчуєте:

• Межа файлової системи: Linux ext4-всередині-vhdx проти Windows NTFS, змонтованого в Linux під /mnt. Різні характеристики продуктивності; різна поведінка спостерігачів файлів; різна семантика метаданих при навантаженні.
• Межа мережі: WSL 2 за замовчуванням знаходиться за NAT, при цьому Windows виконує маршрутизацію і проброс портів. Вхідні підключення, multicast і очікування «просто прив’яжися до 0.0.0.0» можуть поводитися дивно.
• Управління ресурсами: VM WSL збільшує пам’ять за потреби й не завжди звільняє її, як ви очікуєте, якщо не налаштувати. Зручно — поки не стане ні.
• Очікування щодо ядра/модулів: Ви запускаєте ядро Microsoft. Ви не можете вільно завантажувати довільні модулі ядра, як на звичайній інсталяції дистрибутива.

VirtualBox: звична VM з звичними компромісами

VirtualBox — це «комп’ютер у вікні». Ви отримуєте явний віртуальний апарат і більш передбачувану поведінку гостя. Ви також отримуєте накладні витрати, обмеження емульованих пристроїв і щоденні турботи про життєвий цикл VM: оновлення, знімки, зміна розміру диска та налаштування мережі.

Але коли щось ламається, VirtualBox ламається так, що його можна проаналізувати: неправильно налаштований режим NIC, уповільнений диск I/O, не створений host-only інтерфейс, відсутні guest additions. Це нудні відмови. Нудні відмови — виживані.

Одна перефразована думка, яку варто тримати на стікері, приписана Werner Vogels: Усе ламається; будуйте системи, які передбачають відмови й швидко відновлюються. (перефразована ідея)

Перший жарт, бо ми говоритимемо про мережу: NAT — як офісні светські розмови — добре для вихідних, незручно, коли хтось намагається почати справжню розмову.

Коли WSL — правильний інструмент

WSL блищить, коли ваша мета — бути продуктивним на Windows без підтримки повної VM. Це платформа для розробника, а не міні-датацентр.

Використовуйте WSL, коли хочете швидкої ітерації та тісної інтеграції з Windows

• CLI-інструменти розробника: git, ssh, curl, рантайми мов, менеджери пакунків, системи збірки.
• Текстові робочі процеси: редактори, лінтери, компілятори, юніт-тести, локальні скрипти.
• Контейнери (часто): Docker Desktop використовує WSL 2 як бекенд для Linux-контейнерів; для багатьох робочих процесів розробки це найпростіший шлях.
• Кросплатформена розробка: можна збирати артефакти для Linux з Windows без подвійного завантаження.
• Низькоризикові локальні сервіси: запуск розробницької бази даних або кешу може бути прийнятним, якщо ви не ставите це як продуктивний стандарт.

«Добре дивні» можливості WSL

• Когерентний доступ до Windows: ви можете викликати Windows-екзешники з WSL і навпаки. Це не «Linux-подібно», але надзвичайно корисно.
• Миттєва інсталяція: можна підготувати дистрибутив за хвилини без ISO або менеджера VM.
• Менше операційного навантаження: немає життєвого циклу гостя у тому вигляді, як у повній VM; менше частин, які потрібно патчити вручну.

WSL — відмінний вибір за замовчуванням для локальної розробки, якщо ви тримаєте файли проекту всередині файлової системи WSL (не на /mnt/c) і погоджуєтеся, що деякі «справжні» Linux-припущення можуть не виконуватися.

Коли WSL — не той інструмент (і VirtualBox перемагає)

Якщо вам потрібна «машина», а не «shell», WSL починає показувати шви. Ось випадки, що змінюють рішення.

1) Вам потрібна поведінка на рівні ядра, модулі або низькорівнева спостережливість

Якщо ви працюєте з eBPF, розробкою модулів ядра, кастомними потоками iptables/nftables, які очікують повного контролю, або будь-чим, що потребує певної конфігурації ядра: використовуйте реальну VM. Ядро в WSL реальне, але воно не ваше. Ви не отримуєте повної паритетності з дистрибутивним ядром і не можете очікувати можливості завантажувати все, що схочете.

2) Вам потрібні передбачувані вхідні підключення, L2-поведінка або семантика «справжнього хоста»

Режим bridged у VirtualBox дає гостю адресу у вашій LAN. Це все ще віртуалізовано, але узгоджується з «це інша машина». NAT-модель WSL 2 підходить для вихідних підключень і localhost-розробки. Вона менш придатна, коли потрібен вхідний доступ від інших пристроїв, виявлення multicast або захоплення пакетів, яке має бачити правду.

3) Потрібно тестувати завантаження, init або повний життєвий цикл ОС

Тестування systemd-юнітів, порядку завантаження, cloud-init, шифрування диска при завантаженні або змін в командному рядку ядра? Використовуйте VirtualBox. WSL покращився (включно з підтримкою systemd), але його життєвий цикл все ще «WSL-інстанс як кероване середовище», а не «сервер, із яким можна поводитися як з худобою».

4) Ваше навантаження чутливе до зберігання або коректності

WSL швидкий, коли ви працюєте з файлами всередині його Linux-файлової системи. Він може бути болісно повільним, коли ви виконуєте інтенсивні операції з файлами на Windows-змонтованих шляхах. Повільний шлях — це не баг; це межа. Якщо ваше навантаження потребує великих клонів репозиторіїв, масивних node_modules або баз даних з передбачуваними fsync-семантиками, плануйте навколо цієї межі або переходьте на VM.

5) Потрібен USB passthrough або доступ до апаратури

VirtualBox має зрілу підтримку USB passthrough (з extension pack) і доволі традиційну історію підключення пристроїв до гостя. WSL має деякі варіанти через USB/IP, але це не те саме. Якщо ви перепрошиваєте пристрої, працюєте з донглами, серійними адаптерами або робите embedded-розробку: VirtualBox зазвичай чистіше.

6) Потрібна сильна ізоляція від корпоративних інструментів захисту

Незручна правда: інструменти безпеки часто трактують WSL як «ще один спосіб доступу до Windows-файлів». Це може означати додаткове сканування під час збірки або розпакування великої кількості дрібних файлів на /mnt/c. Образ диска VirtualBox може бути більше ізольованим, бо хост бачить переважно великі послідовні читання/записи до одного файлу, а не бурю операцій з файлами.

7) Потрібна стабільна відтворюваність для команди

WSL достатньо відтворюваний для багатьох команд розробки, але він все ще прив’язаний до версій Windows, версій WSL і інколи тонкої інтеграційної поведінки. VM у VirtualBox можна більш явно зафіксувати: відомий ISO, відома версія guest additions, відоме віртуальне обладнання, відомий режим мережі. Це важливо, коли «працює на моїй машині» коштує реальних грошей.

Другий жарт, бо зберігання завжди заслуговує на жарт: «Працювало, поки ми не поклали репозиторій на /mnt/c» — це сучасна версія «працювало на моєму ноуті», тільки з більшою кількістю системних викликів.

Практичні завдання: команди, виводи та рішення

Ви не обираєте інструменти за відчуттями. Ви обираєте їх за вимірюванням вузького місця і перевіркою припущень, які зазвичай підводять: шлях файлової системи, режим мережі, тиск пам’яті та межі хост/гость. Нижче — практичні виконувані команди з прикладами виводів і що з цього вирішувати.

Завдання 1: Підтвердити версію WSL і стан дистрибутива

cr0x@server:~$ wsl.exe --list --verbose
  NAME              STATE           VERSION
* Ubuntu-22.04      Running         2
  Debian            Stopped         2

Що це означає: Ви на WSL 2 (ядро в VM). Якщо ви очікували семантику WSL 1 (трансляція системних викликів), зупиніться. Ваш шлях усунення неполадок буде іншим.

Рішення: Якщо ваша проблема стосується ядра/модулів/мережевого стеку, розглядайте WSL як керовану VM з обмеженнями. Не припускайте, що можна «просто підкрутити ядро».

Завдання 2: Визначити, де знаходяться файли проекту (WSL ext4 vs Windows mount)

cr0x@server:~$ pwd
/mnt/c/Users/alex/work/myapp

Що це означає: Ви збираєте на файловій системі Windows через DrvFs. Для інтенсивних операцій з файлами це повільна смуга.

Рішення: Якщо збірки/тести повільні, перемістіть репозиторій у файлову систему WSL (наприклад, /home/alex) перед тим, як звинувачувати компілятори, Node або «WSL повільний».

Завдання 3: Виміряти тип файлової системи та опції монтажу всередині WSL

cr0x@server:~$ mount | head -n 6
none on / type lxfs (rw,noatime)
none on /mnt/wsl type tmpfs (rw,nosuid,nodev,noexec,relatime)
C:\ on /mnt/c type 9p (rw,noatime,aname=drvfs;path=C:\;uid=1000;gid=1000;metadata;case=off)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,size=1632048k,mode=755)

Що це означає: Диск Windows змонтовано через механізм на базі 9p. Це межа, яка може знищити навантаження з великою кількістю дрібних файлів.

Рішення: Якщо ваше навантаження чутливе до операцій метаданих (git status, npm install, yarn, pip, composer), тримайте його поза /mnt/c.

Завдання 4: Швидкий стрес-тест дрібних файлів (діагностика межі)

cr0x@server:~$ time bash -lc 'rm -rf /tmp/iotest && mkdir -p /tmp/iotest && for i in $(seq 1 20000); do echo $i > /tmp/iotest/f$i; done'

real    0m2.941s
user    0m0.715s
sys     0m2.147s

Що це означає: Це ваш базовий вимір всередині Linux-файлової системи.

Рішення: Запустіть той же тест під /mnt/c. Якщо він значно повільніший — ваша «проблема продуктивності WSL» насправді проблема шляху.

Завдання 5: Повторити стрес-тест на /mnt/c і порівняти

cr0x@server:~$ time bash -lc 'rm -rf /mnt/c/Temp/iotest && mkdir -p /mnt/c/Temp/iotest && for i in $(seq 1 20000); do echo $i > /mnt/c/Temp/iotest/f$i; done'

real    0m38.772s
user    0m2.105s
sys     0m15.883s

Що це означає: Ви платите накладні витрати на перетин межі для кожного файлу. Помножте це на менеджери пакунків, і все стає погано.

Рішення: Перемістіть навантаження у ext4 WSL або використайте VM з нативною Linux-файловою системою для цього навантаження. Не «оптимізуйте» прапорці компілятора, щоб виправити межу файлової системи.

Завдання 6: Перевірити тиск пам’яті і чи WSL запасає RAM

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       6.1Gi       431Mi       152Mi       1.2Gi       1.1Gi
Swap:          2.0Gi       1.4Gi       612Mi

Що це означає: VM WSL під тиском і використовує swap. Це часто відчувається як «все повільно», включно з I/O і мережею.

Рішення: Якщо вам потрібні стійкі пам’ятно-інтенсивні навантаження, розгляньте налаштування лімітів WSL або переміщення навантаження в VM з явним розміром RAM. Swap у розробці — це звук, що краде ваш післяобідній час.

Завдання 7: Перевірити ядро WSL і очікування щодо функцій (systemd, модулі)

cr0x@server:~$ uname -a
Linux cr0x 5.15.133.1-microsoft-standard-WSL2 #1 SMP Wed Oct 11 19:10:13 UTC 2023 x86_64 GNU/Linux

Що це означає: Ви запускаєте варіант ядра WSL. Воно легітимне, але не є точною збіркою ядра вашого дистрибутива.

Рішення: Якщо вам потрібна конкретна версія/конфігурація ядра (наприклад для функцій eBPF, поведінки LSM або доступності модулів), не ризикуйте. Використовуйте VirtualBox з дистрибутивним ядром, яким ви керуєте.

Завдання 8: Діагностика вхідної досяжності (реальність NAT у WSL)

cr0x@server:~$ ip addr show eth0 | sed -n '1,8p'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:3a:7c:11 brd ff:ff:ff:ff:ff:ff
    inet 172.28.96.15/20 brd 172.28.111.255 scope global eth0
       valid_lft forever preferred_lft forever

Що це означає: Ваша інстанція WSL знаходиться в приватній NAT-мережі (172.28.x.x). Інші пристрої LAN не дістатися до неї напряму.

Рішення: Якщо вам потрібні підключення від інших машин до сервісів у Linux без хитрощів з порт-проксі, обирайте VirtualBox з bridged-режимом мережі.

Завдання 9: Перевірити, що Windows думає про режим мережі вашої VirtualBox VM (підказка з гостя)

cr0x@server:~$ ip route
default via 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 100
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15

Що це означає: Той 10.0.2.2 gateway — класичний VirtualBox NAT.

Рішення: Якщо потрібен вхідний доступ з вашої LAN, NAT — неправильний режим. Перейдіть на bridged або host-only + явний роутинг залежно від потреб.

Завдання 10: Підтвердити bridged-мережу на гості VirtualBox

cr0x@server:~$ ip addr show enp0s3 | sed -n '1,8p'
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.77/24 brd 192.168.1.255 scope global dynamic noprefixroute enp0s3
       valid_lft 7200sec preferred_lft 7200sec

Що це означає: VM у тій же LAN, що й хост. Інші пристрої можуть досягти її, а виявлення сервісів працює нормально.

Рішення: Для лабораторій, тестування з декількома вузлами або вхідних сервісів це часто найчистіша конфігурація.

Завдання 11: Перевірити використання диска і сюрприз «vhdx у WSL ніколи не зменшується»

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc       1007G   96G  861G  11% /

Що це означає: Всередині WSL у вас може бути багато вільного місця. На Windows підкладний vhdx може залишатися величезним після видалень.

Рішення: Якщо диск Windows заповнюється, необхідно звільнити місце на рівні віртуального диска (експорт/імпорт або компактування). Якщо вам потрібна передбачувана поведінка росту диска, VM з явним управлінням віртуальним диском може бути простішою в операціях.

Завдання 12: Підтвердити, чи systemd справді PID 1 у WSL

cr0x@server:~$ ps -p 1 -o comm=
systemd

Що це означає: systemd запускається як init. Якщо там init або щось інше, ваші очікування щодо управління сервісами можуть бути помилковими.

Рішення: Якщо ваш стек покладається на systemd-юнити й таймери, переконайтеся, що systemd увімкнено; інакше використайте VM і перестаньте торгуватися з init.

Завдання 13: Перевірити можливість прив’язки й доступу до сервісу з Windows-хоста (інтеграція localhost WSL)

cr0x@server:~$ python3 -m http.server 8080
Serving HTTP on 0.0.0.0 port 8080 (http://0.0.0.0:8080/) ...

Що це означає: Сервіс слухає. Зазвичай Windows може дістатися до нього через localhost:8080 завдяки інтеграції WSL.

Рішення: Якщо Windows бачить сервіс, а інші пристрої LAN — ні, це NAT у WSL за дизайном. Вирішіть, чи потрібна доступність у LAN; якщо так — розгляньте bridged-VM.

Завдання 14: Діагностика DNS-проблем (WSL vs VM поводяться по-різному під VPN)

cr0x@server:~$ resolvectl status | sed -n '1,18p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 172.28.96.1
       DNS Servers: 172.28.96.1

Що це означає: DNS опосередкований. Під деякими корпоративними VPN-клієнтами це може ламати очікування split-DNS або спричиняти періодичні збої резолюції.

Рішення: Якщо DNS нестабільний і вам потрібна детерміністична мережа для лабораторії або CI-подібної поведінки, VM з власним NIC у bridged-режимі часто уникає цих дивних речей.

Швидка методика діагностики

Коли хтось каже «WSL повільний» або «мережа VirtualBox зламалася», у вас є близько п’яти хвилин, щоб уникнути дня забобонів. Ось стислений порядок дій, що швидко знаходить вузьке місце.

Перше: виявте межу, яку ви перетинаєте

• Де файли? Якщо проект під /mnt/c, спочатку припускайте накладні витрати файлової межі.
• Де мережа? Якщо IP гостя — приватний NAT-простір, спочатку припускайте проблеми з вхідною досяжністю.
• Де CPU? Якщо хост під навантаженням або VM обмежена, припускайте планування і тиск пам’яті.

Друге: запустіть три «чисті» перевірки

1. Перевірка файлової системи: Запустіть стрес-тест дрібних файлів в обох місцях. Велика різниця = проблема межі, а не «ваш додаток».
2. Перевірка пам’яті: Шукайте swap і низьку доступну пам’ять. Swap = усе бреше.
3. Перевірка мережі: Підтвердьте тип IP і маршрут. NAT vs bridged підказує, що можливе без хаків.

Третє: вирішіть, чи ви налагоджуєте додаток чи платформу

• Якщо відмова спричинена припущеннями про ядро/модулі, видимістю пакетів, вхідною мережею або семантикою зберігання: перейдіть на VirtualBox (або інший повноцінний гіпервізор).
• Якщо проблема — розміщення шляхів, налаштування ресурсів або відсутня інтеграційна опція: налаштуйте WSL і збережіть швидкий цикл розробки.

Коротка «карта вузьких місць»

• Повільні збірки/тести: зазвичай шлях файлової системи або накладне сканування endpoint-інструментами.
• Не можу дістатися до сервісу з іншої машини: WSL NAT; VirtualBox NAT; неправильний режим.
• VPN + DNS дивини: опосередкований DNS; вирішіть, чи потрібен справжній NIC.
• Зсув часу: синхронізація часу хоста (поширеніше у VM, ніж у WSL).
• «Працює на Linux, не тут»: невідповідність ядра/модулів/привілеїв; обирайте VM.

Типові помилки: симптом → корінна причина → виправлення

1) Симптом: npm/yarn/pip інсталяції повільні у WSL

Корінна причина: Репозиторій знаходиться на /mnt/c і навантаження створює величезну кількість дрібних файлів через межу Windows↔Linux.

Виправлення: Перемістіть репозиторій в /home/<user> всередині WSL. Якщо джерела мають лишатися на Windows, розгляньте VM з shared folders лише для легких редагувань, а не для дерев залежностей.

2) Симптом: сервіс прив’язався до 0.0.0.0, але інші пристрої LAN не дістаються (WSL)

Корінна причина: WSL 2 за NAT. Windows часто дістати його через localhost-інтеграцію; ваша LAN — ні.

Виправлення: Використайте проброс портів, якщо прийнятно, або перемістіть сервіс в bridged-VM (VirtualBox) для реальної присутності в LAN.

3) Симптом: захоплення пакетів не показує очікуваного трафіку

Корінна причина: Віртуальний мережевий шлях WSL і опосередкування Windows ховають/перетворюють те, що ви думаєте, що фіксуєте; можливо, ви ловите не той інтерфейсний шар.

Виправлення: Використайте VM з bridged-мережею і фіксуйте на NIC гостя, або фіксуйте на Windows-хості в правильному інтерфейсі. Якщо потрібна L2-правда — обирайте VM.

4) Симптом: місце на Windows зникає після «видалення великої кількості файлів» у WSL

Корінна причина: Віртуальний диск WSL виріс, але не зменшився автоматично; видалення всередині ext4 не одразу компактить VHDX.

Виправлення: Звільніть місце, компактуючи або експортуючи/імпортуючи дистрибутив. Якщо це відбувається часто, усвідомте: WSL не замінник тонко-пропорційного менеджеру зберігання, якого можна ігнорувати.

5) Симптом: «Hyper-V увімкнено, тому VirtualBox повільний/дивний»

Корінна причина: VirtualBox може працювати поверх API Hyper-V залежно від конфігурації хоста. Це змінює продуктивність і таймінги, і деякі функції можуть бути впливовими.

Виправлення: Вирішіть, який гіпервізор буде основним. Якщо потрібно зберегти функції Hyper-V, протестуйте продуктивність VirtualBox на своїх базових навантаженнях. Якщо вам потрібна максимальна продуктивність VM, розгляньте роботу без конфліктуючих шарів гіпервізорів.

6) Симптом: системні сервіси не стартують надійно в WSL

Корінна причина: systemd не увімкнено або життєвий цикл не еквівалентний повному завантаженню машини; фонова служба може залежати від поведінки init.

Виправлення: Увімкніть systemd для дистрибутива, якщо потрібно, і перевірте PID 1. Якщо життєвий цикл сервісу критичний, припиніть боротися і використайте VM.

7) Симптом: спостерігачі файлів пропускають зміни або створюють бурі подій

Корінна причина: Семантика watcher-ів у крос-файлових системах відрізняється; inotify через Windows-монти не еквівалентний нативній Linux FS-поведінці.

Виправлення: Тримайте спостережувані дерева всередині файлової системи WSL. Для великих монорепозиторіїв з інтенсивним watch-режимом VM може поводитися більш передбачувано.

8) Симптом: «Моя база даних повільніша у WSL, ніж очікувалося»

Корінна причина: Файли бази даних розташовано на /mnt/c, або тиск пам’яті на хості спричиняє swap, або антивірус сканує робочий набір.

Виправлення: Розмістіть data directory всередині ext4 WSL, виділіть більше пам’яті, виключіть відповідні шляхи від сканування згідно з корпоративною політикою, або перемістіть БД-навантаження в VM.

Три корпоративні міні-історії з практики

Міні-історія 1: Інцидент, спричинений невірним припущенням

Середня SaaS-компанія (назвемо її «Northbridge») стандартизувала локальну розробку на Windows-ноутбуках. Платформна команда затвердила WSL 2 за замовчуванням і рухалася далі. Це було вдале рішення для щоденного кодування.

Потім команда, що створювала мережевого агента, почала тестувати «реалістичну» поведінку в WSL. Їхній агент слухав вхідні підключення від інших машин у корпоративній LAN. Розробники повідомляли про переривчасту доступність: іноді працювало з Windows-хоста, іноді — ні з другого ноутбука. Вони звинувачували правила файервола, потім агента, потім лабораторні комутатори QA, бо так роблять люди під тиском часу.

Невірне припущення: «Binding to 0.0.0.0 всередині WSL еквівалентний прив’язці на хост-NIC». Це не так. WSL 2 живе за NAT, і Windows робить розумний проброс localhost, що робить вигляд, ніби все гаразд на тій самій машині. Для LAN це інша історія.

«Інцидент» не був простою відмовою; він був гіршим: періодом хибної впевненості. Вони вмерджили зміну, що виглядала правильно в тестах WSL, але падала в staging-лабораторії з реальними Linux-хостами. Через два дні налагодження корінь проблеми виявився простим: їхня тестова платформа ніколи не відповідала топології розгортання.

Виправлення було нудним і миттєвим: вони перенесли мережеві інтеграційні тести в VirtualBox-VM з bridged-мережею. WSL лишився для кодування. Команда припинила намагатися змусити WSL поводитися як маршрутизований хост. Продуктивність зросла, і кількість суперечок зменшилась.

Міні-історія 2: Оптимізація, що відбилася боком

Ще одна компанія («Red Quarry») вела великий монорепозиторій з важким Node-ланцюжком. Хтось вирішив «оптимізувати», тримаючи репозиторій на файловій системі Windows, щоб Windows-інструменти могли індексувати його і бекапи були простішими. Репозиторій було змонтовано в WSL під /mnt/c. Усім сказали, що це сучасний інтегрований підхід.

Спочатку все було гаразд. Потім кількість залежностей виросла. Кроки збірки почали створювати і видаляти сотні тисяч дрібних файлів. Розробники потай почали запускати збірки вночі. Це вже не робочий процес; це капітуляція.

Оптимізація відбилася боком, бо націлилася не на той вузький місце. Команда оптимізувала «одну копію файлів» і зручність Windows-інструментів, але заплатила за це накладними операціями на кожен файл і посиленням сканування endpoint-інструментами. Кожне створення файлу ставало крос-границею плюс перевіркою безпеки. Машина працювала; просто не над тим, що потрібно.

Зрештою SRE команди запустив малий стрес-тест: створити 20k файлів у /tmp vs /mnt/c. Співвідношення було принизливим. Вони за замовчуванням перемістили репозиторії у файлову систему WSL і налаштували редактор так, щоб відкривати WSL-шляхи. Індексацію переналаштували на Linux-сторону, де можливо.

Результат: часи збірки впали різко без зміни жодного прапорця компілятора. «Оптимізація», яку вони потребували, була не в швидшому коді — а в меншій кількості перетинів межі.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Фінтех-компанія («Halcyon Ledger») мала суворі вимоги до відтворюваності. Інженери використовували Windows-хости, але їхній реліз-пайплайн залежав від Linux-пакування і поведінки, близької до ядра. Також у них були аудитори, яким не важливі ваші почуття щодо вибору інструментів.

Платформна команда прийняла непоказне рішення: кожен проект мав прикріплений VirtualBox VM з зафіксованим дистрибутивом і задокументованим режимом мережі. Розробники все ще могли користуватися WSL для редагування і швидких скриптів, але все важливе — пакування, інтеграційні тести, мережеві перевірки — виконувалося у VM.

Це виглядало як «додаткова робота», поки оновлення Windows не змінило щось у мережевій поведінці WSL на частині ноутбуків. Розробники витратили півдня на пошук проблем з DNS і пробросом портів. Реліз-пайплайн не здригнувся, бо він не працював на тій інтерпретації WSL цього тижня. Він працював у нудній VM, яка поводилася так само, як і вчора.

Заощадження прийшло від передбачуваності, а не продуктивності. Образи VM трактували як артефакти: версіонували, тестували і час від часу міняли. Ніхто не хвалився — це ознака того, що це працювало.

Контрольні списки / покроковий план

Контрольний список A: Обрати WSL чи VirtualBox для нового проєкту

1. Потрібні вхідні підключення від інших машин? Якщо так — віддавайте перевагу VirtualBox з bridged-мережею.
2. Потрібні модулі ядра, eBPF або низькорівневе мережеве управління? Якщо так — віддавайте перевагу VirtualBox.
3. Чи навантаження інтенсивне по дрібних файлах? Якщо так — WSL підходить лише коли проект живе в ext4 WSL.
4. Потрібні USB-пристрої або серійні адаптери? Якщо так — віддавайте перевагу VirtualBox USB passthrough.
5. Критична відтворюваність у команді? Якщо так — віддавайте перевагу базовій VM (VirtualBox) і тримайте її як артефакт.
6. Це переважно CLI-інструменти і локальні збірки? Якщо так — WSL зазвичай кращий досвід.

Контрольний список B: Змусити WSL поводитися (налаштування «не боріться з фізикою»)

1. Тримайте код і дерева залежностей в /home, а не в /mnt/c.
2. Використовуйте Windows-редактори, що можуть відкривати WSL-шляхи без переміщення файлів назад на NTFS.
3. Перевірте systemd, якщо покладаєтеся на нього: перевірте PID 1 і статус сервісів.
4. Слідкуйте за пам’яттю: якщо ви свопите — налаштуйте ліміти або змініть платформу.
5. Будьте явними щодо мережевих очікувань: localhost-розробка — ок; видимість у LAN — не є функцією за замовчуванням.

Контрольний список C: Зробити VirtualBox нудним і надійним

1. Підберіть режим мережі, що відповідає реальності:
   • NAT — для лише вихідної розробки.
   • Bridged — для «ця VM — реальний хост у LAN».
   • Host-only — для ізольованих лабораторій з явним маршрутом.
2. Виділіть ресурси явно: RAM і кількість CPU. Не покладайтеся на динамічне зростання.
3. Використовуйте снапшоти економно й цілеспрямовано (перед ризиковими змінами), а не як спосіб життя.
4. Вирішіть, як ділитися файлами. Shared folders зручні, але можуть бути повільніші і менш Linux-подібні, ніж нативна файловa система.
5. Версіонуйте вашу VM-базу для команд. Якщо це важливо — зафіксуйте її.

Покроково: Міграція проєкту з WSL-on-/mnt/c до WSL ext4

1. Створіть робочу теку всередині WSL: mkdir -p ~/work.
2. Клонувати репозиторій всередині WSL: git clone ... ~/work/myapp.
3. Переінсталюйте залежності всередині WSL (не використовуйте сліпо Windows-кеш).
4. Оновіть конфіг редактора, щоб відкривати WSL-шлях.
5. Перезапустіть стрес-тест і збірку. Якщо різниця неочевидна — вузьке місце не в файловій системі.

Покроково: Міграція «потрібно справжнє мережеве середовище хоста» з WSL у VirtualBox

1. Створіть VM з дистрибутивом, що відповідає тому, який ви розгортаєте (підберіть основні версії).
2. Встановіть мережу в режим Bridged Adapter.
3. Встановіть стек і прив’язуйте сервіси до NIC гостя.
4. Перевірте досяжність з іншого пристрою в LAN.
5. Задокументуйте налаштування VM (режим NIC, очікування портів, правила файерволу) в репозиторії, щоб наступна людина не відкривала їх через страждання.

Питання й відповіді

1) Чи є WSL 2 «справжньою VM»?

Воно використовує справжнє ядро Linux у середовищі, схожому на VM. Але воно кероване й інтегроване так, що поводиться інакше, ніж самостійно керована VM, якою ви керуєте повністю.

2) Якщо WSL 2 використовує справжнє ядро, чому люди все ще кажуть, що це не справжній Linux?

Бо «справжній Linux» зазвичай означає контроль над ядром, модулями, життєвим циклом завантаження і передбачуваною поведінкою пристроїв/мереж. WSL — це справжній Linux userland на керованому ядрі з обмеженнями інтеграції.

3) Яка найбільша помилка продуктивності в WSL?

Помістити свій проєкт (зокрема каталоги залежностей) на /mnt/c і потім запускати Linux-інструменти, що створюють або перевіряють тисячі файлів.

4) Коли VirtualBox — погана ідея?

Коли вам потрібен тісний цикл інтеграції з Windows і вам не потрібні повноцінні машинні семантики. А також коли конфігурація хостів у вашій організації робить VirtualBox повільним через конкуренцію шарів віртуалізації — протестуйте на вашому базовому обладнанні перед прийняттям стандарту.

5) Чи може WSL замінити VirtualBox для Kubernetes-лабораторій?

Іноді. Одновузлові dev-кластери можуть працювати добре. Якщо потрібна мережна реалістичність мультивузловості, вхідний трафік від інших машин або CNI-поведінка, що очікує маршрутизованих вузлів — лабораторія на VM зазвичай менш дивна.

6) Чому доступ через localhost працює з Windows до WSL, але LAN-доступ — ні?

Бо Windows і WSL співпрацюють, щоб проброшувати деякі порти на localhost. Це не те саме, що гостю WSL мати LAN-маршрубельну адресу.

7) Чи потрібен systemd у WSL?

Якщо ваші інструменти очікують systemd-юнити, таймери, журнал чи залежності сервісів — так. Якщо ви просто запускаєте shell і окремі процеси — ні. Якщо ви тестуєте життєвий цикл сервера, все одно використайте VM.

8) А що з USB-пристроями і серійними портами?

VirtualBox має просту історію для USB passthrough (з потрібними компонентами). WSL може підтримувати деякі сценарії пристроїв, але якщо доступ до апаратури критичний — VM зазвичай найменше ризиковане рішення.

9) Чи можна змусити WSL поводитися як bridged-мережа?

Ви можете апроксимувати це через проброс портів і конфігурацію мережі на боці Windows, але це не модель за замовчуванням. Якщо bridged — вимога, обирайте VM, де bridged — перша класна опція.

10) Чи повинні команди стандартизуватися на одному інструменті?

Стандартизуйтеся на результатах. Для кодування WSL часто дає найкращий Windows-досвід. Для інтеграційних тестів і відтворюваності — зафіксована VM-база зазвичай спокійніша.

Наступні кроки, які можна зробити сьогодні

• Аудит де лежать ваші репозиторії. Якщо вони на /mnt/c і ви скаржитеся на продуктивність, перемістіть один репозиторій у /home і перевиміряйте.
• Визначте свої мережеві вимоги. Якщо інші машини мають підключатися вхідно — припиніть вдавати, що NAT підходить. Використовуйте VirtualBox bridged-режим для цього навантаження.
• Запустіть стрес-тести і збережіть результати. Наявність базової цифри переводить суперечки в інженерні аргументи.
• Розділіть «dev shell» від «інтеграційного середовища». WSL для щоденної ітерації; VirtualBox для реалістичності й відтворюваності, коли це важливо.
• Запишіть правила меж. Двосторінковий внутрішній гайд кращий за двадцять Slack-повідомлень і онбординг на основі фольклору.

Оберіть WSL, коли хочете швидкого налаштування і чудового Windows-цикла розробки. Обирайте VirtualBox, коли потрібна машина, яку можна зрозуміти — мережа, зберігання, поведінка ядра й усе інше. Використовуйте обидва, якщо серйозні: WSL для комфорту, VM для правди.