pve-microvm

Debian-пакет, превращающий тип машины `microvm` в QEMU в полноценную управляемую виртуальную машину внутри Proxmox VE. Он закрывает разрыв между LXC-контейнерами (мгновенный старт, общее ядро, нет изоляции) и полновесными VM (аппаратная изоляция, но 5-10 секунд до приглашения ко входу): microVM загружается быстрее чем за 300 мс в гостевую систему только на virtio-устройствах, которая при этом остаётся внутри собственной аппаратной границы KVM. Пакет написан Rui Carmo (taoofmac.com) для собственной домашней лаборатории, где в таких машинах крутятся Gitea, reverse proxy на Caddy, мини-файрволы и агент управления кластером Proxmox.

Идея формулируется как "VM со скоростью контейнеров и реальной изоляцией" - граница изоляции уровня VM, привычная по microvm-платформам, перенесённая из масштабов гиперскейлеров в обычную домашнюю ноду Proxmox.

Как это работает

Когда в конфигурации VM указан machine: microvm, пакет перехватывает генератор команд QEMU в Proxmox и собирает урезанную машину: без BIOS, без GRUB, без мостов PCI, без VGA и без USB. Гостевая система получает единственный последовательный порт (подключённый к xterm.js в PVE), диск virtio-blk и сетевой интерфейс virtio-net, а запускается через прямую загрузку ядра (-kernel/-initrd на хосте). Это та же архитектура, что у qemu-microvm и Firecracker; заслуга проекта - именно интеграция с Proxmox, а не сам тип машины.

Проект держится на трёх архитектурных решениях:

Ядро от хоста, rootfs без привязки к ядру. Единственный файл vmlinuz размером 12 МБ (Linux 6.12.22, собранный из стандартного x86_64_defconfig с набором модулей для virtio/vsock/virtiofs/9p/Docker) лежит на хосте Proxmox по пути /usr/share/pve-microvm/vmlinuz. Все microVM с Linux на ноде загружают одно и то же ядро. Диск гостевой системы содержит только корневую файловую систему - без /boot, без пакетов ядра внутри гостя и без initramfs. Ядро обновляется и проверяется строго в одном месте, и ни одна гостевая система не сможет сломаться из-за неудачного apt upgrade, потому что внутри гостя ядра попросту нет. Вместо установки ОС rootfs собирается из базового OCI-образа (pve-microvm-template поддерживает 12 вариантов - Debian, Alpine, Fedora, Rocky, Amazon Linux и другие) либо импортируется готовый ext4/raw-диск через qm importdisk. Сам Carmo описывает это как "консистентность ядра как в контейнерах, изоляция как в VM".

Патчит внутренности Perl в Proxmox при установке. Пакет .deb изменяет три файла в стеке Perl PVE: Machine.pm (чтобы принимать microvm как допустимый тип машины), QemuServer.pm (для делегирования сборщику команд при machine: microvm) и поставляет MicroVM.pm в качестве полноценного генератора команд. Патчи обратимы (pve-microvm-patch revert, резервные копии оригиналов сохраняются), повторно накатываются автоматически после обновлений PVE через триггер dpkg (interest-noawait qemu-server) и принудительно активируются до автозапуска любых VM с помощью ранней службы systemd (pve-microvm-early.service с параметром Before=pvedaemon.service pve-guests.service).

Транспорт PCIe вместо MMIO для гостей с Linux. Это отступление от классической архитектуры qemu-microvm. QEMU microvm может пробрасывать virtio-устройства через минималистичный MMIO (самый лёгкий вариант - именно так гостевая SmolBSD/NetBSD загружается за 31 мс) или через PCIe. В QEMU 10.x в ветке MMIO есть баг с обнаружением устройств для гостей с Linux: привязывается только virtio-blk, а драйверы сети, serial и balloon свои устройства не подхватывают. Поэтому все гостевые системы на Linux переведены на PCIe с non-transitional (modern-only) virtio-устройствами, где всё определяется надёжно. Расплата за это - около 50 мс дополнительного времени инициализации при общем времени загрузки в 300 мс. Carmo подозревает, что дело в ошибке в его собственной конфигурации ядра, и открыто просит патчей от сообщества.

Как выглядит конфигурация

microVM - это обычная гостевая система qm со специальным типом machine и параметрами командной строки ядра. Пример /etc/pve/qemu-server/114.conf для гостя с Gitea:

agent: 1
args: -kernel /usr/share/pve-microvm/vmlinuz -append "console=ttyS0 root=/dev/vda rw quiet"
boot: order=scsi0
cores: 2
machine: microvm
memory: 2048
name: gitea
net0: virtio=BC:24:11:00:6E:01,bridge=vmbr0
onboot: 1
scsi0: local-lvm:vm-114-disk-0,size=32G
serial0: socket
vga: serial0

Специфичны для microVM только строки machine: microvm, параметр args с ядром и командной строкой, а также serial0/vga: serial0 для вывода консоли в xterm.js. MicroVM.pm автоматически подставляет -initrd, устройства balloon, vsock и (если настроено) virtiofs. Всё остальное - ядра, память, сетевой интерфейс virtio на vmbr0, диск, onboot, гостевой агент - настраивается ровно так же, как для любой другой VM в Proxmox.

Начало работы

# On any PVE 9.x node:
wget https://github.com/rcarmo/pve-microvm/releases/latest/download/pve-microvm_0.3.12-1_all.deb
dpkg -i pve-microvm_0.3.12-1_all.deb

