Все почалось досить безневинно — з 128 гігабайт оперативної памʼяті, які мені дісталися по роботі. Звучить круто як число, але для робочої станції це відверто надлишкові. І саме цей надлишок штовхнув мене на шлях, який закінчився повною переустановкою ОС, віртуалізацією всього і кращою продуктивністю, ніж була без гіпервізора.
Але спочатку — невеликий відступ.
Від Linux до Windows: шлях блудного сина
Я був фанатом Linux. Завдяки моєму університетському викладачу — людині, яка, здавалося, боготворила Linux. За жарт про Windows на його парах можна було отримати непогану оцінку, а за щирий інтерес до ядра — ще кращу. Саме через нього я почав активно використовувати Linux: спочатку Ubuntu, потім Fedora, потім Arch — класичний шлях деградації.
Перший час це було захопливо — знаходити і вирішувати проблеми, налаштовувати систему під себе, ламати і чинити, ламати знову. Але в якийсь момент я зрозумів просту річ: постійно налаштовувати все під себе — це важко, і з часом набридає. Одна неправильна команда може зламати систему, і ти знову сидиш з live USB і перевстановлюєш все з нуля. Час, який міг піти на роботу чи відпочинок, йшов на боротьбу з драйверами, конфігами та залежностями.
Тоді я вирішив встановити Windows 11. І знаєте що? Мені сподобалось. WSL 2 закрив більшість потреб у Linux-середовищі — Docker, Python, Node.js, SSH-тунелі, все працює нативно всередині Windows. Потім я відкрив для себе PowerToys — набір інструментів від Microsoft, де вони тестують різні корисні фічі перед тим, як вбудувати їх у систему (принаймні, я так думаю — деякі штуки звідти реально потім зʼявляються в оновленнях Windows). FancyZones, PowerRename, Peek, Always On Top — рекомендую ставити всім, у кого Windows. Безкоштовно, open source, і суттєво покращує щоденний досвід роботи.
Отже, я сидів на Windows 11, мав WSL 2 і був загалом задоволений. Поки не зʼявилися ці 128 ГБ RAM.
RAM-диск: гарна ідея, яка не злетіла
Коли маєш 128 ГБ оперативки і реально використовуєш 30–50 ГБ під час роботи, виникає закономірне питання: а куди дівати решту? Перша ідея — RAM-диск.
Ідея була проста: тримати проєкти з великою кількістю файлів на RAM-диску, отримувати швидкість читання/запису на рівні оперативної памʼяті і радіти життю. І справді — для проєктів, де тисячі дрібних файлів, різниця відчувалась миттєво. npm install, git status, збірка — все літало.
Але є нюанси. Багато нюансів.
По-перше, RAM-диск живе до вимкнення ПК. Виключив компʼютер — втратив усе. В Україні, де світло відключають регулярно, одне випадкове відключення могло забрати в тебе кусок роботи. Я налаштував rsync-скрипти для бекапу кожні 15 хвилин, але все одно — втрачати навіть 15 хвилин роботи через зникнення електрики неприємно.
По-друге, сумісність. Головна проблема, яка похоронила цю ідею — uv (сучасний Python package manager від Astral, заміна pip/virtualenv) відмовлявся збирати бібліотеки на RAM-диску через проблеми сумісності з файловою системою. Для Head of Data, який живе в Python, це було критично.
По-третє, побічні ефекти. Я переніс усі тимчасові папки (TEMP, кеш браузера) на RAM-диск. Візуально Chrome став працювати краще — кеш читався миттєво. Але система в цілому поводилась дивно: рівень стабільності був десь на 6–7 з 10, а Провідник Windows відкривався довго, ніби щось не знаходив при старті.
Вердикт: більше проблем, ніж користі. Ідея була похована.
Перше знайомство з Proxmox VE
В якийсь момент по роботі і на форумах мені почали потрапляти на очі статті про Proxmox VE — open source платформу для віртуалізації. Насправді, я почув про нього нещодавно, хоча добре знав KVM, OpenVZ, Virtuozzo, VMware і VirtualBox — доводилось зустрічатись з цими інструментами в різних контекстах.
Я скептично переглянув кілька статей. Потім попросив AI зробити розгорнутий опис — і ось тут мене зачепило. Ключові тези, які я почув:
- Легкий. Proxmox VE — це, по суті, Debian з тонким шаром управління віртуалізацією. Сам гіпервізор споживає мінімум ресурсів
- Дуже гнучкий. Повна підтримка KVM для повної віртуалізації та LXC для контейнерів
- PCI passthrough. Можна прокинути фізичні пристрої — GPU, мережеві карти, USB-контролери — напряму у віртуальну машину. VM бачить пристрій як рідний, без емуляції, з near-metal продуктивністю
- ZFS та ARC кеш. Вбудована підтримка ZFS з адаптивним кешуванням в оперативній памʼяті
В принципі, нічого не втрачаю, крім свого часу. А коли час іде на щось цікаве — я навіть не жалкую, якщо щось не вийде.
Підготовка та встановлення
Знайшов свою стару відеокарту — ASUS HD6670 1 ГБ DDR3, 2014 року випуску. Карта без підтримки GOP і UEFI — абсолютна заглушка, але саме це мені і потрібно: вивести термінал Proxmox через неї, щоб не чіпати основну відеокарту. Основна GPU — AMD RX 580 8 ГБ — піде цілком у віртуальну машину через PCI passthrough.
Завантажив ISO Proxmox VE, записав через Rufus — і зустрів максимально дружнє встановлення. Під час якого я дізнався про одну з ключових фішок, яка потім змінила мій досвід використання ПК.
ZFS ARC: навіщо мені стільки RAM
Під час встановлення Proxmox запропонував файлову систему — і я обрав ZFS. Це було одне з найкращих рішень.
ZFS ARC (Adaptive Replacement Cache) — це механізм кешування, вбудований у файлову систему ZFS. Суть проста: ZFS використовує вільну оперативну памʼять як кеш для даних, що читаються з диску. Перше читання файлу йде з фізичного накопичувача, а далі — з RAM. І не просто кешує останні файли, як робить більшість ОС, а використовує адаптивний алгоритм, який розрізняє:
- MRU (Most Recently Used) — файли, які читались нещодавно
- MFU (Most Frequently Used) — файли, які читаються часто
ARC автоматично балансує між цими двома стратегіями, адаптуючись до навантаження. Результат — мінімальне звернення до фізичного диску після першого прогріву, максимально ефективне використання оперативної памʼяті.
І ось тут мої 128 ГБ RAM знайшли своє справжнє призначення. Замість штучного RAM-диску, який треба вручну наповнювати і бекапити, ZFS ARC автоматично перетворює вільну памʼять у надшвидкий дисковий кеш. Система сама вирішує, що кешувати, а коли VM потребує більше памʼяті — ARC автоматично звільняє місце.
Це не RAM-диск. Це розумніше.
Перше враження: web UI, мобільний додаток і встановлення з ліжка
Встановлення пройшло без проблем. Після перезавантаження мене зустрів Web UI — повноцінна панель управління гіпервізором, доступна з будь-якого пристрою в мережі. Термінал, мобільний додаток — все доступне одразу. Я був здивований, особливо мобільним додатком і можливістю запускати noVNC — повноцінну консоль віртуальної машини прямо з телефону.
Не без своїх проблем — на маленькому екрані працювати з консоллю не найзручніше, краще через web-інтерфейс з нормального браузера. Але факт залишається фактом: з мобільного додатку мені вдалось встановити Windows до першого запуску — створити VM, підключити ISO, запустити інсталяцію і пройти її через noVNC, лежачи в ліжку. Великий плюс — можна повністю відключити монітори і керувати всім з телефону.
Три дні до робочої системи
День перший: все дефолтне, все повільне
Перше враження від Windows у VM було прямо кажучи — не дуже. Все працювало, але відчувалось «ватно» — затримки при кліках, мікрофрізи, довге відкриття програм. Оцінка роботи системи — десь 4 з 10.
Проблема була в тому, що я залишив усе за замовчуванням: емульований відеоадаптер, емульований мережевий контролер, стандартний контролер дисків. Proxmox за замовчуванням емулює пристрої для максимальної сумісності, але емуляція — це завжди overhead.
День другий: перші оптимізації
Почав колупати налаштування. Встановив VirtIO-драйвери — паравіртуалізовані драйвери для мережі, дисків, відео, памʼяті. VirtIO — це стандарт, який дозволяє гостьовій ОС «знати», що вона працює у VM, і спілкуватися з гіпервізором напряму, без емуляції фізичних пристроїв. Різниця в швидкості дискових операцій — в рази.
Прокинув основні пристрої через PCI passthrough:
- GPU AMD RX 580 8 ГБ — як основну відеокарту для VM
- WiFi Intel AX210 — разом з Bluetooth
- USB-контролер — для клавіатури, миші та периферії
Система стала працювати на рівні 6–7 з 10 — помітно краще, але все ще трохи гірше, ніж без гіпервізора. Основна проблема — частина пристроїв прокинулась некоректно: деякі емулювались замість passthrough, а деякі блокували хост, бо вже були «зайняті» прокинутою VM.
День третій: переустановка з правильними налаштуваннями
Вирішив перевстановити все з нуля, але вже з правильними налаштуваннями з самого початку. І ось тут я був приємно здивований.
Система стала працювати краще, ніж на «голому» Windows. Зникли мікрофрізи. Відклик став чіткішим. Програми відкривались швидше. Оцінка — тверда 8–9 з 10.
Що я зробив інакше:
CPU: менше ядер — більше частоти. За рекомендацією Claude Opus я зменшив кількість виділених ядер для VM, але дозволив їм працювати на повній частоті турбобусту. Логіка проста: більшість десктопних задач залежать від однопоточної продуктивності, а не від кількості ядер. Плюс, я призначив VM фізичні ядра процесора, а Hyper-Threading залишив для інших VM та хоста. Це мінімізувало конкуренцію за ресурси і дало CPU працювати на максимальній частоті.
RAM: 64 ГБ для VM, решта — під ARC. Виділив 64 ГБ для Windows VM — з запасом, бо під час роботи рідко навантажував більше 50 ГБ. Решта памʼяті автоматично пішла під ZFS ARC, перетворивши диск у ракету.
NUMA topology. Увімкнув NUMA (Non-Uniform Memory Access) в налаштуваннях VM. NUMA повідомляє гостьовій ОС про реальну топологію памʼяті процесора — які ядра мають прямий доступ до яких банків памʼяті. Без цього VM може намагатись читати памʼять через «чужий» контролер, що додає латентність. З NUMA — кожне ядро працює зі своєю найближчою памʼяттю.
Hugepages (1 ГБ сторінки памʼяті). Стандартний розмір сторінки памʼяті в x86 — 4 КБ. Для VM з 64 ГБ RAM це мільйони записів у таблиці сторінок, які процесор повинен обробляти. Hugepages збільшують розмір сторінки до 2 МБ або навіть 1 ГБ, зменшуючи кількість записів у тисячі разів. Менше записів — менше навантаження на TLB (Translation Lookaside Buffer) — швидший доступ до памʼяті.
Відключив енергозбереження. В BIOS і в налаштуваннях Proxmox відключив C-States, P-States, Cool'n'Quiet та інші механізми енергозбереження. Для десктопної робочої станції, яка працює від мережі, немає сенсу жертвувати продуктивністю заради економії 20 Вт. CPU завжди працює на повній частоті, без затримок на «прокидання» з режимів сну.
Linux під капотом: чому це має значення
Є ще один фактор, який я спочатку недооцінив. Proxmox VE — це Debian Linux під капотом. А це означає, що все управління залізом — планувальник CPU, менеджмент памʼяті, I/O scheduler, драйвери — працює через ядро Linux. І саме тут криється один із головних секретів того, чому система стала швидшою.
Linux-ядро історично краще працює з залізом напряму. Планувальник процесів ефективніше розподіляє навантаження між ядрами. I/O scheduler краще оптимізує черги запитів до дисків. Драйвери в ядрі Linux працюють ближче до заліза, без абстракцій Windows Driver Model. Менеджмент памʼяті — особливо з ZFS та hugepages — дає менше фрагментації і меншу латентність.
По суті, я отримав найкраще з двох світів: сиру продуктивність Linux при роботі із залізом і звичний десктопний досвід Windows для щоденної роботи. Windows думає, що вона працює на виділеному залізі, але насправді між нею та фізичним процесором/памʼяттю/диском стоїть тонкий шар Linux-гіпервізора, який робить цю роботу ефективніше, ніж сам Windows на bare metal. Іронія в тому, що Linux, від якого я колись пішов заради зручності, тепер тихо працює під капотом і робить мій Windows кращим.
Хак з двома відеокартами
Окремий момент — як я організував виведення зображення. HD6670 підключена до одного з моніторів через VGA і показує консоль Proxmox. Основна RX 580 прокинута у Windows VM через PCI passthrough і підключена через HDMI/DisplayPort.
Написав невеликий скрипт, який пінгує QEMU Guest Agent всередині VM: коли Windows запущений і драйвери GPU ініціалізовані — монітор автоматично переключається на HDMI (вивід з RX 580). Коли VM вимкнена — переключається назад на VGA (консоль Proxmox через HD6670). Таким чином, в мене завжди є доступ до гіпервізора, навіть коли VM працює.
CrystalDiskMark: цифри, які не мають сенсу (але показово)
Коли система запрацювала стабільно, я вирішив погоняти стандартні бенчмарки. Перше, що запустив — CrystalDiskMark.
Результати для мого ноунейм NVMe PCIe 3.0 на 512 ГБ (диск C:) — 6656 МБ/с читання, 1625 МБ/с запис в послідовному тесті Q8T1. Для мого RAID 1 з двох SATA SSD (диск F:) — 7041 МБ/с читання, 11002 МБ/с запис.
Почекайте, що? 11 ГБ/с запис на SATA SSD? Це фізично неможливо — SATA III має межу в 600 МБ/с на один диск.
Відповідь — ZFS ARC. CrystalDiskMark пише і читає тестовий файл, але ZFS кешує цей файл у RAM після першого звернення. Наступні ітерації читають не з диску, а з оперативної памʼяті. По суті, бенчмарк тестує швидкість RAM, а не диску.
Для реального тестування продуктивності дисків CrystalDiskMark у ZFS-середовищі не підходить. Але це наочно демонструє, що ARC працює: будь-який файл, прочитаний одного разу, далі віддається зі швидкістю оперативної памʼяті. Для реальних задач — відкриття проєктів, запуск IDE, компіляція — це означає, що повторні операції відбуваються миттєво.
AIDA64 видала ще більшу дичку в тестах — я просто проігнорував результати, бо вони не мали жодного відношення до реальної продуктивності.
Elden Ring на максималках: несподіваний сайд-ефект
Тоді чисто заради інтересу вирішив запустити Elden Ring. Коротко про мій топ ігор: Герої 3 (WoG), Red Alert 2: Yuri's Revenge та Elden Ring. Нічого супер нового та вимогливого, але часу на ігри майже немає.
Раніше Elden Ring ледве працювала на мінімальних налаштуваннях — доводилось скидати роздільну здатність до 1080p на моєму 2K-моніторі, щоб мати хоч щось грабельне. RX 580 на 8 ГБ — це вже не та карта для сучасних ігор, особливо з DX12.
Отже, запускаю гру у VM. Пройшов навчання і тільки потім помітив, що гра була запущена в 2K на високих налаштуваннях. Я просто забув зайти в налаштування і скинути все до мінімальних. І при цьому — жодних мікрофрізів, FPS стабільно тримався вище 50.
Подивився в Диспетчер задач — GPU навантажена на 60–70%. Виставив максимальні налаштування — навантаження піднялось до 80–90%, але все працювало так само плавно. Я був приємно здивований.
Чому GPU працює краще у VM?
Це здається парадоксальним — як відеокарта у віртуальній машині може працювати краще, ніж на «голому» залізі? Але є логічне пояснення.
Коли RX 580 прокинута через PCI passthrough, VM отримує прямий, ексклюзивний доступ до GPU. Ніякої емуляції, ніякого проміжного шару — GPU працює так, ніби вона фізично вставлена в компʼютер, на якому крутиться ця VM.
Але ключова різниця — у тому, чого немає. На «голому» Windows відеокарта обслуговує десятки процесів одночасно:
- Desktop Window Manager (DWM) — композитинг всіх вікон, прозорість, анімації
- Windows Search Indexer — генерація мініатюр і превʼю
- Hardware-accelerated browsing — Chrome/Edge використовують GPU для рендерингу сторінок
- Windows Defender — GPU-прискорене сканування
- Кілька моніторів — рендеринг робочого столу на кожному
- OBS, Discord overlay, Steam overlay — якщо запущені
- Фонові оновлення драйверів і телеметрія AMD/NVIDIA
У VM — чистий Windows з мінімумом фонових процесів. GPU виділена виключно під ту задачу, яка зараз працює. Немає конкуренції за VRAM, немає переключення контексту між десятками GPU-процесів. Плюс, Proxmox як Linux-хост не використовує цю GPU взагалі — у нього є своя HD6670.
Додатково, ZFS ARC кешує ігрові файли після першого завантаження. Повторні завантаження рівнів, текстур, шейдерів — зі швидкістю RAM, а не NVMe. Це зменшує stutter від підвантаження ассетів, який є однією з головних проблем Elden Ring.
Результат — GPU працює на повну потужність без «паразитного» навантаження від ОС, а дані літають зі швидкістю оперативної памʼяті. Для старенької RX 580 це виявилось суттєвим бустом.
MacOS: Flutter-збірка без Hackintosh-болю
Окрім Windows, я встановив macOS у окрему VM. Я не фанат цієї ОС — вона гарна, має багато корисних функцій, але політика Apple мене трохи дратує. Та й пальці вже звикли до хоткеїв Windows. Єдина причина, чому мені потрібна macOS — збірка Flutter-додатків для iOS. Без macOS ви не зберете .ipa файл — Apple цього не дозволяє, і обійти це не можна.
Знайшов гайд на GitHub — по інструкції все завелось, але без підтримки GPU. AMD RX 580, хоч і підтримує Metal через macOS-драйвери на реальному залізі, у VM працює з обмеженнями. Це одна з причин, чому я досі тримаю RX 580 і не замінив на якусь RTX 5060 — AMD має кращу підтримку в macOS-віртуалізації, навіть якщо неповну. Запуск iOS Simulator або будь-якого додатку, що потребує Metal GPU-прискорення — без шансів.
З горем вдалось прокинути GPU, і без жодних проблем оновився до macOS Tahoe 26.3. Все запрацювало на рівні, достатньому для збірки проєкту.
У порівнянні з Hackintosh — це було в 100 разів простіше. Ніяких годин з Custom SSDT/DSDT, ніякого підбору кекстів, ніякого написання ACPI-патчів під конкретне залізо, ніякого страху оновлення macOS. Proxmox просто створює VM, а macOS думає, що вона на реальному Macʼу.
Мінус: щоб переключитись між Windows і macOS VM, потрібно повністю вимкнути одну VM і запустити іншу — бо обидві використовують одну GPU через PCI passthrough. Поки для віртуалок є лише одна дискретна GPU, одночасна робота неможлива.
Що я отримав у підсумку
Давайте підібʼємо. Я замінив «голий» Windows на гіпервізор Proxmox VE з Windows VM, і ось що маю:
Кращу продуктивність. Windows з меншою кількістю ядер, з меншим обʼємом RAM (64 ГБ замість 128 ГБ) — але стабільнішу систему з кращим відгуком. GPU працює чистіше, CPU працює на максимальній частоті, диски літають завдяки ARC.
Снапшоти та швидкий відкат. Перед оновленням Windows, перед встановленням сумнівного софту — один клік на снапшот. Якщо щось пішло не так — відкат за секунди. Не потрібно відновлювати з бекапу, не потрібно перевстановлювати. Це як git для операційної системи.
Керування з телефону. Proxmox Mobile App + noVNC — запуск, зупинка, моніторинг VM з будь-якого пристрою. Поки не вдається включити ПК з телефону — потрібно налаштувати Wake-on-LAN або поставити Zigbee-модуль з Home Assistant для керування живленням.
Окрема VM для Docker. Це, мабуть, одна з найбільших перемог. Docker Desktop на Windows — це постійна морока і серйозний вплив на продуктивність системи. На Proxmox я створив окрему легку VM спеціально для Docker — ізольовано, без конфліктів, без WSL2-оверхеду.
Ізольовані середовища для AI-агентів. Можливість запускати AI-агенти (OpenClaw тощо) в повністю ізольованих VM — без ризику для основної системи, з повним контролем над ресурсами.
MacOS для iOS-збірки. Flutter-проєкти збираються для iOS без окремого Macʼа і без Hackintosh-танців.
Чи варто це геморою?
Три дні на налаштування — це не мало. Можливо, все це можна було вирішити і без гіпервізора: поставити Docker на WSL2, забути про RAM-диск, змиритися з мікрофрізами. Але мені подобається цей підхід — бо я маю більше контролю.
Контроль над тим, скільки ресурсів отримує кожна задача. Контроль над тим, що працює і що ні. Можливість зробити снапшот перед будь-якою змінною і відкотитися за секунди. Можливість запустити три різні ОС на одному залізі без перезавантаження (ну, майже — для віртуалок поки одна GPU).
Якщо у вас є зайвий час і цікавість до таких речей — спробуйте. Proxmox VE безкоштовний, документація чудова, а спільнота активна. Найгірше, що може статися — ви витратите вихідні і повернетесь на «голий» Windows. Найкраще — отримаєте систему, яка працює краще, ніж оригінал.
А якщо у вас 128 ГБ RAM — ZFS ARC зробить ваш день.