Smol machines – Portable virtuelle Maschinen mit Cold Starts unter 1 Sekunde

• smolvm ist ein CLI-basiertes Tool zur Verwaltung virtueller Maschinen, das Software in isolierten Umgebungen auf macOS und Linux ausführt
• Unterstützt Cold Starts im Subsekundenbereich (unter 1 Sekunde), elastisches Speichermanagement und Portabilität als einzelne Datei, wodurch sich VMs schnell und leichtgewichtig ausführen lassen
• VMs laufen als MicroVMs auf Basis des Linux-Kernels und können als .smolmachine-Datei paketiert werden, um ohne Abhängigkeiten erneut ausgeführt zu werden
• Bietet integrierte Unterstützung für Entwicklungs- und Sicherheitsumgebungen durch Isolation an der Hypervisor-Grenze, SSH-Agent-Forwarding und Umgebungsdeklaration auf Basis von Smolfile
• Unterstützt das Booten von OCI-Images ohne Docker-Daemon und präsentiert mit Bootzeiten unter 200 ms und Isolation auf Hardware-Ebene eine leichtgewichtige Virtualisierungsalternative

---

Überblick

• smolvm ist ein CLI-basiertes Tool zur Verwaltung virtueller Maschinen, um Software in isolierten Umgebungen auszuführen
• Es läuft auf macOS und Linux und unterstützt Cold Starts im Subsekundenbereich, elastische Speichernutzung und portable Paketierung in einer einzelnen Datei
• Jede Workload läuft als MicroVM auf Basis des Linux-Kernels und bietet Isolation auf Hardware-Ebene
• Als .smolmachine-Datei paketierte VMs können auf Plattformen mit derselben Architektur ohne Abhängigkeiten erneut ausgeführt werden

Hauptfunktionen

• Lokale virtuelle Maschinen verwalten und ausführen

  • Ausführen angepasster Linux-VMs mit dem Befehl smolvm machine run
  • Cold Start in unter 1 Sekunde, Unterstützung für macOS und Linux
  • Der Speicher wird über virtio balloon elastisch verwaltet, sodass dem Host nur die tatsächlich genutzte Menge zugewiesen wird

• Portable Paketierung als einzelne Datei

  • Kann in einer .smolmachine-Datei inklusive VM-Zustand gebündelt und auf anderen Plattformen wiederhergestellt werden
  • Alle Abhängigkeiten sind eingebettet, sodass eine sofortige Ausführung ohne Installation möglich ist; die Bootzeit liegt bei unter 200 ms

• Sandbox für nicht vertrauenswürdigen Code

  • Trennt Host-Dateisystem, Netzwerk und Zugangsdaten vollständig über die Hypervisor-Grenze
  • Netzwerk ist standardmäßig deaktiviert; mit der Option --allow-host können nur bestimmte Hosts erlaubt werden

• Persistente VMs für die Entwicklung

  • Erstellen und verwalten von VMs mit den Befehlen machine create, start, stop
  • Installierte Pakete bleiben auch nach einem Neustart erhalten und können als Entwicklungsumgebung genutzt werden

• SSH-Agent-Forwarding

  • Leitet den SSH-Agent des Hosts in die VM weiter, ohne dass private Schlüssel in den Gast kopiert werden
  • Mit der Option --ssh-agent lässt sich die SSH-Authentifizierung des Hosts sicher nutzen

• Umgebungsdeklaration auf Basis von Smolfile

  • VM-Konfiguration wird in einem Smolfile im TOML-Format deklarativ beschrieben
  • Images, Netzwerk, Initialisierungsbefehle, Volumes und Authentifizierungsoptionen lassen sich festlegen, um reproduzierbare Umgebungen zu erstellen

Anwendungsbeispiele

• Temporäre VM ausführen

  • smolvm machine run --net --image alpine -- sh -c "echo 'Hello world'"
  • Einmalige Ausführung, bei der die VM beim Beenden automatisch bereinigt wird

• Paketierte ausführbare Datei erzeugen

  • smolvm pack create --image python:3.12-alpine -o ./python312
  • Mit der erzeugten ausführbaren Datei lässt sich eine eigenständige Python-Umgebung ausführen

• Netzwerkkontrolle

  • Netzwerk ist standardmäßig deaktiviert
  • Mit der Option --allow-host kann der Zugriff nur auf bestimmte Domains erlaubt werden

• SSH und Git verwenden

  • smolvm machine run --ssh-agent --net --image alpine
  • Sicherer Zugriff auf Git-Repositories mit den SSH-Schlüsseln des Hosts

