Как проверить поддержку Firecracker microVM на VPS

Может ли ваш VPS запускать microVM Firecracker?

Ваш VPS может запускать microVM Firecracker только в том случае, если он предоставляет /dev/kvm. Firecracker — это VMM (монитор виртуальных машин), построенный на базе KVM (kernel-based virtual machine), уровня виртуализации внутри Linux, а KVM требуются инструкции виртуализации от процессора. На VPS вы получаете эти инструкции только тогда, когда провайдер пробрасывает их в вашу гостевую систему, что делает большинство тарифных планов.

Поэтому первый вопрос заключается не в том, какой инструмент для microVM установить. Вопрос в том, может ли машина, за которую вы уже платите, вообще их размещать. Это вопрос хостинга, и вы можете ответить на него примерно за минуту.

Проверка /dev/kvm перед установкой

Выполните эти три команды непосредственно на VPS.

ls -l /dev/kvm
systemd-detect-virt
grep -cE '\b(vmx|svm)\b' /proc/cpuinfo

Сервер, способный запускать microVM, выдаст следующий ответ:

crw-rw---- 1 root kvm 10, 232 Aug 10 09:12 /dev/kvm
kvm
16

Первая строка указывает на узел устройства KVM, владельцем которого является группа kvm. Вторая строка означает, что сама машина является гостевой системой, работающей под управлением KVM, что является нормальным и ожидаемым поведением для VPS. Третья строка подсчитывает количество ядер процессора, у которых установлен флаг аппаратной виртуализации: vmx для Intel и svm для AMD. Значение больше нуля внутри гостевой системы означает, что гипервизор предоставляет вам доступ к вложенной виртуализации (nested virtualization).

Затем убедитесь, что ваш пользователь может открыть это устройство. Это тест из официальной документации по началу работы с Firecracker:

[ -r /dev/kvm ] && [ -w /dev/kvm ] && echo "OK" || echo "FAIL"

Ошибка FAIL при наличии узла устройства указывает на проблему с правами доступа, а не с оборудованием. Предоставьте доступ своему пользователю с помощью sudo setfacl -m u:${USER}:rw /dev/kvm или добавьте себя в группу командой sudo usermod -aG kvm ${USER} и выполните повторный вход в систему.

В Ubuntu также есть встроенная проверка, которая суммирует всё вышесказанное в две строки вывода:

sudo apt update && sudo apt install -y cpu-checker msr-tools
sudo kvm-ok

Рабочий хост выведет INFO: /dev/kvm exists, а затем KVM acceleration can be used. Нерабочий хост выведет INFO: Your CPU does not support KVM extensions, а затем KVM acceleration can NOT be used. На физическом сервере вы можете увидеть INFO: KVM (vmx) is disabled by your BIOS, что исправляется в настройках прошивки (firmware). На VPS такое сообщение встречается редко, так как вы не имеете прямого доступа к реальной прошивке.

Что означают ответы для /dev/kvm?

Узел существует, а количество флагов больше нуля. У вас есть аппаратная виртуализация, поэтому Firecracker будет работать. Переходите к разделу о выборе размера ресурсов, так как вашим основным ограничением будет объем памяти, а не возможности процессора.

Узел отсутствует, systemd-detect-virt выводит kvm или qemu, а количество флагов равно 0. Ваш VPS — это виртуальная машина, хост которой не пробрасывает функции виртуализации внутрь. Никакие действия внутри гостевой системы не изменят ситуацию, так как флаг является свойством виртуального процессора, созданного гипервизором. sudo modprobe kvm_intel завершится с ошибкой modprobe: ERROR: could not insert 'kvm_intel': Operation not supported, а sudo dmesg | grep -i kvm зафиксирует отсутствие аппаратной поддержки. Это типичная ситуация для стандартных тарифов VPS. Уточните у провайдера, поддерживает ли тариф вложенную виртуализацию (nested virtualization). Если нет, вам потребуется другой хостинг, а не другие команды.

