Smol machines – démarrage à froid en moins d’une seconde et machine virtuelle portable

• smolvm est un outil de gestion de machines virtuelles en ligne de commande qui exécute des logiciels dans un environnement isolé
• Il prend en charge un démarrage à froid en moins d’une seconde, une gestion élastique de la mémoire et une portabilité en fichier unique, pour exécuter des VM rapidement et avec légèreté
• Les VM s’exécutent sous forme de microVM basées sur le noyau Linux et peuvent être empaquetées dans un fichier .smolmachine pour être relancées sans dépendances
• Il offre une prise en charge intégrée des environnements de développement et de sécurité avec l’isolation par frontière d’hyperviseur, le transfert d’agent SSH et la déclaration d’environnement via Smolfile
• Il prend en charge le démarrage d’images OCI sans démon Docker et propose une alternative de virtualisation légère avec un temps de démarrage inférieur à 200 ms et une isolation au niveau matériel

---

Vue d’ensemble

• smolvm est un outil de gestion de machines virtuelles en ligne de commande conçu pour exécuter des logiciels dans un environnement isolé
• Il fonctionne sur macOS et Linux et prend en charge un cold start en moins d’une seconde, une utilisation élastique de la mémoire et un empaquetage portable en fichier unique
• Chaque charge de travail s’exécute dans une microVM basée sur le noyau Linux, offrant une isolation au niveau matériel
• Une VM empaquetée dans un fichier .smolmachine peut être relancée sans dépendances sur des plateformes de même architecture

Fonctionnalités principales

• Gestion et exécution de machines virtuelles locales

  • Exécution d’une VM Linux personnalisée avec la commande smolvm machine run
  • Le démarrage à froid prend moins d’une seconde, avec prise en charge de macOS et Linux
  • La mémoire est gérée de façon élastique via virtio balloon, et seule la consommation réelle est allouée à l’hôte

• Empaquetage portable en fichier unique

  • La VM, état inclus, peut être regroupée dans un fichier .smolmachine puis recréée sur une autre plateforme
  • Toutes les dépendances sont intégrées, ce qui permet une exécution immédiate sans installation, avec un temps de démarrage inférieur à 200 ms

• Sandbox pour code non fiable

  • La frontière de l’hyperviseur isole complètement le système de fichiers hôte, le réseau et les identifiants
  • Le réseau est désactivé par défaut, et l’option --allow-host permet d’autoriser uniquement des hôtes précis

• VM persistantes pour le développement

  • Création et gestion des VM avec les commandes machine create, start, stop
  • Les paquets installés sont conservés après redémarrage, ce qui permet un usage comme environnement de développement

• Transfert d’agent SSH

  • L’agent SSH de l’hôte est transmis à l’intérieur de la VM, mais la clé privée n’est pas copiée dans l’invité
  • L’option --ssh-agent permet d’utiliser en toute sécurité l’authentification SSH de l’hôte

• Déclaration d’environnement via Smolfile

  • La configuration de la VM est déclarée dans un Smolfile au format TOML
  • Il est possible de définir l’image, le réseau, les commandes d’initialisation, les volumes, les options d’authentification, etc., pour obtenir un environnement reproductible

Exemples d’utilisation

• Exécution d’une VM temporaire

  • smolvm machine run --net --image alpine -- sh -c "echo 'Hello world'"
  • Mode d’exécution ponctuel dans lequel la VM est automatiquement nettoyée à la fermeture

• Création d’un exécutable empaqueté

  • smolvm pack create --image python:3.12-alpine -o ./python312
  • L’exécutable généré permet de lancer un environnement Python autonome

• Contrôle réseau

  • Le réseau est désactivé par défaut
  • L’option --allow-host permet d’autoriser l’accès uniquement à des domaines précis

• Utilisation de SSH et Git

  • smolvm machine run --ssh-agent --net --image alpine
  • Accès possible à des dépôts Git en utilisant en toute sécurité les clés SSH de l’hôte

Architecture interne et fonctionnement

• Chaque charge de travail exécute un noyau indépendant sur Hypervisor.framework (macOS) ou KVM (Linux)
• Utilise un VMM basé sur libkrun ainsi qu’un noyau personnalisé (libkrunfw)
• Prend en charge le format d’image OCI, ce qui permet de récupérer et d’exécuter directement des images depuis Docker Hub, ghcr.io, etc.
• Aucun démon Docker requis, avec possibilité de démarrer directement des images OCI standard
• La configuration par défaut est de 4 vCPU et 8 Gio de RAM, ajustables via les options --cpus et --mem
• Les threads vCPU passent automatiquement en veille côté hyperviseur lorsqu’ils sont inactifs, ce qui rend le coût de surallocation quasi nul

Comparaison

Élément	smolvm	Containers	Colima	QEMU	Firecracker	Kata
Niveau d’isolation	VM par charge de travail	namespaces (noyau partagé)	namespaces (VM unique)	VM individuelles	VM individuelles	VM par conteneur
Temps de démarrage	<200ms	environ 100ms	quelques secondes	15–30s	<125ms	environ 500ms
Architecture	bibliothèque (libkrun)	démon	démon dans la VM	processus	processus	pile d’exécution
VM par charge de travail	pris en charge	non pris en charge	partagé	pris en charge	pris en charge	pris en charge
macOS natif	pris en charge	via VM Docker	basé sur krunkit	pris en charge	non pris en charge	non pris en charge
SDK intégré	pris en charge	non pris en charge	non pris en charge	non pris en charge	non pris en charge	non pris en charge
Artefact portable	.smolmachine	image nécessitant un démon	non pris en charge	non pris en charge	non pris en charge	non pris en charge

Prise en charge des plateformes

Hôte	Invité	Exigences
macOS Apple Silicon	Linux arm64	macOS 11 ou supérieur
macOS Intel	Linux x86_64	macOS 11 ou supérieur (tests non finalisés)
Linux x86_64	Linux x86_64	KVM (/dev/kvm) requis
Linux aarch64	Linux aarch64	KVM (/dev/kvm) requis

Limitations connues

• Le réseau est désactivé par défaut et ne peut être activé qu’avec l’option --net
• Seuls TCP/UDP sont pris en charge, pas ICMP
• Les montages de volumes ne sont possibles qu’au niveau des répertoires, pas pour un fichier unique
• Sur macOS, seuls les binaires signés avec les autorisations Hypervisor.framework peuvent être exécutés
• Lors de l’utilisation de --ssh-agent, un agent SSH doit être en cours d’exécution sur l’hôte (SSH_AUTH_SOCK doit être défini)

Développement

• Les consignes de développement sont disponibles dans docs/DEVELOPMENT.md
• Publié sous licence Apache-2.0, créé par @binsquare