Micro-VM avec Firecracker : démarrage en millisecondes

Une micro-VM combine l'isolation matérielle d'une vraie machine virtuelle et la vitesse de démarrage d'un conteneur. Firecracker est le gestionnaire de VM minimaliste qui rend cela possible : conçu par AWS pour Lambda et Fargate, il lance des VM légères sur KVM en quelques dizaines de millisecondes. Ce guide vous montre, pas à pas et sur une vraie machine, comment installer Firecracker, préparer un noyau et un rootfs, démarrer une micro-VM, y exécuter une commande et lui donner un réseau. Public visé : vous connaissez déjà ce qu'est une VM et la différence type 1 / type 2. Exemples testés sur Firecracker v1.16.1 avec un noyau 6.1 et un rootfs Ubuntu 24.04.

Ce que vous allez apprendre

Distinguer micro-VM, conteneur et VM classique.
Installer Firecracker et préparer un noyau et un rootfs.
Démarrer une micro-VM et y exécuter une commande.
Connecter la micro-VM au réseau avec une interface tap.

Micro-VM, conteneur ou VM classique

Un conteneur partage le noyau de l'hôte : il démarre en quelques millisecondes mais son isolation repose entièrement sur les namespaces et cgroups du noyau, une surface d'attaque large. Une VM classique embarque un noyau invité et un firmware complet (BIOS, contrôleurs PCI, périphériques émulés) : isolation forte, mais démarrage en dizaines de secondes et empreinte lourde.

La micro-VM occupe le juste milieu. Elle possède son propre noyau invité isolé par le processeur (via KVM), mais Firecracker lui retire tout le superflu d'une VM traditionnelle : ni BIOS, ni bus PCI, ni périphériques émulés, seulement quelques périphériques virtio essentiels.

Critère	Conteneur	Micro-VM (Firecracker)	VM classique
Frontière d'isolation	Noyau partagé	Noyau invité dédié (KVM)	Noyau invité dédié + firmware complet
Démarrage	Millisecondes	~125 ms (VMM), moins d'1 s pour Linux	Dizaines de secondes
Empreinte mémoire	Minimale	~5 Mio par micro-VM	Centaines de Mio
Surface d'attaque	Large (noyau commun)	Réduite (~50 k lignes, virtio minimal)	Large (émulation complète)
Terrain de jeu	Applications sans état	Multi-tenant, sandbox, serverless	OS complet, systèmes existants

Pourquoi Firecracker démarre en millisecondes

La rapidité de Firecracker tient à son minimalisme assumé. Là où un hyperviseur classique comme QEMU émule une machine complète, Firecracker est un VMM (Virtual Machine Monitor) de quelques dizaines de milliers de lignes de Rust, qui n'expose au noyau invité que le strict nécessaire : un périphérique virtio-net pour le réseau, un virtio-block pour le disque, une console série et un contrôleur d'interruptions. Pas de firmware à initialiser, pas de bus PCI à sonder.

Résultat : le processus de démarrage saute toutes les étapes lentes d'un boot PC traditionnel. Le noyau invité s'exécute quasi immédiatement, ce qui explique les 125 millisecondes annoncées par AWS pour lancer le code invité, et l'empreinte mémoire de l'ordre de 5 Mio par micro-VM. C'est cette combinaison qui permet à AWS de faire tourner des millions de fonctions Lambda isolées les unes des autres.

Prérequis : KVM

Firecracker s'appuie sur KVM, le module de virtualisation du noyau Linux. Il vous faut donc un hôte Linux x86_64 ou aarch64 avec la virtualisation matérielle activée, et un accès en lecture-écriture à /dev/kvm. Vérifiez les deux points :

# La virtualisation CPU est-elle disponible ?
grep -Ec 'vmx|svm' /proc/cpuinfo   # doit être > 0

# Ai-je accès à /dev/kvm ?
ls -l /dev/kvm

Si /dev/kvm appartient au groupe kvm, ajoutez votre utilisateur à ce groupe (sudo usermod -aG kvm $USER, puis reconnectez-vous) pour éviter d'avoir à lancer Firecracker en root.

