Всё началось довольно безобидно — со 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 сделает ваш день.