AWS ajoute la prise en charge de la virtualisation imbriquée

• Avec la mise à jour de l’AWS SDK for Go v2, une fonctionnalité permettant d’exécuter une machine virtuelle à l’intérieur d’une autre machine virtuelle a été ajoutée
• Cette nouvelle fonctionnalité permet d’exécuter des VM imbriquées même sur des instances EC2 non bare metal
• L’extension de la prise en charge de la virtualisation imbriquée sur AWS EC2 pourrait servir de base pour accroître l’utilisation des couches de virtualisation dans les environnements de développement et de test

[GN⁺]

Commentaires sur Hacker News

• C’est un gros changement : on peut désormais exécuter directement Firecracker ou d’autres microVM à l’intérieur d’une VM AWS
  Avant, il fallait des instances bare metal coûteuses pour faire ce genre de chose
  À noter que GCP prend déjà en charge la nested virtualization depuis longtemps
  • J’attendais ce commentaire. Les microVM comme Firecracker sont justement un excellent cas d’usage
    Le fait de pouvoir mettre en place facilement des environnements de test ou de développement est aussi un avantage
    La nested virtualization ne désigne pas forcément uniquement des VM complètes
  • Je me demande quel est le niveau de perte de performances dans ce type d’environnement
• La prise en charge de la nested virtualization a été ajoutée aux principaux SDK
  Dans la région us-west-2, l’option « Nested Virtualization » est déjà visible, et elle est disponible sur les types d’instance M8id / C8id / R8id
  C’est vraiment une très grande nouvelle pour les solutions de sandbox micro-VM comme E2B, auxquelles je contribue
• Quelqu’un peut expliquer pourquoi c’est si important ?
  Quand j’avais testé la nested virtualization auparavant, j’avais eu l’impression que ce n’était pas très utile au-delà du niveau PoC
  • C’est très utile du point de vue de l’isolation
    Il existe de nombreuses solutions de conteneurs basées sur des VM, comme Kata Containers, gVisor et Firecracker
    Par exemple, on peut isoler les pods Kubernetes au niveau de la VM
    Cela permet aussi la migration à chaud entre instances EC2, ce qui facilite la maintenance continue des workloads
    Dans les environnements CI/CD, cela devient aussi bien plus pratique, car on peut construire et tester directement des images système sur EC2
    GCP, VMWare, KVM et d’autres proposaient déjà ce type de fonctionnalité, donc c’était frustrant de voir EC2 n’arriver que maintenant
  • On peut désormais faire tourner des VM dans des instances AWS moins chères, sans avoir besoin d’utiliser une instance bare metal entière
    C’est particulièrement utile pour des tâches comme la simulation réseau avec QEMU, où l’on émule du matériel réseau
• On a l’impression qu’AWS vient seulement d’arriver en 2018
  • Oui, c’est assez banal
    J’utilise ce genre de chose chez moi depuis longtemps avec libvirt sur du matériel grand public classique
    AWS ne fait que rattraper une fonctionnalité ancienne
• Je me demande si ce genre de fonctionnalité pourrait aussi être utile pour openclaw ou des agents
  • C’est possible, mais pour un déploiement réel, je choisirais probablement une approche de build d’images avec nix plutôt que la nested virtualization
• Je serais curieux de voir les chiffres de performance en nested virtualization, surtout sur les workloads centrés sur les E/S
• Je me demande quel est généralement l’impact de la nested virtualization sur les performances
  J’imagine qu’il doit y avoir plusieurs couches de surcharge MMU
  • Cela dépend du workload et de l’implémentation
    Les tâches purement CPU sont presque sans impact, mais les E/S peuvent être quasi inchangées ou très dégradées selon l’implémentation
    Les événements comme les traps/vmexit doivent passer par une couche supplémentaire
  • Si je me souviens bien, ce ne sont pas les instructions de virtualisation elles-mêmes qui s’empilent, elles fonctionnent de manière coopérative avec le matériel de virtualisation externe
    Je ne sais pas avec certitude si l’implémentation d’AWS suit cette approche
  • En pratique, on observe en gros une baisse de performance d’environ 5 à 15 %
• J’ai l’impression que cela risque de coûter cher pour les applications legacy
• J’ai enfin l’impression que c’est arrivé, enthousiasme total