Votre VPS peut-il exécuter des microVM Firecracker ?

Votre VPS peut-il exécuter des microVM Firecracker ?

Votre VPS ne peut exécuter des microVM Firecracker que si le fournisseur vous donne accès à /dev/kvm. Firecracker est un VMM (virtual machine monitor) qui repose sur KVM (kernel-based virtual machine), la couche de virtualisation intégrée à Linux. KVM a besoin des instructions de virtualisation du processeur. Sur un VPS, vous ne disposez de ces instructions que si le fournisseur les transmet à votre machine virtuelle, ce que la plupart des offres ne font pas.

La première question n’est donc pas de savoir quel outil de microVM installer. Il faut d’abord vérifier si la machine que vous payez déjà peut en héberger une. C’est une question liée à l’hébergement. Vous pouvez y répondre en environ une minute.

Vérifiez /dev/kvm avant toute installation

Exécutez ces trois commandes directement sur le VPS.

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

Une machine capable d’héberger des microVM répond comme ceci :

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

La première ligne correspond au nœud de périphérique KVM, appartenant au groupe kvm. La deuxième ligne indique que cette machine est elle-même une guest exécutée sous KVM, ce qui est normal et attendu sur un VPS. La troisième ligne compte les cœurs CPU qui signalent le flag de virtualisation matérielle, vmx sur Intel et svm sur AMD. Une valeur supérieure à zéro dans une guest signifie que l’hyperviseur vous expose la virtualisation imbriquée.

Vérifiez ensuite que votre utilisateur peut ouvrir le périphérique. Il s’agit du test utilisé dans le document officiel de prise en main de Firecracker :

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

FAIL alors que le nœud existe indique un problème de permissions, et non un problème matériel. Accordez l’accès à votre propre utilisateur avec sudo setfacl -m u:${USER}:rw /dev/kvm, ou ajoutez-vous au groupe avec sudo usermod -aG kvm ${USER}, puis reconnectez-vous.

Ubuntu fournit également une vérification qui récapitule tout cela en deux lignes :

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

Un hôte fonctionnel affiche INFO: /dev/kvm exists, puis KVM acceleration can be used. Un hôte qui ne peut pas fonctionner affiche INFO: Your CPU does not support KVM extensions, puis KVM acceleration can NOT be used. Sur une machine physique, vous pouvez voir à la place INFO: KVM (vmx) is disabled by your BIOS, ce qui peut être corrigé dans le firmware. Sur un VPS, ce message est rare, car vous n’accédez pas au véritable firmware.

Que signifie chaque résultat pour /dev/kvm ?

Le nœud existe et le nombre de flags est supérieur à zéro. La virtualisation matérielle est disponible, donc Firecracker fonctionnera. Passez à la section sur le dimensionnement : votre contrainte restante concerne la mémoire, et non les fonctionnalités du processeur.

Aucun nœud, systemd-detect-virt affiche kvm ou qemu, et le nombre de flags est 0. Votre VPS est une machine virtuelle dont l’hôte ne transmet pas les fonctionnalités de virtualisation. Rien de ce que vous installez dans le guest ne peut changer cela, car le flag est une propriété du processeur virtuel que l’hyperviseur a configuré pour vous. sudo modprobe kvm_intel échoue avec modprobe: ERROR: could not insert 'kvm_intel': Operation not supported, et sudo dmesg | grep -i kvm consigne l’absence de la prise en charge matérielle. C’est le cas le plus fréquent avec les offres de VPS mutualisés. Demandez au fournisseur si l’offre prend en charge la virtualisation imbriquée. Si ce n’est pas le cas, vous avez besoin d’un autre hébergement, pas d’une autre commande.

systemd-detect-virt affiche lxc, lxc-libvirt ou openvz. Votre offre utilise la virtualisation par conteneurs : vous partagez le kernel de l’hôte. /dev/kvm n’apparaîtra jamais, car vous n’avez pas votre propre kernel dans lequel charger un module. Aucun package ne peut résoudre ce problème.

