Kann Ihr VPS Firecracker-MicroVMs ausführen?

Kann Ihr VPS Firecracker-MicroVMs ausführen?

Ihr VPS kann Firecracker-MicroVMs nur ausführen, wenn er Ihnen /dev/kvm bereitstellt. Firecracker ist ein VMM (Virtual Machine Monitor), der auf KVM (Kernel-based Virtual Machine) aufsetzt. KVM ist die Virtualisierungsschicht in Linux und benötigt Virtualisierungsanweisungen des Prozessors. Auf einem VPS stehen diese Anweisungen nur zur Verfügung, wenn der Provider sie an Ihr Gastsystem durchreicht. Bei den meisten Tarifen ist das nicht der Fall.

Die erste Frage lautet daher nicht, welches MicroVM-Tool Sie installieren sollten. Entscheidend ist, ob die von Ihnen bereits bezahlte Maschine überhaupt eine solche MicroVM hosten kann. Das ist eine Frage des Hostings. Sie können sie in etwa einer Minute beantworten.

Prüfen Sie /dev/kvm, bevor Sie etwas installieren

Führen Sie diese drei Befehle direkt auf dem VPS aus.

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

Ein System, das microVMs hosten kann, antwortet wie folgt:

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

Die erste Zeile zeigt den KVM-Geräteknoten, der der Gruppe kvm gehört. Die zweite Zeile zeigt, dass diese Maschine selbst als Gast unter KVM läuft. Das ist auf einem VPS normal und erwartet. Die dritte Zeile zählt die CPU-Kerne, die das Hardwarevirtualisierungs-Flag melden: vmx bei Intel und svm bei AMD. Ein Wert größer als null innerhalb eines Gasts bedeutet, dass der Hypervisor Ihnen verschachtelte Virtualisierung bereitstellt.

Prüfen Sie anschließend, ob Ihr Benutzer das Gerät öffnen kann. Dies ist der Test aus der Firecracker-eigenen Anleitung für die ersten Schritte:

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

FAIL, obwohl der Geräteknoten vorhanden ist, weist auf ein Berechtigungsproblem und nicht auf ein Hardwareproblem hin. Gewähren Sie Ihrem Benutzer mit sudo setfacl -m u:${USER}:rw /dev/kvm Zugriff oder fügen Sie sich mit sudo usermod -aG kvm ${USER} der Gruppe hinzu. Melden Sie sich danach erneut an.

Ubuntu enthält außerdem eine Prüfung, die all dies in zwei Ausgabezeilen zusammenfasst:

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

Ein funktionierender Host gibt zuerst INFO: /dev/kvm exists und anschließend KVM acceleration can be used aus. Ein Host, der nicht funktioniert, gibt zuerst INFO: Your CPU does not support KVM extensions und anschließend KVM acceleration can NOT be used aus. Auf einer physischen Maschine sehen Sie möglicherweise stattdessen INFO: KVM (vmx) is disabled by your BIOS. Das lässt sich in der Firmware beheben. Auf einem VPS ist diese Meldung selten, weil Sie keine echte Firmware prüfen.

Was bedeutet die jeweilige Antwort zu /dev/kvm?

Der Node ist vorhanden und die Anzahl der Flags ist größer als 0. Sie verfügen über Hardwarevirtualisierung, daher wird Firecracker ausgeführt. Fahren Sie mit dem Abschnitt zur Dimensionierung fort. Ihre verbleibende Einschränkung ist der Arbeitsspeicher, nicht die CPU-Unterstützung.

Kein Node, systemd-detect-virt gibt kvm oder qemu aus, und die Anzahl der Flags ist 0. Ihre VPS ist eine virtuelle Maschine, deren Host die Virtualisierung nicht durchreicht. Nichts, was Sie innerhalb des Gasts installieren, ändert daran etwas. Das Flag ist eine Eigenschaft der virtuellen CPU, die der Hypervisor für Sie erstellt hat. sudo modprobe kvm_intel schlägt mit modprobe: ERROR: could not insert 'kvm_intel': Operation not supported fehl, und sudo dmesg | grep -i kvm protokolliert die fehlende Hardwareunterstützung. Dies ist der häufigste Fall bei gemeinsam genutzten VPS-Tarifen. Fragen Sie den Anbieter, ob der Tarif verschachtelte Virtualisierung unterstützt. Wenn die Antwort Nein lautet, benötigen Sie ein anderes Hosting, nicht einen anderen Befehl.

