Чи запустить ваш VPS microVM Firecracker

Чи може ваш VPS запускати microVM Firecracker?

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

Тому перше питання — не те, який інструмент microVM встановити. Потрібно з’ясувати, чи може вже оплачувана вами машина взагалі розміщувати 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 це нормальна й очікувана ситуація. У третьому рядку наведено кількість ядер CPU, які повідомляють про наявність прапорця апаратної віртуалізації: vmx на Intel і svm на AMD. Ненульове значення всередині гостьової системи означає, що гіпервізор надає вам вкладену віртуалізацію.

Потім перевірте, чи може ваш користувач відкрити пристрій. Це тест із власної інструкції 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. Це можна виправити в мікропрограмі. На VPS таке повідомлення трапляється рідко, оскільки ви не працюєте з реальною мікропрограмою.

Що означає кожна відповідь щодо /dev/kvm?

Вузол існує, а кількість прапорців більша за нуль. У вас доступна апаратна віртуалізація, тому Firecracker працюватиме. Перейдіть до розділу про визначення розміру, оскільки ваше обмеження стосується вже не функцій CPU, а пам’яті.

Вузла немає, systemd-detect-virt виводить kvm або qemu, а кількість прапорців дорівнює 0. Ваш VPS є віртуальною машиною, хост якої не передає функції віртуалізації гостьовій системі. Ніщо з установленого всередині гостьової системи цього не змінить, оскільки прапорець є властивістю віртуального CPU, який для вас створив гіпервізор. sudo modprobe kvm_intel завершується помилкою modprobe: ERROR: could not insert 'kvm_intel': Operation not supported, а sudo dmesg | grep -i kvm фіксує відсутність апаратної підтримки. Це типовий випадок для спільних VPS-тарифів. Запитайте провайдера, чи підтримує тариф вкладену віртуалізацію. Якщо ні, вам потрібен інший хостинг, а не інша команда.

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, а не контейнер

Контейнер — це процес у вашому ядрі, ізольований за допомогою просторів імен та cgroups. Ядро одне й воно належить вам, тому вразливість для обходу ізоляції на рівні ядра дає змогу потрапити на хост. microVM запускає власне ядро всередині межі апаратної віртуалізації та взаємодіє з невеликою моделлю емуляції пристроїв, а не з повним набором системних викликів хоста. Firecracker навмисно підтримує цю модель малою. У цьому й полягає принцип її побудови: що менше емуляційних пристроїв, то менше способів обійти ізоляцію.

Ця відмінність важлива для coding agent, оскільки код, який запускає агент, спочатку ніхто не перевірив. Агент встановлює пакети, запускає build scripts і повторює невдалі операції зі швидкістю машини. Окреме ядро означає, що невдалий крок пошкодить лише машину, яку можна видалити, і більше нічого.

Вимога безпосередньо випливає з механізму. Для апаратної ізоляції потрібна апаратна віртуалізація, а саме її може не підтримувати ваш VPS plan. Контейнеру це не потрібно, тому контейнери працюють на будь-якому плані, який коли-небудь продавали.

Тому коли /dev/kvm відсутня, контейнерна одноразова VM для coding agents залишається правильним рішенням і є повноцінним засобом контролю, а не тимчасовою заміною. Одноразовий контейнер на хості, де немає важливих для вас облікових даних, відновлений зі snapshot щоразу, коли починає працювати неправильно, усуває більшість реальних наслідків таких помилок. Те саме стосується простішого варіанта в запуску coding agent на VPS. Обирайте microVM, коли агент працюватиме без нагляду годинами з кодом, який ви ще не перевірили, а хост належить вам і ви можете його видалити.

Що потрібно хосту для microVM-агента

Nehemiah — актуальний приклад такого класу систем: це демон за ліцензією Apache-2.0, який на вимогу надає AI реальну Linux-машину — по одній Firecracker microVM на машину. У README вимогу сформульовано однозначно: «Linux-машина з /dev/kvm», а точніше — «Ubuntu 24.04, x86_64 або arm64, з /dev/kvm (bare-metal або VM із nested virtualization), до якої можна підключитися через 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 toolchain, kernel і root filesystem для гостьової системи, гостьовий Python image, необов’язковий desktop image із браузером, а також два systemd units з назвами nehemiahd.service і boring-net.service. Потім демон починає приймати запити на порту 8080, а невдала health check виводить /healthz didn't return ok. SKIP_DESKTOP=1 пропускає desktop image, складання якого, за даними README, займає близько 8 хвилин.

