MicroVM в Proxmox: лёгкие виртуальные машины с быстрой загрузкой

Инженер запустил самодельное решение для гибридного кластера Proxmox, состоящего из узлов с диаметрально противоположными возможностями. На практике он столкнулся с компромиссом между LXC-контейнерами (быстрые, но без изоляции) и полноценными виртуальными машинами (медленная загрузка из-за эмуляции BIOS и наследия). Решением стало применение типа машины QEMU microvm, который исключает лишнее (ни BIOS, ни GRUB, ни эмулированных устройств), оставляя прямую загрузку ядра в минимальное окружение virtio. Результат: загрузка в 300 мс с полной сетевой изоляцией KVM.

pve-microvm реализован как пакет Debian, модифицирующий Perl-модули Proxmox. Поставляется с ядром Linux 6.12.22, инициализационным образом (1 МБ) и инструментами для создания корневых файловых систем из OCI-образов. Система поддерживает 21 тип гостевой ОС от Debian до NetBSD и Plan9. На практике работает Gitea, распределённые агенты вывода (для LLM), миникрайволы и другие аgentic-рабочие нагрузки.

Ключевые факты

Время загрузки упало с 5, 10 секунд (стандартная VM) до 300 мс, сохраняя KVM-изоляцию
Ядро хранится на хосте Proxmox, не в гостевой ОС, что позволяет обновлять его в одном месте
Поддерживает 21 тип гостевой ОС, включая экзотические (Plan9, SmolBSD, OSv)
Virtio-девайсы используют PCIe с modern-only транспортом, отказ от эмуляции MMIO ради надёжности
Конфигурация обычная для Proxmox; управление через веб-интерфейс с кнопкой 'Create µVM'

Почему это важно

Контейнеры LXC загружаются мгновенно, но уязвимы к exploit'ам ядра (компрометация хоста), и не позволяют запускать другие ОС или Docker без сложных workaround'ов. Полные VM безопасны благодаря KVM-изоляции, но медленно загружаются из-за эмуляции железа. MicroVM закрывает этот разрыв: VM-уровень безопасности с boot-временем контейнера. Это критично для агентных воркфлоев, которые динамически создают и уничтожают изолированные окружения.

Кому это важно

Инженеры, управляющие гетерогенными кластерами Proxmox (смешанный скромный и мощный hardware). Команды, запускающие Gitea Actions, рабочих вывода (inference), временных систем CI/CD с требованиями изоляции. Люди, которые устали перезагружаться 5, 10 секунд на каждый новый контейнер. Энтузиасты системного программирования, экспериментирующие с нестандартными ОС.

Как это применить

Установить pve-microvm .deb на узлы Proxmox. Создать или импортировать OCI-образ (Debian, Alpine, Fedora, Rocky, Amazon Linux). Создать гостя через веб-интерфейс, выбрать machine: microvm. Конфиг выглядит как обычная VM (cores, memory, диск), но ядро и initrd поставляются хостом. Присоединить к стандартным VLANам, DHCP или статический IP через systemd-networkd. Netfilter firewall работает как обычно.

Можно ли доверять

Решение не quick hack. Автор запускает его в production три года, использует для критического железа (Gitea, CI/CD, агенты). Поддержка 21 ОС означает тестирование на разных платформах и архитектурах. Ядро собирается из x86_64_defconfig с минимальным overlay, что позволяет аудировать. Известна одна особенность (virtio-blk на MMIO в QEMU 10.x не биндится для Linux), которую автор честно описал.

Риски и подводные камни

Ядро на хосте упрощает обновление, но деталь: нельзя обновлять ядро внутри гостя. Переход на новое ядро требует рестарта машины. MMIO-транспорт для virtio имеет проблемы с Linux в QEMU 10.x, что заставляет использовать PCIe (добавляет 50 мс к boot'у). Нет installers ISO; ОС собирается из OCI-образов. Некоторые workload'ы, требующие нестандартных kernel modules (как DSM), могут требовать fallback на хост-ядро.

«What I wanted was the security boundary of a VM with the startup characteristics of a container. QEMU's microvm machine type, originally developed for Firecracker-style workloads, strips all of that away. No BIOS, no GRUB, no legacy devices. Direct kernel boot into a minimal virtio-only environment. The result: sub-300ms boot to a fully networked guest with a QEMU agent, running inside its own KVM hardware isolation boundary.»

— Автор, taoofmac.com