Les flags sont présents, mais le nœud n’existe pas. Le module n’est simplement pas chargé. Exécutez sudo modprobe kvm_intel (ou kvm_amd sur AMD), puis vérifiez de nouveau ls -l /dev/kvm. Si le nœud apparaît, inscrivez le nom du module dans /etc/modules-load.d/kvm.conf pour qu’il soit rechargé après un redémarrage.

Vous utilisez arm64. vmx et svm sont des noms propres à x86 ; le nombre de grep est donc 0 sur toutes les machines arm64, que la virtualisation fonctionne ou non. Sur arm64, fiez-vous au nœud de périphérique ainsi qu’au test de lecture et d’écriture.

Pourquoi utiliser une microVM plutôt qu’un conteneur pour un agent

Un conteneur est un processus exécuté sur votre noyau, isolé par des namespaces et des cgroups. Il n’y a qu’un seul noyau, et c’est le vôtre : une faille permettant de sortir du noyau atteint donc l’hôte. Une microVM démarre son propre noyau à l’intérieur d’une frontière de virtualisation matérielle. Elle communique avec un modèle de périphériques émulés réduit, au lieu d’accéder à l’ensemble des appels système de l’hôte. Firecracker maintient volontairement ce modèle très réduit. C’est le principe de conception : moins de périphériques émulés signifie moins de possibilités de sortie.

Cette différence est importante pour un agent de codage, car le code exécuté par un agent n’a pas été lu au préalable. Il installe des paquets, exécute des scripts de build et réessaie à la vitesse de la machine lorsqu’une opération échoue. Un noyau séparé signifie qu’une mauvaise opération endommage une machine que vous pouvez supprimer, sans affecter le reste.

La contrainte découle directement du mécanisme. L’isolation matérielle nécessite la virtualisation matérielle, et c’est précisément ce que votre offre VPS peut ne pas fournir. Un conteneur n’en a pas besoin. C’est pourquoi les conteneurs fonctionnent sur toutes les offres proposées jusqu’à présent.

Ainsi, lorsque /dev/kvm est absent, la VM jetable pour les agents de codage basée sur un conteneur reste la bonne solution. Elle constitue un véritable contrôle, et non une solution de remplacement par défaut. Un conteneur jetable, sur un hôte qui ne contient aucun identifiant important, restauré depuis un snapshot dès qu’il se comporte mal, bloque la plupart des problèmes réellement rencontrés. Il en va de même pour la configuration plus simple décrite dans exécuter un agent de codage sur un VPS. Utilisez une microVM lorsqu’un agent doit fonctionner sans surveillance pendant plusieurs heures sur du code que vous n’avez pas vérifié, et lorsque vous contrôlez l’hôte.

Ce qu’un hôte agent de microVM doit fournir

Nehemiah est un exemple actuel de cette catégorie : un daemon sous licence Apache-2.0 qui fournit à une IA une véritable machine Linux à la demande, avec une microVM Firecracker par machine. Son README énonce clairement la condition requise : « une machine Linux avec /dev/kvm », et plus précisément « Ubuntu 24.04, x86_64 ou arm64, avec /dev/kvm (bare metal ou VM avec virtualisation imbriquée) sur laquelle vous pouvez vous connecter en SSH en tant que root ».

La configuration documentée consiste à exécuter une commande sur cette machine :

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 effectue un preflight via SSH et s’arrête immédiatement si la machine ne convient pas. Les deux refus matériels sont les suivants :

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

Le premier message est le point central de cet article. L’installateur pose la même question que celle que vous venez de poser avec ls -l /dev/kvm, et obtient la même réponse décevante sur la plupart des offres VPS.

