Прямой ответ
Выбор гипервизора определяется хостовой ОС и соседством с Docker/WSL2:
- Windows 11 Pro + WSL2/Docker → Hyper-V (точнее, его платформа): он уже работает под WSL2, а сторонние гипервизоры с ним конкурируют за аппаратную виртуализацию. VirtualBox 7.x умеет жить поверх Hyper-V, но с потерей скорости.
- Linux-ноутбук → KVM/QEMU (через virt-manager): нативная производительность, нулевая стоимость, минимум прослоек.
- Нужна одна и та же VM на разных хостах, или Windows Home без Hyper-V → VirtualBox: кросс-платформенный, простой, с переносимыми образами (OVA).
Ресурсы: холостая Linux-VM — 1–2 ГБ RAM и 5–10 ГБ диска; Windows-гость — 2–4 ГБ и 30–60 ГБ. На 16 ГБ ноутбуке комфортны 1–2 VM одновременно; на 32 ГБ — рабочий мини-парк.
Hyper-V: что это на самом деле
Hyper-V в контексте современного Windows — не только «Диспетчер Hyper-V», а платформа виртуализации, на которой уже работают WSL2, песочница Windows Sandbox и изоляция ядра. Практические следствия:
- Если у вас работает WSL2 — Hyper-V-платформа уже включена; добавление классических VM через роль Hyper-V ничего не ломает (Windows 11 Pro/Enterprise).
- Конфликт прошлого «VirtualBox не стартует при включённом Hyper-V» в VirtualBox 7 снят режимом работы поверх Hyper-V API — ценой заметного снижения производительности гостя.
- Windows Home роли Hyper-V не имеет — там выбор между VirtualBox и апгрейдом редакции.
Быстрый старт: включите роль Hyper-V («Компоненты Windows»), создайте внешний виртуальный коммутатор для доступа VM в сеть, ставьте гостевые утилиты (Linux Integration Services входят в ядро Linux; для Windows-гостя — отдельная установка).
KVM: стандарт на Linux
KVM превращает ядро Linux в гипервизор — VM работает почти на нативной скорости. Управление — virt-manager (GUI) или virsh (CLI):
sudo apt install qemu-kvm libvirt-daemon-system virt-manager
sudo adduser $USER libvirt # управление без sudo, перелогин
virt-install --name dev --memory 4096 --vcpus 2 \
--disk size=30 --os-variant ubuntu24.04 \
--cdrom ubuntu-24.04-desktop.iso
Преимущества: минимальный оверхед, снапшоты, virtio-драйверы диска/сети (ставьте гостю именно их — разница в I/O кратная), headless-сценарии без GUI. Это же стек, на котором minikube запускает VM-драйвер, — связь с контейнерными сценариями в статье про локальный Kubernetes.
VirtualBox: когда он лучший выбор
- Хост — Windows Home/macOS, где Hyper-V/KVM недоступны.
- Нужны переносимые образы: экспорт OVA и запуск на другой машине без привязки к гипервизору.
- Учебные стенды, где важнее простота, чем производительность.
Ограничения честно: сеть и диск медленнее нативных гипервизоров (помогает установка Guest Additions и virtio-подобные драйверы, где доступны); на Windows при активной платформе Hyper-V гость заметно деградирует; USB-проброс иногда капризничает после обновлений хоста. Для Linux-гостей на Linux-хосте VirtualBox не имеет смысла — KVM объективно лучше.
Вложенная виртуализация и типовые конфликты
Вложенная виртуализация (VM внутри VM — например, Kubernetes-нода или Windows в VM) требует явного включения: в Hyper-V — Set-VMProcessor -ExposeVirtualizationExtensions $true, в KVM — nested=1 у модуля kvm-intel/kvm-amd, в VirtualBox 7 — настройка процессора VM. Без этого Docker/k8s внутри гостя не стартуют с характерными ошибками виртуализации.
Частые конфликты на Windows-ноутбуке:
- «VT-x/AMD-V недоступен» — виртуализация выключена в BIOS/UEFI (SVM/Intel VT) или занята другим гипервизором.
- WSL2 и VirtualBox одновременно — работают, но VirtualBox медленнее; решите, что главное.
- Античиты/корпоративные агенты, требующие эксклюзивного доступа к виртуализации, — проверяйте совместимость до включения Hyper-V.
- Спящий режим хоста с запущенными VM: Hyper-V корректно сохраняет состояние, VirtualBox при s2idle иногда теряет сеть гостя — тема сна на Linux разобрана в статье про Linux на ноутбуке разработчика.
Бюджет ресурсов: сколько VM влезет в ноутбук
Правило: хост оставляет себе минимум 4 ГБ (Windows) или 2 ГБ (Linux), остальное делят VM по фактическому потреблению, а не по выделенному. Динамика помогает: у Hyper-V есть Dynamic Memory, у VirtualBox — ballooning; KVM обычно отдаёт фиксированно, но с KSM дублирующиеся страницы одинаковых гостей дедуплицируются. Диск: тонкие (динамические) диски экономят место, но на полном SSD деградируют — держите 15–20% свободными. И помните про WSL2: если основная разработка контейнерная, возможно, отдельная VM вам не нужна вовсе — сравнение расходов в статье про WSL2 и Docker.
Отдельный практический вопрос — где держать образы VM: на системном SSD они стартуют быстрее, но гостевые диски быстро съедают место; на втором диске — дешевле, но холодный старт и дисковые операции гостя медленнее. Разумный компромисс: активные VM на системном NVMe, архивные образы (OVA/бэкапы) — на внешнем или втором диске, с переносом «в прод» по мере надобности. При любом размещении исключите каталог образов из антивирусного сканирования в реальном времени: проверка каждого гостевого I/O замедляет VM кратно, а проверяемая польза от сканирования виртуальных дисков минимальна.
FAQ
Можно ли обойтись без виртуальных машин вообще? Для Linux-окружения на Windows — да, WSL2 закрывает большинство задач дешевле по ресурсам. VM нужны для полных ОС: Windows-гостей, сетевых лабораторий, ядерных экспериментов.
Сколько RAM выделять Linux-гостю? Серверная роль без GUI — 1–2 ГБ; рабочий стол — 4 ГБ. Больше имеет смысл только под конкретную нагрузку гостя.
Что быстрее на Linux: VirtualBox или KVM? KVM, практически всегда: это гипервизор уровня ядра против пользовательского процесса. VirtualBox выбирают не за скорость, а за переносимость образов.
Безопасны ли снапшоты для экспериментов? Да, это их главное назначение: откат после эксперимента мгновенный. Но снапшот — не бэкап: цепочки снапшотов растут на диске, важные данные держите вне VM или в резервной копии.
Практика: сеть и хранение VM
Два вопроса, которые решают при первой же настройке. Сеть: для доступа VM в интернет и с хоста используйте NAT (проще всего) плюс port forwarding или мост (bridged) — когда VM должна быть видна в локальной сети как отдельное устройство. У Hyper-V это виртуальные коммутаторы трёх типов, у VirtualBox — режимы адаптера, у KVM — сети libvirt (default = NAT). Ошибка новичка — bridged-адаптер в публичной Wi-Fi-сети с изоляцией клиентов: VM «не видна» не из-за настроек, а из-за политики точки доступа.
Хранение: динамические (тонкие) диски экономят место, но растут незаметно — Windows-гость с обновлениями раздувает VHDX на десятки гигабайт; периодически сжимайте их штатными средствами (Optimize-VHD у Hyper-V, VBoxManage modifymedium --compact у VirtualBox, fallocate/discard у qcow2). Снапшоты держите короткими цепочками: длинная цепочка замедляет дисковый I/O гостя кратно. И общее правило ресурсов: выключенная VM не ест память, но занимает диск — неиспользуемые машины экспортируйте в OVA/архив и удаляйте.
Источники: документация Microsoft Hyper-V, руководство VirtualBox, linux-kvm.org (ссылки в шапке).