Interne Struktur und Funktionsweise

• Jede Workload führt einen eigenständigen Kernel auf Hypervisor.framework (macOS) oder KVM (Linux) aus
• Verwendet eine auf libkrun basierende VMM und einen angepassten Kernel (libkrunfw)
• Unterstützt das OCI-Image-Format, sodass Images direkt von Docker Hub, ghcr.io usw. geladen und ausgeführt werden können
• Kein Docker-Daemon erforderlich, Standard-OCI-Images können direkt gebootet werden
• Die Standardkonfiguration ist 4 vCPU, 8 GiB RAM; Anpassung über die Optionen --cpus, --mem möglich
• vCPU-Threads werden im Leerlauf vom Hypervisor automatisch in den Schlafmodus versetzt, sodass kaum Kosten durch Überbelegung entstehen

Vergleich

Kategorie	smolvm	Containers	Colima	QEMU	Firecracker	Kata
Isolationsniveau	VM pro Workload	Namespaces (geteilter Kernel)	Namespaces (eine einzelne VM)	Einzelne VM	Einzelne VM	VM pro Container
Bootzeit	<200ms	ca. 100ms	mehrere Sekunden	15~30 Sekunden	<125ms	ca. 500ms
Architektur	Bibliothek (libkrun)	Daemon	Daemon in VM	Prozess	Prozess	Runtime-Stack
VM pro Workload	Unterstützt	Nicht unterstützt	Geteilt	Unterstützt	Unterstützt	Unterstützt
macOS-nativ	Unterstützt	über Docker-VM	auf Basis von krunkit	Unterstützt	Nicht unterstützt	Nicht unterstützt
SDK integriert	Unterstützt	Nicht unterstützt	Nicht unterstützt	Nicht unterstützt	Nicht unterstützt	Nicht unterstützt
Portable Artefakte	.smolmachine	Image mit Daemon erforderlich	Nicht unterstützt	Nicht unterstützt	Nicht unterstützt	Nicht unterstützt

Plattformunterstützung

Host	Gast	Anforderungen
macOS Apple Silicon	arm64 Linux	macOS 11 oder höher
macOS Intel	x86_64 Linux	macOS 11 oder höher (nicht vollständig getestet)
Linux x86_64	x86_64 Linux	KVM(/dev/kvm) erforderlich
Linux aarch64	aarch64 Linux	KVM(/dev/kvm) erforderlich

Bekannte Einschränkungen

• Netzwerk ist standardmäßig deaktiviert und kann nur mit der Option --net aktiviert werden
• Unterstützt nur TCP/UDP, kein ICMP
• Volume-Mounts sind nur auf Verzeichnisebene möglich, einzelne Dateien werden nicht unterstützt
• Unter macOS können nur mit Hypervisor.framework-Berechtigung signierte Binärdateien ausgeführt werden
• Bei Verwendung von --ssh-agent muss auf dem Host ein SSH-Agent laufen (SSH_AUTH_SOCK muss gesetzt sein)

Entwicklung

• Entwicklungsrichtlinien sind in docs/DEVELOPMENT.md zu finden
• Veröffentlicht unter der Apache-2.0-Lizenz und erstellt von @binsquare

[GN⁺]

Hacker-News-Kommentare

• Ich arbeite an einer virtuellen Maschine als Ersatz für Docker-Container
  Dabei möchte ich die Ergonomie von Containern beibehalten und gleichzeitig Startzeiten von unter 1 Sekunde erreichen
  Bei meiner Arbeit an Firecracker bei AWS wurde mir klar, dass Container eine unnötige Schicht sind, und Firecracker war eine Technologie, die auf die interne AWS-Architektur zugeschnitten wurde
  Deshalb habe ich selbst eine Hybridform entwickelt, die die Vorteile von Containern mit denen von Firecracker verbindet
  Ich würde gern Meinungen dazu hören

  • Das ist wirklich großartig. Ich habe ebenfalls an einer AI-Sandboxing-Lösung geforscht und dabei mit der Kombination aus Lima+Incus Locki gebaut
    Bei microVMs war für mich meist das Problem, dass Docker oder Kubernetes darauf normalerweise nicht laufen
    Ich würde gern einen kompletten Kubernetes-Cluster in eine Sandbox packen. Mich würde interessieren, ob auch die Ausführung von k3s unterstützt wird
  • Mich würde interessieren, wie der Stand beim Support für Live-Migration ist
    In ähnlichen Systemen fehlt diese Funktion fast immer, aber es gibt weiterhin viele Umgebungen, in denen so etwas zusätzlich zu Cloud-Native-Workloads nötig ist
    Falls ihr das einbaut, wäre das aus meiner Sicht ein echtes Unterscheidungsmerkmal
  • Mich würde interessieren, welcher Anteil des Codes mit LLM/AI geschrieben wurde
  • Ich habe auch etwas Ähnliches gebaut — es heißt shuru.run
    Weil Firecracker nicht auf macOS läuft, wollte ich einfach eine microVM-Sandbox für AI-Apps erstellen können
    Aus Sicht normaler Nutzer ist Firecracker zu schwergewichtig
  • Mich würde interessieren, was die schwierigste Design-Herausforderung war, um Bootzeiten von unter 1 Sekunde zu erreichen
    Und ich würde auch gern wissen, wo aktuell die Engpässe liegen, wenn man diese Zeit noch weiter senken will