Installer Firecracker

Firecracker se distribue sous forme d'un binaire statique unique, sans dépendance à installer. Récupérez la dernière version depuis les releases GitHub officielles, pour votre architecture :

arch=$(uname -m)
rel="https://github.com/firecracker-microvm/firecracker/releases"
latest=$(basename $(curl -fsSLI -o /dev/null -w "%{url_effective}" ${rel}/latest))

curl -fsSL ${rel}/download/${latest}/firecracker-${latest}-${arch}.tgz | tar -xz
mv release-${latest}-${arch}/firecracker-${latest}-${arch} firecracker
chmod +x firecracker
./firecracker --version | head -1

Firecracker v1.16.1

Préparer un noyau et un rootfs

Une micro-VM a besoin de deux artefacts : une image noyau non compressée (vmlinux) et un système de fichiers racine (rootfs). L'équipe Firecracker publie des artefacts prêts à l'emploi dans un bucket d'intégration continue. Récupérez un noyau 6.1 et un rootfs Ubuntu 24.04 :

base="https://s3.amazonaws.com/spec.ccfc.min/firecracker-ci/v1.15/x86_64"
curl -fsSL "${base}/vmlinux-6.1.155" -o vmlinux.bin
curl -fsSL "${base}/ubuntu-24.04.squashfs" -o rootfs.squashfs

Le rootfs fourni est un squashfs en lecture seule. Pour que la micro-VM puisse y écrire, convertissez-le en image ext4. L'option -d de mkfs.ext4 recopie un répertoire dans l'image sans montage ni privilèges root :

unsquashfs -d rootfs-dir rootfs.squashfs
mkfs.ext4 -d rootfs-dir rootfs.ext4 1200M

Lancer sa première micro-VM

Firecracker se configure entièrement par un fichier JSON ou via son API sur socket Unix. Pour un premier essai reproductible, le fichier de configuration est le plus simple. Il décrit trois choses : la source de démarrage (noyau et paramètres), le disque racine, et le gabarit machine (vCPU et mémoire).

{
  "boot-source": {
    "kernel_image_path": "vmlinux.bin",
    "boot_args": "console=ttyS0 reboot=k panic=1 pci=off"
  },
  "drives": [{
    "drive_id": "rootfs",
    "path_on_host": "rootfs.ext4",
    "is_root_device": true,
    "is_read_only": false
  }],
  "machine-config": {
    "vcpu_count": 2,
    "mem_size_mib": 1024
  }
}

Le paramètre console=ttyS0 relie la console du noyau à la sortie du processus Firecracker, ce qui permet de suivre le démarrage. Lancez la micro-VM :

./firecracker --no-api --config-file vm_config.json

Le noyau défile puis affiche l'invite de connexion. En observant les horodatages de la console, le noyau Linux est prêt en moins d'une seconde, et un Ubuntu complet atteint son invite de connexion en environ deux secondes :

[    0.000000] Linux version 6.1.155+ ...
Welcome to Ubuntu 24.04.3 LTS!
Ubuntu 24.04.3 LTS ubuntu-fc-uvm ttyS0
ubuntu-fc-uvm login: root (automatic login)

Exécuter une commande dans la micro-VM

Le rootfs de test ouvre une session root automatique sur la console. On peut donc lui envoyer des commandes et lire leur résultat. Une fois connecté, vérifiez ce que la micro-VM voit d'elle-même :

uname -r
grep PRETTY /etc/os-release
nproc
free -m | head -2

6.1.155+
PRETTY_NAME="Ubuntu 24.04.3 LTS"
2
               total        used        free      shared  buff/cache   available
Mem:             985         140         890           3          52         845

La micro-VM voit exactement les 2 vCPU et le gigaoctet de mémoire déclarés dans machine-config, ni plus ni moins. C'est une vraie machine isolée, avec son noyau bien à elle (6.1.155+), pas un espace de noms partagé avec l'hôte.

