Firecracker-microVM's in gewone taal: een echte VM die in een fractie van een seconde start

Als je iets hebt gelezen over het veilig uitvoeren van door AI gegenereerde code, ben je het woord microVM tegengekomen, meestal naast Firecracker. Het wordt uitgelegd als „een lichtgewicht VM” (klopt, helpt niet) of met een diagram van kernel-ingewanden. Hier is de versie ertussenin.

Twee oudere opties, en waarom geen van beide past

Begin bij de twee dingen waartussen een microVM zit.

Een container is een groep gewone processen op je machine waar de kernel tegen heeft afgesproken te liegen. Namespaces tonen ze een eigen bestandssysteem, een eigen proceslijst en een eigen netwerk; cgroups begrenzen hoeveel CPU en geheugen ze mogen gebruiken. Hij start in milliseconden omdat er niets nieuws opstart. Maar elke container op een host praat met dezelfde kernel. Een kernelbug die vanuit één container bereikbaar is, is een uitweg uit allemaal.

Een virtuele machine brengt een eigen kernel mee. De CPU van de host voert de gast via hardwarevirtualisatie (KVM op Linux) uit alsof die een eigen computer heeft. De grens is de hypervisor, die veel minder blootstelt dan de honderden systeemaanroepen van een kernel. De prijs is gewicht. Een klassieke VM emuleert een hele pc: firmware, een PCI-bus, USB-controllers, een grafische kaart, soms een geluidskaart. Hij start door dat alles heen, doet daar seconden tot minuten over, en elke instantie sleept tientallen of honderden megabytes overhead mee.

Een analogie die redelijk standhoudt: containers zijn appartementen in één gebouw, met gedeelde fundering, leidingen en bedrading. VM's zijn losse huizen. Huizen zijn veiligere buren, maar voor een bezoek van 20 seconden bouw je er geen.

Wat Firecracker weglaat

Firecracker is een virtual machine monitor (het programma dat een VM bovenop KVM inricht en draait), geschreven in Rust en in 2018 open source gemaakt. Hij is gebouwd voor één taak: enorme aantallen kortstondige werklasten die elkaar niet vertrouwen op gedeelde hardware draaien. Dat lukt vooral door weg te laten:

• Geen firmware, geen hardwaredetectie. De kernel wordt rechtstreeks in het geheugen geladen en gestart. Niemand zoekt naar apparaten die er niet zijn.
• Een piepklein apparaatmodel. Een netwerkkaart, een blokapparaat, een seriële console en nog een paar, allemaal virtio (apparaten ontworpen voor virtuele machines in plaats van imitaties van fysieke). Geen USB, geen graphics, geen PCI.
• Een kleine, geheugenveilige codebase. Minder code die apparaten emuleert, betekent minder plekken voor een bug waarmee de gast de host bereikt.
• Een kooi rond de VMM zelf. Elk Firecracker-proces draait in een chroot, met seccomp-filters op zijn eigen systeemaanroepen en cgroups op zijn resources. Mocht er iets uit de gast breken, dan belandt het in een kooi, niet op de host.

De cijfers die het project zelf publiceert: user space in slechts 125 ms en minder dan 5 MiB geheugenoverhead per microVM. Dat zijn de beste labwaarden; een echte sandbox moet ook schijf en netwerk inrichten en wachten op een agent binnenin die klaar is voor commando's, daarom is de onze in ongeveer een seconde klaar. Dat ligt nog steeds dicht genoeg bij containersnelheid om er per taak één aan te maken en hem daarna weg te gooien.

Container versus microVM in de praktijk

De rij die telt is de tweede. Bij een container wordt de vraag „kan deze code ontsnappen?” de vraag „zit er ergens in de hostkernel een bereikbare bug?”. Bij een microVM wordt het „zit er een bug in de hypervisor of in een handvol virtuele apparaten?”. Het tweede oppervlak is veel kleiner, en het is precies wat cloudplatforms al verdedigen voor hun eigen multi-tenant hosting.

Wat je inlevert

Een microVM is geen gratis upgrade.

• Geen GPU's en geen schermen. Hij is voor het draaien van code, niet voor desktops of graphics.
• Minder apparaten, minder flexibiliteit. Alles wat echte hardware of een lange lijst kernelmodules verwacht, voelt zich er niet thuis.
• Grenzen hebben nog steeds beleid nodig. Een microVM met open uitgaand verkeer kan nog steeds verkeer sturen dat je niet wilt; een met je API-sleutels erin kan ze nog steeds lekken. Isolatie beschermt de host tegen de gast, niet je geheimen tegen de code waaraan je ze gaf.

Hoe onze sandboxes hem gebruiken

Elke EQVPS-sandbox is één Firecracker-microVM met een eigen kernel, van 0.25 vCPU en 512 MB tot 8 vCPU en 16 GB. Hij heeft Python 3.12, Node.js 22, bash, git en curl, uitgaand internet en geen inkomende poorten. Kortstondige sandboxes worden verwijderd als je klaar bent; persistente houden hun schijf, en pauzeren schrijft een snapshot van de microVM naar schijf, zodat hij niets kost tot hij hervat. Gepauzeerde snapshots worden 14 dagen bewaard. Daarna wordt de sandbox verwijderd en antwoordt zijn id met 410 sandbox_deleted.

We kozen voor microVM's in plaats van containers om één reden: de code die in een sandbox draait, is per definitie code die niemand heeft nagekeken. De uitvoer van een AI-agent, de pull request van een onbekende, een benchmark van duizend door een model geschreven programma's. Daarvoor is een eigen kernel de grens die het geld waard is. Wat we eromheen bouwden — tarieven, quota, de limiet van 55 seconden voor synchrone commando's — staat in de sandboxdocumentatie.

Wil je deze grens uitgebreider vergelijken met de andere opties, dan zet isolatieniveaus voor onbetrouwbare code processen, containers, microVM's en volledige VM's naast elkaar. En als de prijs per seconde je aandacht trok, laat hoe facturering per seconde echt werkt de rekensom zien.