Тип машины QEMU microvm
- title
- Тип машины QEMU microvm
- type
- entity
- summary
- Урезанный тип машины x86 в QEMU: без PCI и ACPI, только virtio-mmio, прошивка qboot, прямая загрузка ядра и выключение через triple fault
- parent
- microvm
- tags
- virtualization, qemu, microvm
- sources
- qemu-microvm-docs
- created
- 2026-05-06
- updated
- 2026-07-21
- lang
- ru
- translation_of
- qemu-microvm
- source_updated
- 2026-07-21
- translated
- 2026-09-01
- translator
- lllm/antigravity/gemini-3.7-flash-medium
Тип машины в QEMU (-M microvm), созданный с явной оглядкой на Firecracker. Он вычищает из платформы i386 шины PCI, ACPI и большинство устаревших шин, заменяя обнаружение устройств фиксированной шиной virtio-mmio. За счёт этого сам QEMU может служить основой для microVM наряду с альтернативами на Rust из rust-vmm. В апстрим-документации позиционируется как "базовый уровень для бенчмаркинга и оптимизации как самого QEMU, так и гостевых операционных систем" - полезный ориентир эпохи языка C, с которым сравнивают Firecracker и Cloud Hypervisor.
Что есть, чего нет
Машина включает шину ISA, LAPIC, IOAPIC (kernel-irqchip=split по умолчанию), kvmclock под KVM, fw_cfg и до восьми слотов virtio-mmio. Опциональные устаревшие устройства: i8259 PIC, i8254 PIT, MC146818 RTC и один последовательный порт ISA - каждое из них можно переключать через свойства машины.
Явно не поддерживаются:
- Устройства, работающие только через PCI (всё, что требует механизма обнаружения PCI)
- Горячее подключение (hotplug)
- Живая миграция между версиями QEMU (snapshot/migrate работает только внутри одной версии)
Принципиальным здесь является решение "без PCI и без ACPI". PCI даёт перечисление устройств и hotplug ценой внушительной площади эмуляции; ACPI даёт таблицы, управление питанием и стандартный путь выключения. Отказ от обоих вынуждает использовать virtio-mmio для ввода-вывода и triple fault для выключения - ровно такой компромисс выбирают платформы microvm.
Процесс загрузки
По умолчанию QEMU microvm использует qboot (минимальную прошивку, совместимую с SeaBIOS), однако эта прошивка не умеет загружаться с блочных устройств virtio-mmio. Поэтому хост передаёт ядро напрямую через флаг -kernel vmlinux (и опционально -initrd) - тот же путь прямой загрузки ядра (direct kernel boot), что использует Firecracker. Загрузка с диска на уровне BIOS отсутствует; rootfs подключается через virtio-mmio, когда ядро уже запущено.
Свойства машины
Настраиваются через -M microvm,<prop>=<value>:
x-option-roms=bool- отключение загрузки Option ROMpit=OnOffAuto- i8254 PITpic=OnOffAuto- i8259 PICrtc=OnOffAuto- MC146818 RTCisa-serial=bool- последовательный порт ISAauto-kernel-cmdline=bool- автоподстановка дескрипторов устройств virtio-mmio в cmdline ядра
Свойства OnOffAuto по умолчанию имеют значение auto, оставляя устаревшие устройства включёнными ради совместимости. Если отключить их все, получается вариант с минимальным потреблением ресурсов, для которого требуется поддержка TSC_DEADLINE у процессора хоста, чтобы таймер LAPIC заменил PIT.
Использование
Базовый запуск с включёнными устаревшими устройствами:
qemu-system-x86_64 -M microvm \
-enable-kvm -cpu host -m 512m -smp 2 \
-kernel vmlinux -append "earlyprintk=ttyS0 console=ttyS0 root=/dev/vda"
Вариант с минимальным футпринтом (требует KVM с TSC_DEADLINE, отключает все опциональные устаревшие устройства):
qemu-system-x86_64 \
-M microvm,x-option-roms=off,pit=off,pic=off,isa-serial=off,rtc=off
Выключение
Без ACPI и без эмулируемой клавиатуры пути для мягкого выключения (soft-off) нет. Общепринятый подход - спровоцировать triple fault для перезагрузки. В cmdline ядра добавляют reboot=t, чтобы Linux выбирал путь через triple fault; на стороне QEMU это дополняют флагом -no-reboot, чтобы QEMU завершал работу вместо перезапуска гостя. Это тот же паттерн, что использует Firecracker, за вычетом обвязки на стороне хоста.
Место рядом с Firecracker
QEMU microvm и Firecracker сходятся в архитектурных решениях - virtio-mmio, прямая загрузка ядра, отказ от PCI/ACPI, - но различаются кодовой базой вокруг них. QEMU - это VMM классической эпохи C (~1,7 млн строк кода), из которого вырезали microvm; rust-vmm - современная экосистема на Rust, написанная с нуля вокруг тех же архитектурных решений. Firecracker содержит ~83 тыс. строк кода на Rust, Cloud Hypervisor - ~106 тыс. Обе кодовые базы на порядок меньше всего объёма QEMU, хотя тип машины microvm и задействует лишь часть последнего.
Практический вывод для сценариев sandboxing-ai-agents: QEMU microvm полезен, когда вам нужна семантика минимальной microVM поверх уже имеющегося развёртывания QEMU, когда для matryoshka-isolation требуется бэкенд Kata Containers или когда нужна возможность, которую разработчики Firecracker отказались добавлять. Для создания песочниц агентов с нуля актуальным выбором остаются VMM на Rust - см. обзор платформ в microvm-2026.
См. также
- microvm - архитектурная концепция, которую это реализует
- microvm-2026 - обзор индустрии от Бегановича за 2026 год
- rust-vmm - современная альтернативная экосистема, переписанная на Rust
- matryoshka-isolation - Kata Containers и похожие паттерны, где QEMU microvm является одним из поддерживаемых бэкендов
- sandboxing-ai-agents - общая таксономия изоляции в песочницах
- pve-microvm - оформляет этот тип машины как управляемого гостя Proxmox VE; примечателен откатом с virtio-mmio на устройства PCIe non-transitional из-за того, что MMIO в QEMU 10.x не может привязать net/serial/balloon для гостевых систем Linux
- spindle-microvm - использует этот тип машины как CI-движок для каждого workflow в Tangled с гостевым агентом vsock и конфигурацией NixOS-from-YAML
- qemu-microvm-docs - исходная документация апстрима QEMU