AWS fügt Unterstützung für Nested Virtualization hinzu

• Mit dem Update des AWS SDK for Go v2 wurde eine Funktion hinzugefügt, mit der sich eine weitere virtuelle Maschine innerhalb einer virtuellen Maschine ausführen lässt
• Die neue Funktion ermöglicht die Ausführung verschachtelter VMs auch auf Nicht-Bare-Metal-EC2-Instanzen
• Die erweiterte Unterstützung für Nested Virtualization in AWS EC2 dürfte eine Grundlage dafür schaffen, die Nutzung von Virtualisierungsebenen in Entwicklungs- und Testumgebungen zu erhöhen

[GN⁺]

Hacker-News-Kommentare

• Dass man jetzt Firecracker oder andere MicroVMs direkt innerhalb einer AWS-VM ausführen kann, ist eine große Veränderung
  Früher brauchte man dafür teure Bare-Metal-Instanzen
  Zur Einordnung: GCP unterstützt Nested Virtualization schon seit langer Zeit
  • Auf so einen Kommentar habe ich gewartet. MicroVMs wie Firecracker sind genau so ein guter Anwendungsfall
    Ein weiterer Vorteil ist, dass sich Test- oder Entwicklungsumgebungen damit einfach aufsetzen lassen
    Nested Virtualization bedeutet nicht zwangsläufig nur vollständige VMs
  • Ich frage mich, wie groß der Performanceverlust in so einer Umgebung ist
• Die Unterstützung für Nested Virtualization wurde zu den wichtigsten SDKs hinzugefügt
  In der Region us-west-2 sieht man bereits die Option „Nested Virtualization“, und sie ist für die Instanztypen M8id / C8id / R8id verfügbar
  Für Micro-VM-Sandbox-Lösungen wie E2B, an denen ich mitarbeite, sind das wirklich große Neuigkeiten
• Kann jemand erklären, warum das so eine große Sache ist?
  Als ich früher Nested Virtualization ausprobiert habe, hatte ich den Eindruck, dass es außerhalb von PoCs nicht besonders nützlich ist
  • Im Hinblick auf Isolation ist es sehr nützlich
    Es gibt viele VM-basierte Container-Lösungen wie Kata Containers, gVisor und Firecracker
    Zum Beispiel kann man in Kubernetes Pods auf VM-Ebene isolieren
    Außerdem werden Live-Migrationen zwischen EC2-Instanzen möglich, was die Wartung laufender Workloads erleichtert
    Auch in CI/CD-Umgebungen ist es viel praktischer, System-Images direkt auf EC2 zu bauen und zu testen
    GCP, VMWare und KVM boten solche Funktionen bereits, daher war es schade, dass EC2 erst jetzt nachzieht
  • Man kann jetzt VMs innerhalb günstigerer AWS-Instanzen betreiben, ohne eine komplette Bare-Metal-Instanz zu benötigen
    Besonders nützlich ist das für Arbeiten wie Netzwerksimulationen, bei denen mit QEMU Netzwerkhardware emuliert wird
• Es fühlt sich an, als wäre AWS jetzt erst im Jahr 2018 angekommen
  • Stimmt, das ist ziemlich gewöhnlich
    Ich nutze so etwas zu Hause schon seit Langem mit libvirt auf normaler Consumer-Hardware
    AWS holt bei dieser alten Funktion also erst jetzt auf
• Ich frage mich, ob so eine Funktion auch für openclaw oder agentische Systeme nützlich wäre
  • Möglich ist es, aber für ein echtes Deployment würde ich wohl lieber Images mit nix bauen als Nested Virtualization zu verwenden
• Mich interessieren Performancewerte in einer Nested-Virtualization-Umgebung, besonders bei IO-lastigen Workloads
• Ich frage mich allgemein, wie groß die Auswirkungen von Nested Virtualization auf die Performance sind
  Es scheint, als müsste es mehrere Schichten von MMU-Overhead geben
  • Das hängt vom Workload und von der Implementierung ab
    Reine CPU-Arbeit ist fast nicht betroffen, aber IO kann je nach Implementierung fast unverändert oder sehr schlecht ausfallen
    Ereignisse wie Trap/VM-Exit müssen eine zusätzliche Ebene durchlaufen
  • Soweit ich mich erinnere, werden nicht die Virtualisierungsinstruktionen selbst verschachtelt, sondern sie arbeiten kooperativ mit der externen Virtualisierungshardware zusammen
    Ich bin mir nicht sicher, ob die AWS-Implementierung diesem Ansatz folgt
  • In der Praxis liegt der Performanceverlust grob bei 5–15 %
• Für Legacy-Apps klingt das nach hohen Kosten
• Endlich ist es da, ich bin riesig gespannt