Czy mój VPS obsługuje Firecracker microVM?

Czy VPS może uruchamiać mikro-VM Firecracker?

Twój VPS może uruchamiać mikro-VM Firecracker tylko wtedy, gdy zapewnia /dev/kvm. Firecracker to VMM (monitor maszyn wirtualnych) zbudowany w oparciu o KVM (kernel-based virtual machine), czyli warstwę wirtualizacji wewnątrz systemu Linux, a KVM wymaga instrukcji wirtualizacji od procesora. Na VPS otrzymujesz te instrukcje tylko wtedy, gdy dostawca przekaże je do systemu gościa, a większość planów tego nie robi.

Zatem pierwsze pytanie nie dotyczy tego, jakie narzędzie mikro-VM zainstalować. Dotyczy ono tego, czy maszyna, za którą już płacisz, w ogóle może je hostować. Jest to kwestia hostingu, na którą możesz odpowiedzieć w około minutę.

Sprawdź /dev/kvm przed instalacją czegokolwiek

Wykonaj te trzy polecenia bezpośrednio na serwerze VPS.

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

Maszyna zdolna do hostowania microVM odpowiada w następujący sposób:

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

Pierwsza linia to węzeł urządzenia KVM, którego właścicielem jest grupa kvm. Druga linia oznacza, że ta maszyna sama jest gościem działającym w ramach KVM, co jest normalne i oczekiwane na serwerze VPS. Trzecia linia zlicza rdzenie procesora, które zgłaszają flagę wirtualizacji sprzętowej, vmx dla Intel oraz svm dla AMD. Liczba większa od zera wewnątrz gościa oznacza, że hypervisor udostępnia wirtualizację zagnieżdżoną.

Następnie sprawdź, czy użytkownik może otworzyć to urządzenie. Jest to test pochodzący z dokumentacji wprowadzającej Firecracker:

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

FAIL przy istniejącym węźle oznacza problem z uprawnieniami, a nie ze sprzętem. Przyznaj dostęp swojemu użytkownikowi za pomocą sudo setfacl -m u:${USER}:rw /dev/kvm lub dodaj się do grupy za pomocą sudo usermod -aG kvm ${USER} i zaloguj ponownie.

Ubuntu zawiera również narzędzie sprawdzające, które podsumowuje to wszystko w dwóch liniach wyjściowych:

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

Działający host wyświetla INFO: /dev/kvm exists, a następnie KVM acceleration can be used. Host, który nie działa, wyświetla INFO: Your CPU does not support KVM extensions, a następnie KVM acceleration can NOT be used. Na maszynie fizycznej można zamiast tego zobaczyć INFO: KVM (vmx) is disabled by your BIOS, co można naprawić w oprogramowaniu układowym (firmware). Na serwerze VPS ten komunikat występuje rzadko, ponieważ nie masz dostępu do rzeczywistego oprogramowania układowego.

Co oznaczają poszczególne odpowiedzi /dev/kvm?

Węzeł istnieje, a liczba flag jest większa od zera. Posiadasz wirtualizację sprzętową, więc Firecracker zadziała. Przejdź do sekcji dotyczącej doboru rozmiaru, ponieważ Twoim głównym ograniczeniem jest pamięć, a nie funkcje procesora.

Brak węzła, systemd-detect-virt zwraca kvm lub qemu, a liczba flag wynosi 0. Twój VPS jest maszyną wirtualną, której host nie przekazuje wirtualizacji. Żadna instalacja wewnątrz gościa tego nie zmieni, ponieważ flaga jest właściwością wirtualnego procesora utworzonego przez hiperwizor. sudo modprobe kvm_intel kończy się błędem modprobe: ERROR: could not insert 'kvm_intel': Operation not supported, a sudo dmesg | grep -i kvm rejestruje brak wsparcia sprzętowego. Jest to typowy przypadek w planach VPS współdzielonych. Zapytaj dostawcę, czy plan wspiera wirtualizację zagnieżdżoną (nested virtualisation). Jeśli odpowiedź brzmi nie, potrzebujesz innego hostingu, a nie innej komendy.

systemd-detect-virt zwraca lxc, lxc-libvirt lub openvz. Twój plan opiera się na wirtualizacji kontenerowej, więc współdzielisz jądro systemu z hostem. /dev/kvm nigdy się nie pojawi, ponieważ nie posiadasz własnego jądra, do którego mógłbyś załadować moduł. Żaden pakiet tego nie naprawi.

