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

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'

Ред. Plan9 и NetBSD в списке поддержки, потому что без них любой инфраструктурный проект чувствует себя недостаточно серьёзным.

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

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

Ред. Безопасность VM при скорости контейнера, классическое «и рыбку съесть». Здесь, похоже, действительно съели, ценой одного .deb и тонны Perl.

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

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

Ред. «Люди, которые устали перезагружаться 5, 10 секунд», то есть примерно все, кто хоть раз ждал старта VM с чашкой остывающего кофе.

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

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

Ред. «Конфиг выглядит как обычная VM, только ядро поставляет хост», тот случай, когда самое интересное спрятано за словом «только».

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

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

Ред. Три года в production и честно описанный баг внушают больше доверия, чем любой маркетинговый раздел «почему нам можно верить».

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

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

Ред. Сэкономили 5 секунд на загрузке, доплатили 50 мс за PCIe и невозможность обновить ядро в госте. В инфраструктуре бесплатного обеда по-прежнему не подают.

«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