systemd-detect-virt выводит lxc, lxc-libvirt или openvz. Ваш тариф использует контейнерную виртуализацию, поэтому вы используете общее ядро хоста. /dev/kvm никогда не появится, так как у вас нет собственного ядра, в которое можно было бы загрузить модуль. Никакие пакеты не решат эту проблему.

Флаги присутствуют, а узла нет. Модуль просто не загружен. Выполните sudo modprobe kvm_intel (или kvm_amd для AMD) и снова проверьте ls -l /dev/kvm. Если узел появился, запишите имя модуля в /etc/modules-load.d/kvm.conf, чтобы он загружался автоматически после перезагрузки.

Вы используете архитектуру arm64. vmx и svm — это названия для x86, поэтому счетчик grep будет равен 0 на любой машине с arm64, независимо от её работоспособности. На arm64 ориентируйтесь на наличие узла устройства и результаты тестов на чтение и запись.

Почему для работы агента лучше использовать microVM, а не контейнер

Контейнер — это процесс в вашем ядре, изолированный с помощью namespaces и cgroups. Ядро одно, и оно принадлежит вам, поэтому выход на уровень ядра означает компрометацию хоста. MicroVM загружает собственное ядро внутри границы аппаратной виртуализации и взаимодействует с небольшой моделью эмулируемых устройств, а не со всей поверхностью системных вызовов вашего хоста. Firecracker намеренно сохраняет эту модель минималистичной, в этом и заключается вся концепция: меньше эмулируемых устройств — меньше путей для выхода наружу.

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

Это требование напрямую вытекает из механизма работы. Аппаратная изоляция требует аппаратной виртуализации, а аппаратная виртуализация — это именно то, чего может не быть в вашем тарифном плане VPS. Контейнеру она не нужна, поэтому контейнеры работают на любом тарифном плане.

Поэтому, когда /dev/kvm отсутствует, контейнерный вариант одноразовой VM для агентов разработки остается верным решением, и это полноценный инструмент контроля, а не утешительный приз. Одноразовый контейнер на хосте, где нет важных для вас учетных данных, восстанавливаемый из снимка при сбоях, предотвращает большинство реальных проблем. То же самое верно и для более простого варианта настройки запуска агента разработки на VPS. Используйте microVM, если агент будет работать без присмотра в течение нескольких часов с кодом, который вы не проверяли, и если хост находится в вашем полном распоряжении.

Требования хоста для агента microVM

Nehemiah — актуальный пример такого класса ПО: демон с лицензией Apache-2.0, который по запросу предоставляет ИИ полноценную машину Linux, по одной microVM Firecracker на каждую машину. В файле README прямо указано требование: «машина Linux с /dev/kvm», а точнее — «Ubuntu 24.04, x86_64 или arm64, с /dev/kvm (bare-metal или VM с поддержкой вложенной виртуализации), к которой есть root-доступ по SSH».

Документированная процедура установки сводится к одной команде, выполняемой на этой машине:

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah && npm install
NEHEMIAH_ANTHROPIC_KEY=sk-ant-... ./infra/setup.sh root@YOUR_BOX_IP

infra/setup.sh выполняет предварительную проверку по SSH и прерывает работу, если параметры машины не соответствуют требованиям. Вот два сообщения об отказе из-за аппаратных ограничений:

/dev/kvm missing — the box needs hardware/nested virtualization
box arch is ${ARCH}; nehemiahd needs x86_64 or aarch64

Первая строка — это суть данной статьи. Установщик задает тот же вопрос, который вы только что задали с помощью ls -l /dev/kvm, и на большинстве тарифных планов VPS получает такой же разочаровывающий ответ.

После прохождения предварительной проверки начинается установка на всю машину: Firecracker и его jailer, набор инструментов Go, гостевое ядро и корневая файловая система, гостевой образ Python, опциональный образ рабочего стола с браузером, а также два юнита systemd с именами nehemiahd.service и boring-net.service. Затем демон начинает принимать запросы на порту 8080, а при неудачной проверке работоспособности выводит /healthz didn't return ok. Флаг SKIP_DESKTOP=1 позволяет пропустить сборку образа рабочего стола, которая, согласно README, занимает около 8 минут.