systemd-detect-virt gibt lxc, lxc-libvirt oder openvz aus. Ihr Tarif verwendet Container-Virtualisierung, daher teilen Sie den Kernel des Hosts. /dev/kvm wird niemals erscheinen, weil Sie keinen eigenen Kernel haben, in den Sie ein Modul laden könnten. Auch ein Paket kann dieses Problem nicht beheben.

Die Flags sind vorhanden, der Node jedoch nicht. Das Modul ist lediglich nicht geladen. Führen Sie sudo modprobe kvm_intel aus (oder unter AMD kvm_amd) und prüfen Sie ls -l /dev/kvm erneut. Wenn der Node erscheint, tragen Sie den Modulnamen in /etc/modules-load.d/kvm.conf ein, damit das Modul nach einem Reboot erneut geladen wird.

Sie verwenden arm64. vmx und svm sind x86-Bezeichnungen. Daher ist die Anzahl von grep auf jedem arm64-Rechner 0, unabhängig davon, ob er funktioniert oder nicht. Verwenden Sie unter arm64 stattdessen den Device-Node sowie den Lese- und Schreibtest als Prüfkriterien.

Warum eine microVM und kein Container für Agentenarbeit

Ein Container ist ein Prozess auf Ihrem Kernel, der durch Namespaces und cgroups abgeschottet wird. Es gibt nur einen Kernel, und dieser gehört Ihnen. Ein Escape auf Kernel-Ebene führt daher auf den Host. Eine microVM startet innerhalb einer Hardwarevirtualisierungsgrenze einen eigenen Kernel und kommuniziert mit einem kleinen emulierten Gerätemodell statt mit der vollständigen Systemaufrufschnittstelle Ihres Hosts. Firecracker hält dieses Modell bewusst klein. Genau das ist das Design: Weniger emulierte Geräte bedeuten weniger mögliche Ausbruchspfade.

Dieser Unterschied ist bei einem Coding-Agenten wichtig, weil niemand den Code, den ein Agent ausführt, vorher geprüft hat. Der Agent installiert Pakete, führt Build-Skripte aus und wiederholt Aktionen mit Maschinengeschwindigkeit, wenn etwas fehlschlägt. Ein separater Kernel bedeutet, dass ein fehlerhafter Schritt eine Maschine beschädigt, die Sie löschen können, und sonst nichts.

Die Anforderung ergibt sich direkt aus dem Mechanismus. Hardwareisolierung benötigt Hardwarevirtualisierung. Genau diese Funktion bietet Ihr VPS-Tarif möglicherweise nicht. Ein Container benötigt sie nicht. Deshalb laufen Container auf jedem jemals angebotenen Tarif.

Wenn /dev/kvm also fehlt, bleibt der containerbasierte wegwerfbare VM für Coding-Agenten die richtige Lösung. Sie ist eine echte Sicherheitsmaßnahme und kein Ersatz aus der Not. Ein Wegwerfcontainer auf einem Host, der keine für Sie wichtigen Zugangsdaten enthält und bei Fehlverhalten aus einem Snapshot wiederhergestellt wird, verhindert den Großteil der tatsächlich auftretenden Probleme. Dasselbe gilt für die einfachere Konfiguration unter einen Coding-Agenten auf einem VPS ausführen. Verwenden Sie eine microVM, wenn ein Agent unbeaufsichtigt über Stunden hinweg Code ausführt, den Sie noch nicht geprüft haben, und wenn der Host Ihnen zur Verfügung steht.

Was ein microVM-Agent-Host benötigt

Nehemiah ist ein aktuelles Beispiel für diese Klasse: ein Apache-2.0-Daemon, der einer KI bei Bedarf eine echte Linux-Maschine bereitstellt, mit einer Firecracker-microVM pro Maschine. Am 10 August 2026 formulierte die README die Anforderung eindeutig: „a Linux box with /dev/kvm“, genauer „Ubuntu 24.04, x86_64 or arm64, with /dev/kvm (bare-metal, or a VM with nested virtualization) that you can root-SSH into“.

