Pourquoi ils ont remplacé Firecracker par QEMU

• Hocus (une alternative auto-hébergeable à GitPod/GitHub Codespaces) a remplacé Firecracker par QEMU

Firecracker est optimisé pour des workloads de courte durée qui s’exécutent puis s’arrêtent

• Un hyperviseur de microVM léger, rapide et sécurisé, utilisé par AWS Lambda
• Ce n’est pas si léger que ça
  • Il ne fournit pas de « gestion dynamique de la RAM », pourtant indispensable pour les workloads de longue durée. La RAM allouée une fois n’est pas rendue à l’hôte
  • Il n’existe pas non plus de mécanisme pour restituer le stockage à l’hôte. Même si l’on crée puis supprime un gros fichier dans la VM, l’espace libre n’est pas rendu à l’hôte. Il reste occupé jusqu’à la suppression du disque complet de la VM
  • Il n’y a pas de prise en charge du GPU, ni de disque IO hautes performances

QEMU n’est pas parfait non plus

• Il y a trop de paramètres à configurer
• Pour restituer la RAM inutilisée, l’hôte doit relever trois défis
  • Savoir que cette fonctionnalité existe (elle s’appelle free page reporting et doit être activée manuellement)
  • Comprendre la fonctionnalité DAMON de Linux, savoir à quoi elle sert et comment la configurer, puis compiler un noyau Linux qui la prend en charge
  • Empêcher l’utilisation de Transparent Huge Pages dans le guest, sinon la VM ne rend pas une grande quantité de mémoire
• Il a fallu 2 mois pour l’évaluer
  • lire le code de Firecracker/QEMU,
  • et même échanger des e-mails avec les développeurs pour configurer DAMON
    → (Le développeur de DAMON est M. SeongJae Park, qui est coréen.)

Conclusion

• QEMU dispose des fonctionnalités nécessaires pour faire tourner des workloads génériques
• Mais la configuration demande du temps et de la patience
• Pour des short-lived, untrusted workloads, Firecracker est un bon choix
• Mais si vous voulez faire tourner votre environnement de développement dans une VM, vous pouvez utiliser Hocus (nous avons déjà fait tout le travail difficile)

[tujuc]

C’est bien de présenter son propre produit, mais je me dis aussi qu’il vaut mieux simplement utiliser les services AWS..
Comme l’a dit ssssut, c’est un service qui fonctionne aussi sur Fargate, donc je ne pense pas qu’il faille aller jusque-là.

Je ne comprends toujours pas en quoi le fait de ne pas restituer la mémoire est un problème. Même s’il y a de la contention CPU, l’application ne fera que ralentir, sans empêcher son démarrage, mais pour la mémoire, il n’y a pas de solution...

[ssssut]

Ajout : Firecracker est utilisé non seulement dans AWS Lambda, mais aussi dans ECS Fargate pour des charges de travail de longue durée.

[GN⁺]

Avis Hacker News

• Firecracker est utilisé par CodeSandbox pour héberger des environnements de développement, mais je pense qu’il peut aussi servir à des tâches de longue durée.
• QEMU dispose d’une cible inspirée de Firecracker appelée microvm, un type de machine minimal sans prise en charge de PCI ni d’ACPI, conçu pour des invités de courte durée.
• Cloud-hypervisor est une autre option similaire à Firecracker, qui prend en charge la récupération de mémoire et d’autres fonctionnalités.
• Firecracker possède un périphérique de ballon mémoire qui peut se gonfler et se dégonfler afin de récupérer de la mémoire sur le système hôte.
• Cet article mentionne les limitations de Firecracker, mais ne fournit pas beaucoup d’informations sur QEMU.
• Fly utilise Firecracker pour héberger des processus de longue durée.
• Je voudrais que les VM s’intègrent plus intelligemment à l’hôte, notamment avec la déduplication du cache de blocs et une intégration zero-copy.
• Contrairement à Firecracker, QEMU peut faire du bind mount de volumes, mais cela peut représenter un risque de sécurité.