Ознакомьтесь с предостережениями перед выполнением этой команды

Для работы требуется root-доступ по SSH на чистом хосте. Установщик записывает системные пакеты, юниты systemd и конфигурацию сети с правами root. Используйте машину, которую вы готовы переустановить с нуля, а не сервер, на котором уже работают ваши сайты.

По умолчанию демон слушает 0.0.0.0:8080. Любой, кто получит доступ к этому порту, сможет создавать машины, которые будут расходовать ваш ключ модели, переданный установщику. Настройте NEHEMIAH_TOKEN для обязательной аутентификации или установите BIND_LOCALHOST=1, чтобы демон слушал только 127.0.0.1, и подключайтесь к нему через туннель с помощью ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP. К этому ключу нужно относиться так же бережно, как и к любому другому секрету на сервере, как описано в защите секретов от AI-агентов.

Каждая машина — это компьютер с доступом в Интернет и предустановленными агентами. В README перечислены claude, codex, cursor и pi внутри гостевой системы, наряду с node, python и git. Проект заявляет, что гостевые системы находятся за исходящим файрволом, и граница изоляции действительно существует. Тем не менее, гостевая система по замыслу имеет доступ к сети, так как кодинг-агент, не способный загрузить пакет, бесполезен. Учитывайте это, а не полагайтесь на полную изоляцию (air gap).

Отсутствуют тегированные релизы. По состоянию на 10 августа 2026 года в репозитории нет ни одного тега, поэтому клонирование main загрузит версию, актуальную на текущее утро. Фиксируйте версию по хешу коммита и читайте скрипт перед тем, как запускать его с правами root на своем сервере:

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah
git checkout ae743fd5c05aecb6ae4bb52bac6bce198b01ebaa
less infra/setup.sh

Репозиторий был создан в конце июня 2026 года, поэтому относитесь к нему как к новому программному обеспечению. Перечитывайте infra/setup.sh после каждого обновления, так как вы предоставляете root-доступ к машине, а не просто обновляете версию библиотеки.

Проверьте работу KVM, прежде чем винить установщик

Если установка завершается с ошибкой и вы хотите понять, является ли KVM причиной, протестируйте Firecracker отдельно. Ниже приведены шаги для загрузки из upstream:

ARCH="$(uname -m)"
release_url="https://github.com/firecracker-microvm/firecracker/releases"
latest=$(basename $(curl -fsSLI -o /dev/null -w %{url_effective} ${release_url}/latest))
curl -L ${release_url}/download/${latest}/firecracker-${latest}-${ARCH}.tgz | tar -xz
./release-${latest}-${ARCH}/firecracker-${latest}-${ARCH} --version

Успешный вывод версии подтверждает, что бинарный файл соответствует вашей архитектуре и запускается. Это не доказывает наличие доступа к KVM, поэтому выполните тест на чтение и запись для /dev/kvm, описанный ранее. В совокупности эти два теста позволяют отделить проблему хостинга от проблемы пакета, что избавит вас от отладки установщика, который изначально работал корректно.

Сколько ресурсов сервера требуется для нескольких microVM?

Каждая microVM содержит полноценное гостевое ядро и выделенный объем оперативной памяти, который резервируется на всё время работы машины. Поэтому рассчитывайте ресурсы хоста исходя из требований гостевых систем и их количества. Приведенные ниже цифры являются арифметическим расчетом, а не результатами замеров. Гостевой системе без графического интерфейса требуется 1 GB, а системе с рабочим столом и браузером — 2 GB. Хост должен резервировать 2 GB для собственных нужд, работы демона и сборки образов.

[
  {
    "label": "1 headless guest",
    "guests": 1,
    "guest_ram_gb": 1,
    "host_ram_gb": 3
  },
  {
    "label": "4 headless guests",
    "guests": 4,
    "guest_ram_gb": 1,
    "host_ram_gb": 6
  },
  {
    "label": "4 desktop guests",
    "guests": 4,
    "guest_ram_gb": 2,
    "host_ram_gb": 10
  },
  {
    "label": "8 desktop guests",
    "guests": 8,
    "guest_ram_gb": 2,
    "host_ram_gb": 18
  }
]