Das hat sich inzwischen geändert. Am 11 August 2026 ersetzte das Projekt seine Self-Service-Einrichtungsdokumentation durch ein Runbook für verwaltete Hosts. Die am 11 October 2026 geprüfte README enthält diese Anforderung und die Installation mit einem Befehl nicht mehr. Hosts werden jetzt aus signierten Release-Artefakten auf Bare-Metal-Servern von Latitude.sh mit infra/latitude/provision.sh bereitgestellt. Dieser manuelle, von einem Operator ausgeführte Ablauf gilt für freigegebene Hosts, die anschließend von der Control Plane des Projekts registriert werden. Der Canary des Runbooks lehnt einen Host ohne nutzbares /dev/kvm weiterhin ab. Die Anforderung ist also nicht entfallen. Sie wurde auf Bare Metal verlagert.

Bis zu dieser Änderung bestand die dokumentierte Einrichtung aus einem Befehl, der auf diese Maschine zielte:

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

Unter dem aktuellen main installiert dieser Befehl nichts mehr. infra/setup.sh ist als nicht mehr im Umfang enthalten gekennzeichnet und beendet sich bereits im ersten Schritt mit dem Hinweis, dass der Self-Service-Bootstrap nicht mehr unterstützt wird. Es wird kein Preflight- oder Installationsschritt ausgeführt. Die README weist darauf hin, dass die früheren Self-Service-Installer nun mit einem Verweis auf das Runbook für verwaltete Hosts beendet werden.

Beim Commit, auf den sich dieser Beitrag ursprünglich bezog, führte infra/setup.sh einen Preflight-Test über SSH aus und brach frühzeitig ab, wenn der Host nicht geeignet war. Die beiden Hardware-Ablehnungen lauteten:

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

Die erste Meldung ist der Kern dieses Beitrags. Der Installer stellte mit ls -l /dev/kvm genau die Frage, die Sie gerade gestellt haben. Auf den meisten VPS-Tarifen erhielt er dieselbe enttäuschende Antwort. Auch das Runbook für verwaltete Hosts stellt diese Frage.

Nach dem Preflight installierte der Ablauf die vollständige Umgebung: Firecracker und dessen jailer, eine Go-Toolchain, einen Gastkernel und ein Root-Dateisystem, ein Python-Gast-Image, ein optionales Desktop-Image mit Browser sowie zwei systemd-Units namens nehemiahd.service und boring-net.service. Bei einem fehlgeschlagenen Health Check wurde /healthz didn't return ok ausgegeben. Mit SKIP_DESKTOP=1 wurde das Desktop-Image übersprungen, für dessen Erstellung die README an diesem Datum ungefähr 8 Minuten veranschlagte. Keiner dieser Schritte, Meldungen oder Schalter wird mit dem aktuellen main ausgeführt. Der Daemon lauscht standardmäßig weiterhin auf Port 8080.

Lesen Sie die Einschränkungen, bevor Sie diesen Befehl einfügen

Der Installer benötigte SSH-Zugriff als root auf einem frisch eingerichteten Host. Der Self-Service-Installer schrieb Systempakete, systemd-Units und die Netzwerkkonfiguration als root. Wenn Sie diesen nicht unterstützten Commit trotzdem ausführen, verwenden Sie dafür eine Maschine, die Sie bei Bedarf vollständig neu aufsetzen können. Verwenden Sie nicht den Server, auf dem Ihre Website bereits läuft.

Der Daemon bindet standardmäßig an 0.0.0.0:8080. Jeder, der diesen Port erreicht, kann Maschinen erstellen. Diese Maschinen verwenden den Model-Key, den Sie dem Host übergeben haben. Setzen Sie NEHEMIAH_TOKEN, um eine Authentifizierung zu verlangen. Alternativ setzen Sie NEHEMIAH_ADDR=127.0.0.1:8080 (der Daemon akzeptiert auch -addr 127.0.0.1:8080), damit er nur an 127.0.0.1 bindet. Greifen Sie dann über einen Tunnel mit ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP darauf zu. Der Schalter BIND_LOCALHOST=1 des alten Installers wird vom Daemon nicht gelesen und hat außerhalb dieses Scripts keine Wirkung. Behandeln Sie den Key genauso sorgfältig wie jedes andere Secret auf dem System, wie unter Secrets aus AI-Agents heraushalten beschrieben.

Jede Maschine ist ein Computer mit Internetzugriff und vorinstallierten Agents. Die README nennt claude, codex, cursor und pi innerhalb des Gasts, zusätzlich zu node, python und git. Das Projekt gibt an, dass die Gäste hinter einer Egress-Firewall liegen und dass die Isolationsgrenze tatsächlich wirksam ist. Der Gast erreicht das Netzwerk trotzdem absichtlich, weil ein Coding-Agent, der kein Paket herunterladen kann, unbrauchbar ist. Planen Sie damit, statt von einer Air-Gap-Umgebung auszugehen.