• Dieses Projekt klingt ähnlich wie verschiedene Unikernel-Implementierungen — zum Beispiel Unikraft

  • Ich kenne die Innereien von Unikraft nicht genau, weil sie nicht Open Source sind
    Aber Smol Machines ist keine Unikernel-Implementierung, sondern eine verschlankte Version des Linux-Kernels
    Daher ist die Kompatibilität mit der meisten Software hoch

• Die Funktion zur Erzeugung selbstenthaltener Binärdateien wirkt wie eine Möglichkeit, JVM-Apps einfacher zu paketieren als mit GraalVM Native
  Beispielbefehl:
  smolvm pack create --image python:3.12-alpine -o ./python312
./python312 run -- python3 --version
  → Python 3.12.x läuft vollständig isoliert, ohne pyenv/venv/conda

  • Das ist konzeptionell ähnlich wie Electron
    So wie Electron Web-Apps zusammen mit einem Browser ausliefert, paketiert Smol Machines Software zusammen mit einer Linux-VM
    Dadurch lassen sich Probleme mit Abhängigkeiten oder Kompatibilität vermeiden
    Persönlich würde ich es begrüßen, wenn auch Tools wie Codex oder Claude Code auf diese Weise ausgeliefert würden
  • Wahrscheinlich hat jeder schon einmal „seine Entwicklungsumgebung kaputtgemacht“
    Das ist das Konzept einer „verteilbaren Maschine“, um genau solche Probleme zu lösen
    Wenn das Setup einmal stimmt, kann man sie sofort mit jedem teilen und ausführen lassen

• Mich würde interessieren, ob .smolmachine-Dateien digitale Signaturen und Self-Attestation unterstützen
  Ich würde gern wissen, ob das ähnlich funktionieren kann wie in der Signatur-/Verifikationsdokumentation von Sylabs

• Mich würde interessieren, ob sich das mit Ideen von zeroboot noch schneller machen ließe

• Die Vergleichstabelle ist wirklich sehr gelungen
  Zuerst dachte ich: „Das ist wohl ähnlich wie Firecracker“, aber nach der Tabelle waren die Unterschiede klar erkennbar
  Sie war leicht zu lesen, und insgesamt ist das sehr beeindruckende Arbeit

  • Danke

• Ich habe in der CLI-Dokumentation die Images alpine und python:3.12-alpine gesehen und frage mich, woher sie kommen
  Werden sie aus etwas wie einer Docker-Registry geholt, sind sie eingebaut oder erstellt man sie direkt mit einem smolfile?
  Mich würde auch interessieren, ob es Ubuntu-Images gibt
  Es wäre schön, wenn Hot-Resize für Arbeitsspeicher/CPU hinzukäme, und ich könnte mir vorstellen, dass man das auch zur Orchestrierung von Backend-Infrastruktur pro Kunde nutzen könnte

• Die meisten Open-Source-Projekte starten ihre Container mit Docker Compose, aber Smol Machines unterstützt Docker innerhalb einer microVM nicht
  Außerdem ist es schade, dass auch verschachtelte VMs wie bei Vagrant nicht unterstützt werden

  • Docker-Support ist geplant. In der nächsten Version wollen wir einen kompatiblen Kernel mit den nötigen Kernel-Flags ausliefern
  • Da Vagrant lokal VMs startet, scheint dafür Nesting nötig zu sein
    Als Alternative schlage ich vor, sie per Trampolin-Ansatz als Schwester-VM der Vagrant-VM auszuführen

• Mich würde interessieren, was der zentrale Grund ist, statt einer Docker-Sandbox Smol Machines zu verwenden — könntest du das kurz erklären?

• Wirklich ein großartiges Ergebnis. Glückwunsch