Прочитайте застереження, перш ніж вставляти цю команду

Для роботи потрібен root SSH на новому хості. Інсталятор встановлює системні пакети, unit-файли 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. У проєкті зазначено, що гостьові системи працюють за egress firewall, а сама межа ізоляції є реальною. Гостьова система все одно має доступ до мережі за задумом, оскільки coding agent, який не може завантажити пакет, непридатний для роботи. Плануйте конфігурацію з урахуванням цього, а не припускайте наявність air gap.

Позначеного релізу немає. Станом на 10 August 2026 у репозиторії взагалі немає тегів, тому клонування main дасть вам версію, яка потрапила до репозиторію того ранку. Зафіксуйте commit і прочитайте скрипт до його запуску від імені root на сервері:

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

Репозиторій створено наприкінці June 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 містить повноцінне гостьове ядро та призначений їй обсяг пам’яті. Ця пам’ять резервується на весь час роботи машини. Тому розмір host потрібно визначати за розміром guest і кількістю машин, які мають працювати одночасно. Наведені нижче значення є арифметичним розрахунком, а не результатами вимірювань. Headless guest отримує 1 GB, а desktop guest із браузером — 2 GB. Host резервує для себе, daemon і складання образів фіксовані 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
  }
]

Для однієї headless machine потрібно приблизно 3 GB. Цей обсяг може забезпечити VPS середнього розміру, якщо він надає KVM. Для чотирьох таких машин потрібно 6 GB. Для 8 desktop machines той самий розрахунок дає 18 GB без урахування навіть одного гігабайта дискового простору.

Диск — це ресурс, про який найчастіше не планують заздалегідь. Host зберігає ядро guest, базову root filesystem, по одному образу для кожного типу guest і snapshot для кожної запущеної машини. Образ desktop guest із браузером є найбільшим. У README немає значення обсягу диска, тому під час першого складання стежте за df -h /, а не покладайтеся на припущення.

Тому чесна відповідь на запитання «який VPS запускає Firecracker» часто звучить так: «інший клас машин». Bare metal надає потрібні CPU flags без проміжного hypervisor. Це компроміс, описаний у матеріалі як вибрати між VPS і виділеним сервером. Деякі провайдери справді надають nested virtualisation на віртуальних тарифах. У матеріалі nested virtualisation на VPS описано, як перевірити це до оплати. Якщо обладнання вже належить вам, Proxmox замість звичайного VPS розглядає те саме питання з боку hypervisor.

Сервер — лише половина витрат. Кожна машина, яку ви передаєте agent, витрачає model tokens протягом усього часу роботи. Тому idle microVM споживає пам’ять, а зайнята microVM — пам’ять і кошти на API. Тариф на 1 GB не може вмістити host. Навіть тариф, якого достатньо для host, не забезпечить оплату ключа.

FAQ

Як перевірити, чи може мій VPS запускати Firecracker?

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

Чи можна ввімкнути вкладену віртуалізацію зсередини VPS?

Ні. Вкладену віртуалізацію вмикає хост у власному kernel module гіпервізора. До вашої системи вона надходить як CPU flag у наданому вам віртуальному процесорі. Усередині guest sudo modprobe kvm_intel повертає modprobe: ERROR: could not insert 'kvm_intel': Operation not supported, оскільки віртуальний CPU не має VMX для використання. Варіанти: обрати провайдера, який пропонує вкладену віртуалізацію у вашому плані, або використовувати машину, на якій ви керуєте гіпервізором.

Чи достатньо контейнера для ізоляції coding agent?

Часто так. Контейнер використовує спільне ядро, тому escape на рівні ядра досягає хоста. Водночас одноразовий контейнер на машині, де немає цінних облікових даних, усуває більшість реальних ризиків. Обирайте microVM, якщо agent тривалий час працює без нагляду з неперевіреним кодом і ви можете надати йому хост із /dev/kvm. Якщо це неможливо, контейнер, який ви знищуєте після кожного завдання, кращий за microVM, яку вам так і не вдається запустити.

Скільки RAM потрібно хосту для agent у microVM?

Почніть із розміру guest. Один headless guest із 1 GB RAM і резервом хоста 2 GB потребує загалом приблизно 3 GB, а 8 desktop guests по 2 GB кожен потребують приблизно 18 GB. Диск потрібно рахувати окремо. Його легко недооцінити, оскільки хост зберігає kernel, root filesystems, по одному image для кожного типу guest і snapshot для кожної запущеної машини.