Es gibt kein markiertes Release. Am 11. Oktober 2026 hatte das Repository weder Tags noch Releases. Ein Klonen von main liefert daher den Stand, der an diesem Morgen zuletzt eingegangen ist. Das ist derzeit der Code für den Managed-Betrieb. Fixieren Sie einen Commit. Der folgende Commit entspricht dem Stand, gegen den dieser Beitrag am 10. August 2026 geschrieben wurde, also am Tag vor der Einstellung des Self-Service-Installers. Sein infra/setup.sh lässt sich daher noch installieren. Das Projekt unterstützt diesen Pfad nicht mehr. Lesen Sie deshalb das Script, bevor es als root auf Ihrem Server ausgeführt wird:

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

Das Repository wurde Ende Juni 2026 erstellt. Sechs Wochen später wurde die Self-Service-Installation eingestellt. Behandeln Sie die Software daher als junges Projekt, dessen unterstützter Pfad sich kurzfristig ändern kann. Lesen Sie vor dem Abruf eines neueren Stands erneut die README und das Runbook. Sie genehmigen damit Root-Zugriff auf eine Maschine und keine Aktualisierung einer Library-Version.

Beweisen Sie, dass KVM funktioniert, bevor Sie dem Installer die Schuld geben

Wenn die Einrichtung fehlschlägt und Sie wissen möchten, ob KVM die Ursache ist, testen Sie Firecracker separat. Dies sind die Download-Schritte des Upstream-Projekts:

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

Eine ausgegebene Version bestätigt, dass die Binärdatei zu Ihrer Architektur passt und ausgeführt wird. Sie bestätigt jedoch nicht den KVM-Zugriff. Führen Sie daher zusätzlich den Lese- und Schreibtest für /dev/kvm aus dem vorherigen Abschnitt aus. Zusammen trennen die beiden Tests ein Problem mit der Hosting-Umgebung von einem Paketierungsproblem. So vermeiden Sie die Fehlersuche in einem Installer, der von Anfang an korrekt gearbeitet hat.

Wie viel Server benötigen mehrere microVMs?

Jede microVM enthält einen echten Gastkernel sowie den dafür zugewiesenen Arbeitsspeicher. Dieser Arbeitsspeicher bleibt belegt, solange die Maschine läuft. Dimensionieren Sie den Host daher anhand der Größe der Gäste und der Anzahl der Maschinen, die gleichzeitig laufen sollen. Die folgenden Werte sind berechnet und nicht gemessen. Ein Gast ohne grafische Oberfläche erhält 1 GB. Ein Desktop-Gast mit Browser erhält 2 GB. Der Host reserviert zusätzlich pauschal 3 GB für sich selbst, den Daemon und Image-Builds. Das ist die Standardreserve des Daemons (NEHEMIAH_MEM_RESERVE_MB, 3072 MB). Der Daemon startet keine neue Maschine, wenn dadurch diese Reserve unterschritten würde. Ein zu kleiner Host erreicht daher seine Kapazitätsgrenze, statt dass der Arbeitsspeicher ausgeht.

[
  {
    "label": "1 headless guest",
    "guests": 1,
    "guest_ram_gb": 1,
    "host_ram_gb": 4
  },
  {
    "label": "4 headless guests",
    "guests": 4,
    "guest_ram_gb": 1,
    "host_ram_gb": 7
  },
  {
    "label": "4 desktop guests",
    "guests": 4,
    "guest_ram_gb": 2,
    "host_ram_gb": 11
  },
  {
    "label": "8 desktop guests",
    "guests": 8,
    "guest_ram_gb": 2,
    "host_ram_gb": 19
  }
]

Eine einzelne Maschine ohne grafische Oberfläche benötigt ungefähr 4 GB. Das kann ein mittelgroßer VPS verkraften, sofern er KVM bereitstellt. Vier solcher Maschinen benötigen 7 GB. Für 8 Desktop-Maschinen ergibt dieselbe Berechnung 19 GB, noch ohne ein einziges Gigabyte für den Speicherplatz.