Une fois le preflight terminé, l’installation porte sur toute la machine : Firecracker et son jailer, une toolchain Go, un kernel invité et un root filesystem, une image invitée Python, une image de bureau facultative avec un navigateur, ainsi que deux unités systemd nommées nehemiahd.service et boring-net.service. Le daemon répond ensuite sur le port 8080. En cas d’échec du health check, il affiche /healthz didn't return ok. SKIP_DESKTOP=1 ignore l’image de bureau, dont la construction prend environ 8 minutes selon le README.

Lisez les précautions avant de coller cette commande

Elle nécessite un accès SSH en tant que root sur un hôte vierge. L’installateur écrit des paquets système, des unités systemd et la configuration réseau avec les privilèges root. Utilisez une machine que vous êtes prêt à reconstruire entièrement, et non le serveur qui héberge déjà votre site.

Le daemon se lie par défaut à 0.0.0.0:8080. Toute personne qui peut atteindre ce port peut créer des machines, et ces machines consomment la clé de modèle que vous avez fournie à l’installateur. Définissez NEHEMIAH_TOKEN pour imposer une authentification, ou définissez BIND_LOCALHOST=1 afin que le daemon se lie uniquement à 127.0.0.1 et que vous y accédiez via un tunnel avec ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP. Protégez cette clé comme n’importe quel autre secret présent sur le serveur, comme indiqué dans ne pas exposer les secrets aux agents d’IA.

Chaque machine est un ordinateur qui dispose d’un accès à Internet et d’agents préinstallés. Le README répertorie claude, codex, cursor et pi dans l’environnement invité, en plus de node, python et git. Le projet indique que les environnements invités sont placés derrière un pare-feu de sortie et que la séparation elle-même est effective. L’environnement invité accède tout de même au réseau par conception, car un agent de programmation incapable de télécharger un paquet est inutilisable. Prévoyez ce fonctionnement au lieu de supposer qu’il s’agit d’un réseau isolé.

Il n’existe aucune release taguée. Au 10 août 2026, le dépôt ne comporte aucun tag. Le clonage de main récupère donc le contenu ajouté ce matin-là. Épinglez un commit et lisez le script avant qu’il ne s’exécute avec les privilèges root sur votre serveur :

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

Le dépôt a été créé fin juin 2026. Considérez donc ce logiciel comme récent. Relisez infra/setup.sh après chaque mise à jour récupérée, car ce que vous autorisez est un accès root à une machine, et non une simple mise à jour de version d’une bibliothèque.

Prouvez que KVM fonctionne avant d’accuser l’installateur

Si l’installation échoue et que vous voulez déterminer si KVM est en cause, testez Firecracker séparément. Voici les étapes de téléchargement fournies par le projet :

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

L’affichage de la version confirme que le binaire correspond à votre architecture et qu’il s’exécute. Il ne confirme pas l’accès à KVM. Associez donc ce test à celui de lecture et d’écriture sur /dev/kvm présenté plus haut. Ces deux vérifications permettent de distinguer un problème lié à l’hébergement d’un problème de packaging. Vous évitez ainsi de déboguer un installateur qui fonctionnait correctement.

De quelle taille de serveur plusieurs microVM ont-elles besoin ?

Chaque microVM contient un véritable noyau invité, ainsi que la mémoire qui lui est attribuée. Cette mémoire reste réservée tant que la machine fonctionne. Dimensionnez donc l’hôte selon la taille des invités et le nombre de machines à exécuter simultanément. Les chiffres ci-dessous sont des calculs, pas des mesures. Un invité sans interface graphique reçoit 1 GB. Un invité de bureau avec un navigateur reçoit 2 GB. L’hôte conserve une réserve fixe de 2 GB pour lui-même, le daemon et la construction des images.

[
  {
    "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
  }
]

Une seule machine sans interface graphique nécessite environ 3 GB. Un VPS de taille moyenne peut l’héberger s’il vous fournit KVM. Quatre machines nécessitent 6 GB. Exécuter 8 machines de bureau demande 18 GB selon le même calcul, avant même de compter un seul gigabyte de disque.

