EnglishРусский Map

rust-vmm

title
rust-vmm
type
entity
summary
Экосистема Rust-крейтов в основе большинства современных VMM (kvm-ioctls, vm-memory, virtio-queue, vhost-user) под совместным управлением вендоров
tags
virtualization, rust, infrastructure, open-source
created
2026-05-03
updated
2026-05-03
lang
ru
translation_of
rust-vmm
source_updated
2026-05-03
translated
2026-09-01
translator
lllm/antigravity/gemini-3.7-flash-medium

rust-vmm - открытый проект группы вендоров, предоставляющий общие Rust-крейты, на которых строятся почти все современные реализации microVM. Запущен в 2018 году одновременно с Firecracker; управляется совместно AWS, Intel, Google, Microsoft, Red Hat, Alibaba и Linaro. Замысел простой: вместо того чтобы каждый VMM заново писал KVM-биндинги, virtio-очереди, бэкенды устройств vhost-user и менеджеры памяти, делать эти крейты общими и дорабатывать в одном месте.

К 2026 году эта архитектура лежит в основе Firecracker, Cloud Hypervisor, libkrun, Dragonball, crosvm и множества их производных. Улучшение в vm-memory появляется один раз и достаётся всем; кампания по фаззингу или формальной верификации virtio-queue сразу защищает все нижележащие VMM. Индустриальный контекст разобран в microvm-2026.

Что внутри

Проект выпускает крейты четырёх основных категорий:

  • База для VM. kvm-ioctls, kvm-bindings, mshv-ioctls (гипервизор Microsoft под Windows), xen-ioctls, linux-loader - низкоуровневые интерфейсы к гипервизорам хоста и загрузка гостевого ядра.
  • Управление ресурсами. vm-allocator, vm-memory - области памяти гостя, поддержка IOMMU, интеграция с guest_memfd и формальная верификация свойств безопасности с помощью Kani.
  • Эмуляция устройств. virtio-queue, virtio-bindings, vhost, vhost-user-backend, vfio-ioctls - плоскость данных virtio и протокол для выноса эмуляции устройств в отдельный процесс (vhost-user).
  • Бэкенды устройств vhost-user. can, console, gpio, gpu, i2c, input, rng, scmi, scsi, sound, spi, video, vsock, virtiofsd. Готовые реализации устройств, которые может подключить любой VMM.

Структура репозиториев: исторически это было созвездие небольших крейтов, но на FOSDEM 2026 объявили об объединении в монорепозиторий для снижения накладных расходов на координацию. В этот же период добавили поддержку архитектуры RISC-V.

Почему это работает

Любопытна сама модель управления: крейты rust-vmm поставляются как строительные блоки, а не как готовый VMM. AWS по-прежнему выпускает Firecracker; Intel - Cloud Hypervisor; Red Hat - libkrun. Каждый вендор конкурирует на уровне интеграции поверх общих крейтов и на эксплуатационной обвязке (образы rootfs, снапшоты, интеграция с контейнерами). Сами же крейты стали коммодити.

Это редкий результат: несколько коммерческих продуктов для виртуализации вместе разрабатывают базовую библиотеку и продают конкурирующие решения поверх неё. Модель работает, потому что базовый код (KVM-биндинги, очереди virtio) действительно у всех один, на нём никто не выстраивает продуктовые отличия, а выигрыш в безопасности и производительности от общей формальной верификации и фаззинга огромен.

Формулировка Бегановича из microvm-2026: "улучшения идут на пользу всем downstream-проектам одновременно. Доработка vm-memory одинаково помогает Firecracker, Cloud Hypervisor, libkrun, Dragonball и crosvm".

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

Тезис о "моменте Docker" в microvm-2026 во многом опирается на rust-vmm. Большинство рассмотренных платформ для песочниц ИИ-агентов (E2B, Vercel Sandbox, Microsandbox, SlicerVM, Matchlock и другие) вышли за месяцы, а не за годы. Это удалось именно потому, что тяжёлая базовая работа - KVM-биндинги, плоскость данных virtio, эмуляция устройств, безопасность памяти - уже была сделана. Новые разработчики строили интеграцию, планировщики и UX оператора поверх зрелых общих крейтов.

В гипотетическом сценарии, где каждый автор ИИ-песочницы писал бы свой VMM с нуля, индустрия отставала бы на 3-5 лет от текущего состояния, а большинство участников выпустили бы кривые гипервизоры вместо шероховатого UX.

Свойства безопасности на уровне крейтов

  • Для ряда операций в vm-memory свойства верифицированы через Kani - это полноценная формальная верификация, а не только фаззинг
  • Интеграция с guest_memfd уменьшает поверхность атаки при разделении памяти между гостем и хостом по сравнению с классическими bounce buffer'ами virtio
  • vhost-user изолирует процессы эмуляции устройств от самого VMM, поэтому ошибка в virtio-net не даёт доступа к памяти VMM
  • Поддержка IOMMU в vm-memory позволяет VMM давать устройствам доступ к DMA, сохраняя при этом ограничения

Репозитории и ссылки

  • Организация: github.com/rust-vmm
  • Состояние (2026): идёт переход на монорепозиторий; добавлена поддержка RISC-V; активная поддержка пулом вендоров

См. также

  • microvm-2026 - разбор Бегановича, задающий индустриальный контекст для rust-vmm
  • microvm - архитектура, которую реализует rust-vmm
  • matryoshka-isolation - паттерн, развёртывание которого этот базис делает достаточно дешёвым
  • supply-chain-security - смежная тема: общие крейты несут и общие риски цепочки поставок