Donner un réseau à la micro-VM

Sans configuration, la micro-VM est coupée du réseau. Firecracker la relie au monde par une interface tap côté hôte, un câble virtuel entre le processus et la pile réseau de l'hôte. Créez le tap et donnez-lui une adresse (ces opérations touchent la configuration réseau de l'hôte, elles demandent sudo) :

sudo ip tuntap add dev fctap0 mode tap
sudo ip addr add 172.16.0.1/24 dev fctap0
sudo ip link set fctap0 up

Ajoutez ensuite une network-interfaces à la configuration, qui associe l'interface invitée au tap de l'hôte, et préconfigurez l'adresse de la VM directement dans les boot_args du noyau :

{
  "boot-source": {
    "kernel_image_path": "vmlinux.bin",
    "boot_args": "console=ttyS0 reboot=k panic=1 pci=off ip=172.16.0.2::172.16.0.1:255.255.255.0::eth0:off"
  },
  "network-interfaces": [{
    "iface_id": "eth0",
    "host_dev_name": "fctap0",
    "guest_mac": "06:00:AC:10:00:02"
  }]
}

Au démarrage, l'interface eth0 de la micro-VM porte l'adresse 172.16.0.2, et la VM joint l'hôte sans effort :

# ip -br addr show eth0
eth0             UP             172.16.0.2/24 ...
# ping -c 2 172.16.0.1
64 bytes from 172.16.0.1: icmp_seq=1 ttl=64 time=0.447 ms
64 bytes from 172.16.0.1: icmp_seq=2 ttl=64 time=0.340 ms
--- 172.16.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss

Pour donner à la micro-VM un accès à Internet, activez le routage IP sur l'hôte et une règle de NAT (iptables -t nat -A POSTROUTING) depuis le sous-réseau du tap vers votre interface physique. En fin de test, supprimez le tap avec sudo ip tuntap del dev fctap0 mode tap.

Cas d'usage et outillage

La micro-VM brille dès qu'on a besoin d'isolation forte à grande échelle et à faible coût. Trois familles d'usages reviennent :

Sandbox d'exécution : lancer du code non fiable (soumissions d'un concours, exécution d'un agent IA) dans une frontière matérielle, sans risquer l'hôte.
CI éphémère : donner à chaque job une VM neuve qui démarre en une seconde et disparaît sans laisser de trace.
Serverless multi-tenant : c'est l'usage d'origine, celui d'AWS Lambda et Fargate, où des millions de fonctions clientes cohabitent isolées.

Piloter Firecracker à la main convient à l'apprentissage, pas à la production. Pour orchestrer des micro-VM en vrai, tournez-vous vers un runtime maintenu : firecracker-containerd (intégration à l'écosystème containerd), Kata Containers (des conteneurs OCI exécutés dans des micro-VM, avec Firecracker comme moteur possible), ou flintlock pour une gestion déclarative.

À retenir

Une micro-VM a son propre noyau invité isolé par KVM, avec la vitesse de démarrage d'un conteneur.
Firecracker est un VMM minimaliste (virtio seul, ni BIOS ni PCI) : démarrage en dizaines de millisecondes, ~5 Mio d'empreinte.
Il faut un accès à /dev/kvm, un noyau vmlinux et un rootfs (convertir le squashfs de test en ext4 avec mkfs.ext4 -d).
La configuration tient dans un fichier JSON : boot-source, drives, machine-config, et network-interfaces pour le réseau.
Le réseau passe par une interface tap côté hôte ; la VM joint l'hôte en moins d'une milliseconde.
Pour la production, pilotez Firecracker avec un runtime maintenu : firecracker-containerd, Kata Containers ou flintlock.

Prochaines étapes

Qu'est-ce qu'une VM Les fondamentaux de la virtualisation avant de plonger dans les micro-VM.

Hyperviseurs type 1 et type 2 Situer Firecracker dans le paysage de la virtualisation.

Panorama de la virtualisation Revenir au hub pour explorer les autres approches.