Le disque est le paramètre que personne ne prévoit. L’hôte stocke un noyau invité, un système de fichiers racine de base, une image par type d’invité et un snapshot par machine en fonctionnement. L’image de bureau avec un navigateur est la plus volumineuse. Le README ne fournit aucun chiffre pour le disque. Surveillez donc df -h / pendant la première construction au lieu de vous fier à une estimation.

C’est pourquoi la réponse honnête à la question « quel VPS peut exécuter Firecracker ? » est souvent « une autre catégorie de machine ». Le bare metal vous fournit les CPU flags sans hyperviseur intermédiaire. C’est le compromis présenté dans le choix entre un VPS et un serveur dédié. Certains fournisseurs exposent la virtualisation imbriquée sur leurs offres virtuelles. La page virtualisation imbriquée sur un VPS explique comment la vérifier avant de payer. Si le matériel vous appartient déjà, Proxmox face à un VPS classique pose la même question du point de vue de l’hyperviseur.

Le serveur n’est que la moitié du coût. Chaque machine confiée à un agent consomme des tokens de modèle tant qu’elle fonctionne. Une microVM inactive consomme donc de la mémoire, tandis qu’une microVM active consomme de la mémoire et génère des coûts d’API. Une offre de 1 GB ne peut pas héberger l’hôte. Une offre capable d’héberger l’hôte ne vous fournira toujours pas la clé.

FAQ

Comment vérifier si mon VPS peut exécuter Firecracker ?

Exécutez ls -l /dev/kvm, systemd-detect-virt et grep -cE '\b(vmx|svm)\b' /proc/cpuinfo sur le VPS. Un device node appartenant au groupe kvm, avec un nombre de flags supérieur à zéro, indique que Firecracker peut s’exécuter. L’absence du node avec un nombre de 0 indique que l’hyperviseur ne transmet pas la virtualisation, et sudo kvm-ok du package cpu-checker le confirme avec KVM acceleration can NOT be used. Sur arm64, ignorez le nombre, car vmx et svm sont des noms x86.

Puis-je activer la virtualisation imbriquée depuis mon VPS ?

Non. La virtualisation imbriquée est activée par l’hôte, dans son propre module de kernel d’hyperviseur, puis vous est exposée sous forme de flag CPU sur le processeur virtuel qui vous a été attribué. Dans le guest, sudo modprobe kvm_intel renvoie modprobe: ERROR: could not insert 'kvm_intel': Operation not supported, car le CPU virtuel ne dispose d’aucun VMX utilisable. Vos options sont un provider qui propose la virtualisation imbriquée dans son offre, ou une machine dont vous contrôlez l’hyperviseur.

Un conteneur suffit-il pour isoler un agent de programmation ?

Souvent, oui. Un conteneur partage votre kernel : une évasion au niveau du kernel atteint donc l’hôte. Toutefois, un conteneur éphémère sur une machine qui ne contient aucun credential sensible élimine la plupart des risques auxquels vous êtes réellement exposé. Choisissez une microVM lorsqu’un agent exécute sans supervision des tâches longues sur du code non vérifié, et lorsque vous pouvez lui fournir un hôte avec /dev/kvm. Sinon, un conteneur que vous détruisez après chaque tâche est préférable à une microVM que vous ne parvenez jamais à démarrer.

De combien de RAM l’hôte d’un agent en microVM a-t-il besoin ?

Commencez par la taille du guest. Un guest headless de 1 GB avec une réserve de 2 GB pour l’hôte nécessite environ 3 GB au total, et 8 guests desktop de 2 GB chacun nécessitent environ 18 GB. Le disque est à considérer séparément et sa capacité est souvent sous-estimée, car l’hôte conserve un kernel, des root filesystems, une image par type de guest et un snapshot pour chaque machine en cours d’exécution.