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, eine Firecracker-MicroVM pro Maschine. Die README formuliert die Voraussetzung eindeutig: „eine Linux-Box mit /dev/kvm“, genauer „Ubuntu 24.04, x86_64 oder arm64, mit /dev/kvm (Bare Metal oder eine VM mit verschachtelter Virtualisierung), auf die Sie sich per root-SSH verbinden können“.

Die dokumentierte Einrichtung besteht aus einem Befehl, der auf dieser Box ausgeführt wird:

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 führt über SSH eine Vorabprüfung durch und bricht frühzeitig ab, wenn die Box die Voraussetzungen nicht erfüllt. Die beiden Hardware-Ablehnungen lauten:

/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. Das Installationsprogramm stellt dieselbe Frage, die Sie gerade mit ls -l /dev/kvm gestellt haben, und erhält bei den meisten VPS-Tarifen dieselbe enttäuschende Antwort.

Nach der Vorabprüfung wird die gesamte Box installiert: Firecracker und sein jailer, eine Go-Toolchain, ein 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. Der Daemon nimmt anschließend Verbindungen auf Port 8080 an. Bei einer fehlgeschlagenen Health-Prüfung wird /healthz didn't return ok ausgegeben. SKIP_DESKTOP=1 überspringt das Desktop-Image, dessen Erstellung laut README ungefähr 8 Minuten dauert.

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

Der Installer benötigt SSH-Zugriff als root auf einem neuen Host. Der Installer schreibt Systempakete, systemd-Units und die Netzwerkkonfiguration als root. Verwenden Sie dafür eine Maschine, die Sie vollständig neu aufsetzen können, 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 Modellschlüssel, den Sie dem Installer übergeben haben. Setzen Sie NEHEMIAH_TOKEN, um eine Authentifizierung zu verlangen. Alternativ setzen Sie BIND_LOCALHOST=1, damit der Daemon nur an 127.0.0.1 bindet und Sie ihn über einen Tunnel mit ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP erreichen. Behandeln Sie den Schlüssel genauso sorgfältig wie jedes andere Geheimnis auf dem System, wie unter Geheimnisse von KI-Agenten fernhalten beschrieben.

Jede Maschine ist ein Computer mit Internetzugriff und vorinstallierten Agenten. Die README führt claude, codex, cursor und pi innerhalb des Gasts neben node, python und git auf. Laut Projekt befinden sich die Gäste hinter einer Firewall für ausgehenden Datenverkehr. Auch die Isolationsgrenze selbst ist tatsächlich vorhanden. Der Gast kann das Netzwerk dennoch absichtlich erreichen, denn ein Coding-Agent, der kein Paket abrufen kann, ist nutzlos. Berücksichtigen Sie das bei der Planung, statt von einer vollständigen Netzwerktrennung auszugehen.

Es gibt kein getaggtes Release. Am 10. August 2026 hatte das Repository überhaupt keine Tags. Ein Klonen von main liefert daher den Stand, der an diesem Morgen zuletzt eingespielt wurde. Fixieren Sie einen Commit und lesen Sie das Skript, 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. Behandeln Sie die Software daher als junges Projekt. Lesen Sie infra/setup.sh nach jedem Update, das Sie abrufen, erneut durch. Sie genehmigen damit Root-Zugriff auf eine Maschine und nicht lediglich die Aktualisierung einer Bibliotheksversion.

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 Serverleistung benötigen mehrere microVMs?

Jede microVM enthält einen echten Gastkernel sowie den ihr zugewiesenen Arbeitsspeicher. Dieser Speicher bleibt belegt, solange die Maschine läuft. Dimensionieren Sie den Host daher anhand der Größe der Gäste und der Anzahl der Gäste, die gleichzeitig laufen sollen. Die folgenden Werte sind Berechnungen und keine Messwerte. Ein Gast ohne grafische Oberfläche erhält 1 GB. Ein Desktop-Gast mit Browser erhält 2 GB. Für sich selbst, den Daemon und Image-Builds reserviert der Host pauschal 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
  }
]

Eine einzelne Maschine ohne grafische Oberfläche benötigt etwa 3 GB. Das passt auf einen mittelgroßen VPS, sofern dieser KVM bereitstellt. Vier solcher Maschinen benötigen 6 GB. Für 8 Desktop-Maschinen ergibt dieselbe Berechnung 18 GB, noch ohne ein einziges Gigabyte für den Datenträger.

Der Datenträgerbedarf wird am häufigsten unterschätzt. 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 Speicherbedarf. Ü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 dazwischengeschaltet ist. Das ist der entscheidende Unterschied beim Vergleich von VPS und dediziertem Server. Einige Anbieter stellen verschachtelte Virtualisierung auf virtuellen Tarifen bereit. Verschachtelte Virtualisierung auf einem VPS beschreibt, wie Sie dies vor dem Bezahlen überprüfen. Wenn die Hardware bereits Ihnen gehört, stellt Proxmox im Vergleich zu einem einfachen VPS dieselbe Frage aus Sicht des Hypervisors.

Der Server ist außerdem nur die günstige Hälfte. Jede Maschine, die Sie einem Agenten überlassen, verbraucht so lange Modell-Tokens, wie sie läuft. Eine inaktive microVM kostet daher Arbeitsspeicher, während eine ausgelastete microVM 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 sowie eine Anzahl von Flags größer als null bedeuten, dass Firecracker ausgeführt werden kann. Ein fehlender Knoten mit einer Anzahl von 0 bedeutet, dass der Hypervisor keine Virtualisierung durchreicht. 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 eigenen 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 verwalten.

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

Oft ja. Ein Container verwendet denselben Kernel wie der Host. Ein Ausbruch auf Kernel-Ebene erreicht daher den Host. Ein kurzlebiger Container auf einer Maschine, auf der keine wertvollen Zugangsdaten gespeichert sind, beseitigt jedoch den größten Teil des tatsächlichen Risikos. Wählen Sie eine MicroVM, wenn ein Agent über längere Zeit unbeaufsichtigt mit ungeprüftem 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, die Sie nie erfolgreich starten.

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

Gehen Sie von der Größe des Gasts aus. Ein zustandsloser Gast mit 1 GB und einer Host-Reserve von 2 GB benötigt insgesamt etwa 3 GB. 8 Desktop-Gäste mit jeweils 2 GB benötigen etwa 18 GB. Der Speicherplatzbedarf ist davon unabhängig 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.