Flagi są obecne, ale węzła brak. Moduł po prostu nie jest załadowany. Uruchom sudo modprobe kvm_intel (lub kvm_amd w przypadku AMD) i sprawdź ponownie ls -l /dev/kvm. Jeśli węzeł się pojawi, wpisz nazwę modułu do /etc/modules-load.d/kvm.conf, aby ładował się automatycznie po restarcie.

Korzystasz z arm64. vmx i svm to nazwy dla architektury x86, więc licznik grep wynosi 0 na każdej maszynie arm64, niezależnie od tego, czy działa poprawnie. Na arm64 polegaj na obecności węzła urządzenia oraz na teście odczytu i zapisu.

Dlaczego microVM, a nie kontener do pracy agenta

Kontener to proces w jądrze systemu, odizolowany za pomocą przestrzeni nazw (namespaces) oraz cgroups. Istnieje tylko jedno jądro i jest ono wspólne, więc ucieczka na poziomie jądra oznacza przejęcie hosta. MicroVM uruchamia własne jądro wewnątrz granicy wirtualizacji sprzętowej i komunikuje się z niewielkim modelem emulowanych urządzeń, zamiast korzystać z pełnego interfejsu wywołań systemowych hosta. Firecracker celowo ogranicza ten model, co stanowi istotę projektu: mniej emulowanych urządzeń oznacza mniej dróg wyjścia.

Ta różnica ma znaczenie dla agenta programistycznego, ponieważ uruchamia on kod, którego nikt wcześniej nie sprawdził. Instaluje pakiety, wykonuje skrypty budowania i ponawia próby z prędkością maszyny, gdy coś zawiedzie. Osobne jądro sprawia, że błędny krok uszkodzi jedynie maszynę, którą można usunąć, i nic poza tym.

Wymaganie wynika bezpośrednio z mechanizmu działania. Izolacja sprzętowa wymaga wirtualizacji sprzętowej, a wirtualizacja sprzętowa jest dokładnie tym, czego może nie oferować plan VPS. Kontener nie potrzebuje jej wcale, dlatego kontenery działają na każdym sprzedawanym planie.

Zatem, gdy brakuje /dev/kvm, oparty na kontenerach jednorazowy VM dla agentów programistycznych pozostaje właściwym rozwiązaniem i stanowi realną kontrolę, a nie nagrodę pocieszenia. Jednorazowy kontener na hoście, który nie przechowuje żadnych istotnych poświadczeń i jest przywracany ze migawki w przypadku nieprawidłowego działania, eliminuje większość rzeczywistych zagrożeń. To samo dotyczy prostszej konfiguracji opisanej w uruchamianie agenta programistycznego na VPS. Wybierz microVM, gdy agent ma działać bez nadzoru przez wiele godzin, operując na kodzie, którego nie zweryfikowałeś, oraz gdy host jest w pełni pod Twoją kontrolą.

Czego wymaga agent microVM od hosta

Nehemiah jest aktualnym przykładem tego typu oprogramowania: to demon na licencji Apache-2.0, który na żądanie udostępnia sztucznej inteligencji pełnoprawną maszynę z systemem Linux, uruchamiając jedną microVM Firecracker na instancję. Plik README jasno określa wymagania: „maszyna z systemem Linux z /dev/kvm”, a dokładniej „Ubuntu 24.04, x86_64 lub arm64, z /dev/kvm (bare-metal lub maszyna wirtualna z zagnieżdżoną wirtualizacją), do której można uzyskać dostęp przez SSH z uprawnieniami root”.

Zalecana konfiguracja sprowadza się do jednego polecenia uruchamianego na docelowej maszynie:

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 przeprowadza wstępną weryfikację przez SSH i przerywa działanie, jeśli parametry maszyny są nieprawidłowe. Dwa komunikaty odmowy ze względu na sprzęt brzmią następująco:

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

Ten pierwszy ciąg znaków stanowi sedno niniejszego wpisu. Instalator zadaje to samo pytanie, które właśnie zadano przy użyciu ls -l /dev/kvm, a w przypadku większości planów VPS otrzymuje tę samą rozczarowującą odpowiedź.