Для запуска одной машины без графического интерфейса требуется около 3 GB, что доступно на VPS среднего размера с поддержкой KVM. Четырем таким машинам потребуется 6 GB. Запуск 8 машин с графическим интерфейсом согласно этой арифметике потребует 18 GB, без учета дискового пространства.

Дисковое пространство — это ресурс, который часто не планируют заранее. Хост хранит гостевое ядро, базовую корневую файловую систему, по одному образу на каждый тип гостя и по одному снимку на каждую запущенную машину; образ с графическим интерфейсом и браузером является наиболее объемным. В README не указаны точные цифры по диску, поэтому следите за df -h / во время первой сборки, вместо того чтобы полагаться на догадки.

Именно поэтому честный ответ на вопрос «какой VPS подходит для Firecracker» часто звучит как «сервер другого класса». Bare metal предоставляет необходимые CPU flags без прослойки в виде гипервизора, что является ключевым фактором при выборе между VPS и выделенным сервером. Некоторые провайдеры предоставляют вложенную виртуализацию (nested virtualisation) на виртуальных тарифах, а в статье вложенная виртуализация на VPS описано, как проверить её наличие до оплаты. Если оборудование уже находится в вашем распоряжении, то сравнение Proxmox и обычного VPS — это тот же вопрос, но с точки зрения гипервизора.

Сервер — это лишь менее затратная часть расходов. Каждая машина, которую вы передаете агенту, потребляет токены модели всё время, пока она запущена, поэтому простаивающая microVM расходует только память, а активная — память и средства на API. Тарифный план с 1 GB памяти не сможет вместить хост. План, способный вместить хост, всё равно не покроет расходы на ключ.

FAQ

Как проверить, может ли мой VPS запускать Firecracker?

Выполните ls -l /dev/kvm, systemd-detect-virt и grep -cE '\b(vmx|svm)\b' /proc/cpuinfo на VPS. Наличие устройства, принадлежащего группе kvm, при значении счетчика флагов выше нуля означает, что Firecracker может работать. Отсутствие узла при значении счетчика 0 означает, что гипервизор не пробрасывает виртуализацию, что подтверждается командой sudo kvm-ok из пакета cpu-checker с выводом KVM acceleration can NOT be used. На архитектуре arm64 игнорируйте значение счетчика, так как vmx и svm — это имена для x86.

Можно ли включить вложенную виртуализацию (nested virtualisation) изнутри VPS?

Нет. Вложенная виртуализация включается на хосте в модуле ядра гипервизора и передается вам в виде флага процессора на виртуальном CPU. Внутри гостевой системы sudo modprobe kvm_intel возвращает modprobe: ERROR: could not insert 'kvm_intel': Operation not supported, так как у виртуального процессора нет доступных инструкций VMX. Ваши варианты — выбрать провайдера, предлагающего вложенную виртуализацию в рамках тарифа, или использовать машину, на которой вы сами управляете гипервизором.

Достаточно ли контейнера для изоляции агента, выполняющего код?

Зачастую да. Контейнер использует общее с хостом ядро, поэтому побег на уровне ядра даст доступ к хосту, но использование одноразового контейнера на машине без критически важных учетных данных устраняет большинство реальных рисков. Выбирайте microVM, если агент работает без присмотра длительное время с непроверенным кодом и если вы можете предоставить ему хост с /dev/kvm. Если это невозможно, контейнер, который вы уничтожаете после каждой задачи, лучше, чем microVM, которую вы не можете запустить.

Сколько оперативной памяти нужно хосту для агента в microVM?

Отталкивайтесь от размера гостевой системы. Один headless-гость на 1 ГБ с резервом хоста в 2 ГБ требует в сумме около 3 ГБ, а 8 десктопных гостевых систем по 2 ГБ каждая потребуют около 18 ГБ. Дисковое пространство учитывается отдельно, и его легко недооценить, так как хост хранит ядро, корневые файловые системы, по одному образу на каждый тип гостевой системы и снапшот для каждой запущенной машины.