Speicherplatz ist der Wert, den niemand einplant. Der Host speichert einen Gastkernel, ein Basis-Root-Dateisystem, ein Image pro Gastvariante und einen Snapshot pro laufender Maschine. Das Desktop-Image mit Browser ist dabei das größte. Die README nennt keinen Wert für den Speicherplatz. Überwachen Sie daher df -h / während des ersten Builds, statt einer Schätzung zu vertrauen.

Deshalb lautet die ehrliche Antwort auf die Frage „Welcher VPS führt Firecracker aus?“ häufig „eine andere Maschinenklasse“. Bare Metal stellt die CPU-Flags bereit, ohne dass ein Hypervisor dazwischenliegt. Das ist der entscheidende Unterschied bei der Wahl zwischen einem VPS und einem dedizierten Server. Einige Anbieter stellen verschachtelte Virtualisierung auf virtuellen Tarifen bereit. Verschachtelte Virtualisierung auf einem VPS beschreibt, wie Sie dies vor dem Kauf überprüfen. Wenn die Hardware bereits Ihnen gehört, stellt Proxmox gegenüber einem einfachen VPS dieselbe Frage aus Sicht des Hypervisors.

Der Server ist außerdem nur die günstigere Hälfte. Jede Maschine, die Sie einem Agenten übergeben, verbraucht so lange Modell-Tokens, wie sie läuft. Eine inaktive microVM kostet daher Arbeitsspeicher, während eine ausgelastete Maschine zusätzlich API-Kosten verursacht. Ein Tarif mit 1 GB kann den Host nicht aufnehmen. Ein Tarif, der den Host aufnehmen könnte, bezahlt trotzdem nicht den Schlüssel.

FAQ

Wie prüfe ich, ob mein VPS Firecracker ausführen kann?

Führen Sie auf dem VPS ls -l /dev/kvm, systemd-detect-virt und grep -cE '\b(vmx|svm)\b' /proc/cpuinfo aus. Ein Device-Knoten im Besitz der Gruppe kvm und eine Flag-Anzahl größer als 0 bedeuten, dass Firecracker ausgeführt werden kann. Fehlt der Knoten und beträgt die Anzahl 0, stellt der Hypervisor keine Virtualisierung durch. sudo kvm-ok aus dem Paket cpu-checker bestätigt dies mit KVM acceleration can NOT be used. Ignorieren Sie auf arm64 die Anzahl, weil vmx und svm x86-Bezeichnungen sind.

Kann ich verschachtelte Virtualisierung innerhalb meines VPS aktivieren?

Nein. Der Host aktiviert die verschachtelte Virtualisierung im Kernelmodul des Hypervisors. Sie wird Ihnen als CPU-Flag auf dem zugewiesenen virtuellen Prozessor bereitgestellt. Innerhalb des Gasts gibt sudo modprobe kvm_intel modprobe: ERROR: could not insert 'kvm_intel': Operation not supported zurück, weil die virtuelle CPU kein VMX verwenden kann. Ihre Optionen sind ein Anbieter, der verschachtelte Virtualisierung im Tarif anbietet, oder eine Maschine, auf der Sie den Hypervisor selbst betreiben.

Reicht ein Container aus, um einen Coding-Agenten zu sandboxen?

Oft ja. Ein Container verwendet denselben Kernel wie der Host. Ein Kernel-Level-Escape erreicht daher den Host. Ein kurzlebiger Container auf einer Maschine ohne wertvolle Zugangsdaten beseitigt jedoch den größten Teil des tatsächlich bestehenden Risikos. Verwenden Sie eine MicroVM, wenn ein Agent über längere Zeit unbeaufsichtigt mit nicht geprüften Code arbeitet und Sie ihm einen Host mit /dev/kvm bereitstellen können. Wenn das nicht möglich ist, ist ein Container, den Sie nach jeder Aufgabe löschen, besser als eine MicroVM, deren Start Sie nie verwalten.

Wie viel RAM benötigt ein Host für MicroVM-Agenten?

Gehen Sie von der Größe der Gastsysteme aus. Ein headless Gast mit 1 GB und einer Host-Reserve von 3 GB benötigt insgesamt etwa 4 GB. 8 Desktop-Gäste mit jeweils 2 GB benötigen etwa 19 GB. Der Speicherplatz muss separat betrachtet werden und wird leicht unterschätzt, weil der Host einen Kernel, Root-Dateisysteme, ein Image pro Gastvariante und einen Snapshot für jede laufende Maschine vorhält.