Po przejściu weryfikacji następuje pełna instalacja: Firecracker wraz z narzędziem jailer, łańcuch narzędzi Go, jądro systemu gościa i główny system plików, obraz gościa z Pythonem, opcjonalny obraz pulpitu z przeglądarką oraz dwie jednostki systemd o nazwach nehemiahd.service i boring-net.service. Demon nasłuchuje następnie na porcie 8080, a nieudana kontrola stanu (health check) skutkuje wyświetleniem komunikatu /healthz didn't return ok. Flaga SKIP_DESKTOP=1 pomija obraz pulpitu, którego budowanie – jak podaje README – zajmuje około 8 minut.

Zapoznaj się z zastrzeżeniami przed wklejeniem polecenia

Wymagany jest dostęp root przez SSH do świeżego hosta. Instalator zapisuje pakiety systemowe, jednostki systemd oraz konfigurację sieci z uprawnieniami roota. Skieruj go na maszynę, którą możesz odtworzyć od zera, a nie na serwer, na którym już działa Twoja witryna.

Demon domyślnie nasłuchuje na 0.0.0.0:8080. Każdy, kto uzyska dostęp do tego portu, może tworzyć maszyny, które zużywają klucz modelu przekazany instalatorowi. Skonfiguruj NEHEMIAH_TOKEN, aby wymagać uwierzytelniania, lub ustaw BIND_LOCALHOST=1, aby demon nasłuchiwał wyłącznie na 127.0.0.1, a dostęp realizuj przez tunel z użyciem ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP. Klucz wymaga takiej samej ochrony jak każdy inny sekret na serwerze, zgodnie z przechowywanie sekretów poza zasięgiem agentów AI.

Każda maszyna to komputer z dostępem do Internetu i zainstalowanymi agentami. Plik README wymienia claude, codex, cursor oraz pi wewnątrz gościa, obok node, python i git. Projekt zakłada, że goście znajdują się za firewallem wyjściowym, a granica izolacji jest rzeczywista. Gość nadal uzyskuje dostęp do sieci zgodnie z założeniami, ponieważ agent programistyczny, który nie może pobrać pakietu, jest bezużyteczny. Zaplanuj to, zamiast zakładać izolację typu air gap.

Brak oznaczonego wydania. Na dzień 10 sierpnia 2026 repozytorium nie posiada żadnych tagów, więc klonowanie main pobiera wersję, która pojawiła się danego ranka. Przypnij wersję do konkretnego commita i przeczytaj skrypt, zanim uruchomisz go jako root na swoim serwerze:

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

Repozytorium powstało pod koniec czerwca 2026 roku, więc traktuj je jako młode oprogramowanie. Czytaj infra/setup.sh ponownie po każdej aktualizacji, ponieważ zatwierdzasz dostęp roota do maszyny, a nie zwykłą aktualizację wersji biblioteki.

Weryfikacja działania KVM przed podważeniem poprawności instalatora

Jeśli konfiguracja kończy się niepowodzeniem i zachodzi potrzeba ustalenia, czy przyczyną jest KVM, należy przetestować Firecracker w izolacji. Poniżej przedstawiono kroki pobierania z oficjalnego źródła:

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

Wyświetlenie wersji potwierdza, że plik binarny jest zgodny z architekturą systemu i uruchamia się poprawnie. Nie dowodzi to jednak dostępu do KVM, dlatego należy zestawić ten test z testem odczytu i zapisu na /dev/kvm opisanym wcześniej. Łączne wykonanie obu testów pozwala odróżnić problem z hostingiem od problemu z pakietem, co pozwala uniknąć debugowania instalatora, który od początku działał poprawnie.

Jakich zasobów serwera wymagają mikro-VM?

Każda mikro-VM zawiera rzeczywiste jądro systemu gościa oraz przypisaną pamięć RAM, która jest zarezerwowana przez cały czas działania maszyny. Rozmiar hosta należy zatem dobrać na podstawie wymagań gości oraz ich planowanej liczby. Poniższe wartości są wyliczeniami arytmetycznymi, a nie wynikami pomiarów. Gość bez interfejsu graficznego wymaga 1 GB RAM, natomiast gość z pulpitem i przeglądarką potrzebuje 2 GB. Host rezerwuje stałe 2 GB pamięci na własne potrzeby, działanie demona oraz budowanie obrazów.

[
  {
    "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
  }
]

