EnglishРусский Map
MicroVM

Тип машины QEMU microvm

title
Тип машины QEMU microvm
type
entity
summary
Урезанный тип машины x86 в QEMU: без PCI и ACPI, только virtio-mmio, прошивка qboot, прямая загрузка ядра и выключение через triple fault
parent
microvm
tags
virtualization, qemu, microvm
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 ROM
  • pit=OnOffAuto - i8254 PIT
  • pic=OnOffAuto - i8259 PIC
  • rtc=OnOffAuto - MC146818 RTC
  • isa-serial=bool - последовательный порт ISA
  • auto-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