# Build a Debian microVM template (~60s: pulls OCI image, installs packages, writes rootfs):
pve-microvm-template --vmid 9000 --storage local-lvm --profile standard

# Clone it into a real VM:
qm clone 9000 100 --name my-microvm --full
qm set 100 --machine microvm --memory 1024 --cores 2
qm start 100

Создание linked clone'ов после первичной сборки шаблона происходит практически мгновенно.

Почему это "обычная гостевая система PVE"

Так как диск представляет собой обычное устройство virtio-blk-pci, а сетевая карта подключается к стандартному Linux bridge, почти все возможности Proxmox работают без изменений: любые бэкенды хранилища (LVM/LVM-thin, ZFS, Ceph/RBD, NFS, CIFS, директории), снимки состояния, linked и full clone'ы, резервные копии через vzdump, файрвол nftables для отдельных VM и сетевая изоляция через зоны VLAN/VXLAN в Proxmox SDN. Carmo намеренно не стал заново изобретать сетевую изоляцию внутри пакета: политики задаются в Proxmox SDN, а не в отдельном наборе правил. Не привязанный к сети vsock CID (VMID + 1000) отвечает за проброс SSH-agent с хоста в гостя и общий доступ к каталогам через virtiofs/9p. Заданный объём памяти - это потолок, а не фиксированное выделение: KVM выделяет страницы только по мере обращения, same-page merging устраняет дубликаты общего ядра, libc и слоёв базовых образов между всеми microVM на ноде, а недавно добавленный balloon (с free-page-reporting/deflate-on-oom) вместе с virtio-mem обеспечивают честный auto-ballooning и точечное горячее добавление/удаление памяти.

Ограничения

• Нет live migration - в типе машины microvm в QEMU она не реализована. Офлайн-миграция работает; благодаря субсекундной загрузке перемещение в HA по схеме stop -> migrate -> start на общем хранилище занимает около 2 секунд.
• Патчить чужой продукт рискованно. Любое обновление qemu-server может сломать интеграцию. При частичных или незавершённых обновлениях PVE бывало, что pvedaemon не мог скомпилировать пропатченный модуль. На нодах с этим пакетом нужно всегда выполнять полный dist-upgrade, а не частичный.
• Ловушка с /dev/vda -> /dev/sda. Если гостевая система запустится со стандартным чипсетом (из-за не полностью применённого патча или если VM с onboot=1 стартует раньше, чем ранняя служба успеет повторно наложить патч), диск определится как /dev/sda, корневой раздел не найдётся, и покажется, что гость потерял файловую систему. Сейчас в initrd добавлен fallback на /dev/sda, но подобные шероховатости возможны, пока (и если) Proxmox не поддержит microVM нативно.
• Только последовательная консоль - без VGA и графической консоли. Для серверов этого достаточно; паники ядра при загрузке читаются в терминале. Гостевым системам на Plan 9 это не нравится.
• Вообще нет USB - ни контроллеров, ни проброса. Это исключает работу с USB-донглами Zigbee/Z-Wave (свою домашнюю автоматизацию Carmo держит в LXC).
• Проброс GPU/PCI отключён, хотя и не невозможен: hostpci* вырезается, обвязка vIOMMU отсутствует. В ранних тестах RTX 3060 работала; функциональность была отключена ради простоты и из-за нехватки оборудования для полноценного тестирования.
• Специфичный выбор ядра. Если для задач нужен модуль, отсутствующий в авторской сборке 6.12.22, придётся пересобрать ядро или использовать стандартное ядро Debian (оно работает, но примерно втрое больше и дольше грузится).

Поддерживаемые гостевые системы

Carmo запускает на этом целый зоопарк систем, причём каждую реально загружал и проверял: "голая" Gitea со SQLite + Caddy, агент piclaw, управляющий всем кластером и запускающий Docker внутри себя, координатор распределённого инференса exo, а также - из любви к необычным ОС - 21 тип гостевых систем: от Debian/Alpine/Fedora/Rocky/Amazon Linux до OpenWrt, OPNsense, уникернелов OSv, Go-приложений gokrazy, SmolBSD (NetBSD, 31 мс через MMIO) и пока неактивной 9Front (Plan 9). Базовой тестовой платформой на износ служил безвентиляторный Atom x5-Z8350 2016 года с 2 ГБ RAM, на котором заработали шесть microVM, прежде чем система начала замедляться - проверка по принципу "если работает здесь, заработает везде".

Список наблюдения

В watchlist: версия v0.3.x, один автор, поддержка только Proxmox и жёсткая зависимость от патчинга внутренних модулей Perl апстрима, которые проект не контролирует. Стоит вернуться и проверить, когда версия станет более зрелой, появится ли второй мейнтейнер или закроют ли патчами от сообщества проблемы с MMIO/Linux и пробросом GPU - Carmo открыто просит помощи с тем и другим, но сам тратить на это время не успевает.

Связанные страницы

• qemu-microvm - тип машины QEMU, который этот проект упаковывает для Proxmox (и транспорт MMIO, который пока не удаётся надёжно использовать для гостей с Linux)
• microvm - архитектурная концепция; microvm-2026 - обзор индустрии microVM и песочниц для агентов за 2026 год
• sandboxing-ai-agents - более широкая классификация песочниц для агентов; matryoshka-isolation - эшелонированная защита "контейнеры внутри VM"
• proxmox-manager - TUI для управления теми же гостевыми системами Proxmox

Репозиторий: github.com/rcarmo/pve-microvm - ~320 звёзд, Apache-2.0. Анонсирован на taoofmac.com. Источник: pve-microvm-taoofmac.