Jedna maszyna bez interfejsu graficznego wymaga około 3 GB, co mieści się w możliwościach średniej wielkości VPS z dostępem do KVM. Cztery takie maszyny wymagają 6 GB. Uruchomienie 8 maszyn z pulpitem, zgodnie z tą samą arytmetyką, wymaga 18 GB, nie wliczając przy tym ani jednego gigabajta przestrzeni dyskowej.

Przestrzeń dyskowa to parametr, którego często nie bierze się pod uwagę. Host przechowuje jądro gościa, bazowy system plików root, jeden obraz dla każdego typu gościa oraz migawkę dla każdej uruchomionej maszyny. Obraz pulpitu z przeglądarką jest największy. Plik README nie podaje konkretnych wartości, dlatego należy monitorować df -h / podczas pierwszego budowania, zamiast polegać na szacunkach.

Dlatego uczciwa odpowiedź na pytanie „jaki VPS obsłuży Firecracker” często brzmi: „maszyna innej klasy”. Serwer dedykowany udostępnia flagi procesora bez pośrednictwa hypervisora, co stanowi główny punkt rozważań w wyborze między VPS a serwerem dedykowanym. Niektórzy dostawcy udostępniają wirtualizację zagnieżdżoną w planach wirtualnych, a artykuł wirtualizacja zagnieżdżona na VPS wyjaśnia, jak to zweryfikować przed dokonaniem płatności. Jeśli sprzęt jest własnością użytkownika, Proxmox kontra zwykły VPS to to samo pytanie zadane z perspektywy hypervisora.

Serwer to również ta tańsza część kosztów. Każda maszyna udostępniona agentowi zużywa tokeny modelu przez cały czas działania, więc bezczynna mikro-VM kosztuje pamięć, a aktywna – pamięć oraz środki na API. Plan 1 GB nie wystarczy do uruchomienia hosta. Plan, który obsłuży hosta, nadal nie pokryje kosztów klucza.

FAQ

Jak sprawdzić, czy mój VPS może uruchomić Firecracker?

Uruchom ls -l /dev/kvm, systemd-detect-virt oraz grep -cE '\b(vmx|svm)\b' /proc/cpuinfo na VPS. Węzeł urządzenia należący do grupy kvm wraz z liczbą flag większą od zera oznacza, że Firecracker może działać. Brak węzła przy liczbie 0 oznacza, że hypervisor nie przekazuje wirtualizacji, co potwierdza sudo kvm-ok z pakietu cpu-checker za pomocą KVM acceleration can NOT be used. Na architekturze arm64 zignoruj tę liczbę, ponieważ vmx i svm to nazwy specyficzne dla x86.

Czy mogę włączyć zagnieżdżoną wirtualizację z poziomu mojego VPS?

Nie. Zagnieżdżona wirtualizacja jest włączana przez hosta w module jądra hypervisora i dociera do systemu jako flaga procesora na wirtualnym CPU. Wewnątrz gościa sudo modprobe kvm_intel zwraca modprobe: ERROR: could not insert 'kvm_intel': Operation not supported, ponieważ wirtualny procesor nie posiada dostępnego VMX. Dostępne opcje to wybór dostawcy oferującego zagnieżdżoną wirtualizację w planie lub maszyna, na której użytkownik posiada uprawnienia hypervisora.

Czy kontener wystarczy do odizolowania agenta programistycznego?

Często tak. Kontener współdzieli jądro systemu, więc ucieczka na poziomie jądra pozwala na dostęp do hosta, jednak jednorazowy kontener na maszynie bez cennych poświadczeń eliminuje większość realnego ryzyka. Wybierz microVM, gdy agent działa bez nadzoru przez długi czas na niezweryfikowanym kodzie oraz gdy możesz zapewnić mu hosta z /dev/kvm. Jeśli nie jest to możliwe, kontener niszczony po każdym zadaniu jest lepszym rozwiązaniem niż microVM, którego nie udaje się uruchomić.

Ile pamięci RAM potrzebuje host dla agenta microVM?

Zacznij od rozmiaru gościa. Jeden gość bez interfejsu graficznego z 1 GB RAM i rezerwą 2 GB dla hosta wymaga łącznie około 3 GB, a 8 gości z interfejsem graficznym po 2 GB każdy wymaga około 18 GB. Pamięć dyskowa jest oddzielna i łatwo ją niedoszacować, ponieważ host przechowuje jądro, systemy plików root, jeden obraz dla każdego typu gościa oraz migawkę dla każdej uruchomionej maszyny.