© donets / 123RF.com

Vor gut vier Jahren überraschte Amazon die IT mit Firecracker: Der Emulator fußt auf PVOps im Linux-Kernel und ist deutlich effizienter und sicherer als das Urgestein KVM. Mittlerweile hat Firecracker sich auch als Alternative zu Containern etabliert.

Virtualisierung gilt heute in der IT als weitgehend abgefrühstücktes Thema, zumal die klassische Voll- und Paravirtualisierung in den vergangenen Jahren massiv an Bedeutung verloren hat. Die Containerisierung macht es möglich: Wo viele Administratoren früher selbstverständlich zu KVM und Qemu oder gar VMware griffen, tun es Container im Tandem mit Kubernetes heute oft ebenso. Paradoxerweise gilt KVM als hochkomplex und kompliziert, vor allem unter der Haube – dabei sind Kubernetes und der Layer Cake, der implizit mit Containern einhergeht, nun auch nicht gerade trivial. Da bleibt mancher Admin doch lieber im gewohnten Umfeld der Vollvirtualisierung, mit allen negativen Konsequenzen, die das mit sich bringt. KVM und Qemu etwa sagt man nach, sie kämen mit massivem Overhead daher und verfeuerten 15 bis 20 Prozent der verfügbaren Ressourcen allein für den eigenen Betrieb.

Dass KVM und Qemu nicht gerade leichtfüßig sind, ist auch Amazon schon aufgefallen, dem Klassenprimus der Cloud-Branche. Für AWS hat man sich dort allerdings schon 2018 einen alternativen Ansatz ausgedacht: Auf Basis der Virtualisierungsfunktion PVOps im Kernel entwickelt man einen neuen VMM (Virtual Machine Manager) namens Firecracker. Er präsentiert sich als schlanker Gegenentwurf zu KVM und Qemu und soll vollvirtualisierte Systeme mit möglichst geringem Overhead ermöglichen.

Wir haben bereits 2019 über Firecracker ausführlich berichtet [1]. Fast vier Jahre später hat sich viel getan. Manche Hoffnungen der Firecracker-Entwickler haben sich erfüllt, andere Aspekte sind bis heute nicht optimal gelöst oder stellen sogar noch ein echtes Hindernis für den produktiven Betrieb dar. Zeitgleich hat Firecracker den Markt nicht annähernd so radikal durchdrungen, wie man es sich bei AWS erhofft haben dürfte. Das hat aber nicht zwingend etwas mit der Qualität von Firecracker zu tun, sondern eher mit dem Umfeld und der Tatsache, dass noch immer fast alle Augen auf Container und Kubernetes gerichtet sind.

Höchste Zeit also für ein Update: Was kann Firecracker mittlerweile, in welche externen Lösungen passt es sich ein, und wie integrieren umsteigewillige Admins die Lösung?

Die Technik

An dieser Stelle schadet ein kurzer Exkurs in die Technik hinter Firecracker nicht, denn die hat sich in den vergangenen vier Jahren verändert. Zur Erinnerung: Firecracker ist eine AWS-eigene Entwicklung für den Dienst Lambda. Der kommt laut AWS für die Verarbeitung von Daten zum Einsatz und führt auf Zuruf bestimmte Programme aus, die in einer strikt separierten Umgebung laufen sollen.

Es geht bei Lambda – und das wird später noch wichtig werden – also nicht primär um virtuelle Instanzen für den allgemeinen Zweck. Dafür gibt es bei AWS schließlich EC2, und Lambda soll keine In-House-Konkurrenz für EC2 sein. Der relevante Unterschied: Die im Rahmen von Lambda gestarteten Instanzen übernehmen kurzzeitig eine einzelne Aufgabe, wobei der Dienst implizit annimmt, dass er die VM nach dem Abwickeln ebendieser Aufgabe löschen kann.

Ein valides Beispiel wäre etwa eine Rechenaufgabe aus dem KI- oder Machine-Learning-Kontext. Rechnet eine Anwendung gerade einen Datensatz durch, benötigt sie dafür Rechenleistung. Lambda eröffnet ihr die Möglichkeit, beliebig viele virtuelle Instanzen zu starten, um die anstehende Aufgabe zu berechnen, und sie danach wieder zu deaktivieren.

Dieses Beispiel zeigt, warum klassische Vollvirtualisierung für AWS keine Option war: Eine KVM-Qemu-Instanz benötigt locker eine halbe Minute, um überhaupt so weit zu hochzufahren, dass sie ein vom Benutzer eingepflegtes Programm starten kann. Dafür sorgt neben dem in der VM vorhandenen BIOS der Umstand, dass in entsprechenden Instanzen üblicherweise Linux-Systeme auf Basis von Standarddistributionen zum Einsatz kommen. Firecracker geht deutlich schneller zu Werke und startet neue Instanzen in unter einer Sekunde, sofern die in der Instanz gestartete Distribution mitspielt. Oft kommt Alpine Linux zum Einsatz, das sich in solchen Szenarien bewährt hat.

Unter der Haube folgt Firecracker dabei einer nicht sonderlich komplexen Architektur (Abbildung 1). AWS hat gut daran getan, das Rad in Sachen Virtualisierung nicht vollständig neu zu erfinden, sondern auf einige bewährte Komponenten aus der Open-Source-Welt zu setzen. Noch heute erstaunt es viele, wenn sie hören, dass KVM als technischer Kern für Firecracker dient – eben jener VMM also, den AWS selbst im Kontext klassischer Para- und Vollvirtualisierung eigentlich verteufelt. Hier kommt es allerdings auf die Details an.

KVM selbst ist ja zunächst einmal nur ein Satz verschiedener Funktionen aus dem Linux-Kernel, der seinerseits auf PVOps fußt. Unter der Bezeichnung PVOps firmiert wiederum eine Technik, die einst auf Geheiß von Linus Torvalds persönlich Einzug in den Linux-Kernel fand und Standardfunktionen definierte, um Voll- und Paravirtualisierung zu ermöglichen. Egal, ob KVM oder Xen: Wer heute unter Linux virtualisiert, nutzt PVOps. Amazon hat quasi eine Abkürzung genommen, indem es keinen komplett neuen Hypervisor entwickelte, sondern auf KVM setzte. Die Art und Weise, wie der Hypervisor gesteuert und gemanagt wird und welcher Emulator zum Einsatz kommt, um die eigentlichen virtuellen Instanzen zu betreiben, macht jedoch den entscheidenden Unterschied zum Gespann aus KVM und Qemu aus.

Abbildung 1: Firecracker fungiert im Gespann mit KVM als Hypervisor und als leichtfüßige Alternative zu Qemu, bietet aber auch deutlich weniger Funktionalität. Quelle: Mathis Joffre

Wie eingangs beschrieben, ist Firecracker eigentlich ein Virtual Machine Monitor (VMM). Das bedeutet, dass Firecracker virtuelle Instanzen so vorbereitet, dass sie sich unter Verwendung der KVM-Funktionen des Linux-Kernels starten lassen. Einen entsprechenden Emulator liefert Firecracker mit. Es bereitet unter anderem entsprechende Festplattenabbilder vor und führt einen Kernel samt Bootloader aus. Obendrein konfiguriert Firecracker Netzwerk- und Storage-Funktionen so, dass Firecracker-Instanzen sie unmittelbar nutzen können. Ein Metadaten-Dienst und eine eigene ReSTful-API machen Firecracker von außen und aus der Ferne steuerbar (Abbildung 2).

Abbildung 2: Anders als etwa Qemu kommt Firecracker mit einer ReSTful-API daher, über die sich der Betrieb und der Start von Instanzen steuern und kontrollieren lassen.

Firecracker selbst läuft zudem in einer Sandbox, die KVM zur Verfügung stellt. Auf diese Weise führt selbst ein Ausbruch aus einer virtuellen Instanz nicht zu unmittelbarem Zugriff auf andere Ressourcen des Hosts. Für AWS wäre das der Super-GAU: Auf einem AWS-Server laufen VMs von Dutzenden, wenn nicht Hunderten Kunden. Ein einzelner Ausbruch ginge hier also mit massiven Gefahren in Sachen Datensicherheit und Datenschutz einher, für die gehosteten Kunden ebenso wie für AWS selbst.

Firecracker bringt zudem ein Werkzeug namens Jailer mit, mit dessen Hilfe sich die Sandbox konfigurieren und dynamisch nutzen lässt. Ab Werk ist eine Firecracker-Instanz gar nicht zwangsläufig mit Storage- oder Netzwerkressourcen versehen. Werden diese benötigt, alloziert der Jailer die benötigten Ressourcen und aktiviert sie in der Sandbox einer virtuellen Instanz, sodass sie sich dort verwenden lassen.

Kritische Stimmen

Gerade in jüngerer Vergangenheit mehrten sich allerdings die kritischen Stimmen im Hinblick auf Firecracker. An und für sich ist das Tool eine hervorragende Lösung für Einsatzbereiche, in denen voll- oder paravirtualisierte Instanzen kurzzeitig laufen sollen, aber eben nur dafür. AWS selbst weist darauf immer wieder hin und spricht von “short-lived instances”, also kurzlebigen Instanzen. Manche Administratoren und Entwickler ignorieren den dezenten Hinweis allerdings, und holen sich damit eine blutige Nase, wie die letzten vier Jahre gezeigt haben.

Die Firecracker-Entwickler betrachten vor allem jene Funktionalität als unnötig, die den Speicherfußabdruck einer Micro-Instanz erhöht oder die Angriffsfläche für Hacker vergrößert. Auch Micro-Instanz (oder MicroVM) ist in diesem Kontext ein zentraler Begriff. Das Schlagwort bezeichnet Instanzen, die für den kurzzeitigen Betrieb eines einzelnen, meist nicht sonderlich großen oder ressourcenintensiven Diensts konzipiert sind. Solche VMs benötigen lediglich die Komponenten für den Betrieb der fraglichen Software sowie einige wenige Treiber, um den Netzwerkverkehr mit dem Host abzuwickeln und auf dessen Arbeitsspeicher und seine CPU zuzugreifen. Anders formuliert: Firecracker fehlen sämtliche Funktionen, die AWS Lambda schlicht nicht benötigt. Dort wird eine Instanz ja nur kurz gestartet, führt eine Aufgabe aus und terminiert dann sofort wieder.

Was passiert, wenn man die Faktoren MicroVM und kurzlebige Workloads außer Acht lässt und Firecracker als vollständigen Ersatz für KVM und Qemu einsetzt, hat man bei Hocus am eigenen Leib erfahren. Hocus bietet vorgefertigte, vorkonfigurierte virtuelle Instanzen für den Betrieb verschiedener Entwicklungsumgebungen und Anwendungen auf Knopfdruck an und kommt auch mit einem gehosteten Angebot in der Cloud daher. Entwickler sollen laut Anbieter davon profitieren, dass sie reproduzierbare, saubere Umgebungen für verschiedene Aufgabenbereiche vorfinden, ohne diese vor Ort selbst entwickeln zu müssen. Der Haken an der Sache: Hocus-Kunden nutzen ihre virtuellen Umgebungen durchaus länger, als es mit der Definition von Kurzlebigkeit nach Lambda-Standards vereinbar ist. Das führte insbesondere in der Anfangszeit von Hocus zu Problemen, denn die ersten Pilotversionen des Diensts setzten statt auf KVM mit Qemu auf Firecracker.

Dabei traten regelmäßig zwei Probleme zutage. Zum einen geben Firecracker-Instanzen einmal vom Host allozierten Speicher nicht mehr an diesen zurück. Wer darin also einen Dienst aufruft, der 32 Gigabyte Arbeitsspeicher benötigt und sich nach getaner Arbeit beendet, hat anschließend eine leere Firecracker-Instanz, die nach wie vor 32 Gigabyte RAM auf dem Host bindet (Abbildung 3).

Abbildung 3: Von wegen leichtfüßig: Hocus konnte beweisen, dass langfristig laufende Firecracker-Instanzen viel mehr RAM benötigen als die Qemu-Pendants. Kein Wunder: Für diesen Einsatzzweck wurde Firecracker schlicht nicht konzipiert. Quelle: Hocus

Zumindest für dieses Problem verspricht Firecracker zwar eine Lösung in Form eines eigenen Ballooning-Treibers für KVM, praktisch nutzbar ist der in einer Lösung wie Hocus laut dessen Entwicklern aber nicht. Damit der Kernel des Host-Systems den Arbeitsspeicher aus einer Instanz zurückfordern kann, muss er zuverlässig sicherstellen, dass die Instanz ihn tatsächlich nicht mehr benötigt. Dazu müsste eine Firecracker-Komponente auf dem Host in die Instanz hineinschauen. Das würde einerseits heftige Anpassungen erfordern und dem Gebot von Voll- und Paravirtualisierung widersprechen und andererseits die gewünschte strikte Trennung zwischen Host und Gast aufweichen.

Eine zweite Schwachstelle besteht laut Hocus-Entwicklern in der Art und Weise, wie Firecracker auf an die Instanz angeschlossenen Blockspeicher zugreift. Dafür kommt eine modifizierte Implementierung von Virtio-blk zum Einsatz, des paravirtualisierten Treibers für den Zugriff auf Blockspeichergeräte. Sie benötigt laut Hocus zwar in der Tat deutlich weniger Arbeitsspeicher als die Standardimplementierung, bietet allerdings auch einen deutlich geringeren Datendurchsatz. Das bremst insbesondere Anwendungen aus, die auf hohe Bandbreiten bei den angeschlossenen Speichergeräten angewiesen sind. Laut Hocus realisiert Firecracker ausschließlich einen MMIO-basierten Transport von Daten, während Qemu bei der Paravirtualisierung auch die schnellere PCI-Variante verwenden kann.

Das Ende vom Lied hat wohl jeder geahnt: Hocus entschied sich letztlich gegen Firecracker und für das klassische Gespann aus Qemu und KVM, mit vielen lokalen Anpassungen. Allerdings weisen die Entwickler ausdrücklich darauf hin, dass das nicht als Kritik an Firecracker zu verstehen sei. Man habe die Software lediglich in einer anderen Art und Weise genutzt, als vom Hersteller vorgesehen. Den eigenen Blog-Eintrag [2] möchte Hocus insofern vor allem als Warnung für Unternehmen verstanden wissen, die einen breitflächigen Ersatz von KVM und Qemu durch Firecracker ins Auge fassen. Sollen Instanzen lange laufen und dabei kontinuierlich Server-Dienste anbieten, ist Firecracker vermutlich nicht das richtige Werkzeug für die Aufgabe.

Integration ist wichtig

Unser erster Artikel zu Firecracker endete 2019 mit der Anmerkung, dass die Lösung in der Open-Source-Welt wohl erst dann wirklich Fahrt aufnehmen werde, wenn sie mit anderen Tools wie Libvirt oder OpenStack integriert wird. Bis heute liegt für Firecracker noch keine Libvirt-Integration vor, und von OpenStack war bislang noch gar nicht die Rede. Das ist allerdings kein sträfliches Versäumnis der Entwickler, sondern hat vor allem mit den schon beschriebenen Einsatzszenarien für Firecracker zu tun.

Ein Gespann aus Firecracker und Libvirt wäre nur dann sinnvoll, wenn das Ziel darin bestünde, kurzlebige virtuelle Instanzen auf Standard-Servern auszurollen. Das gilt noch viel mehr für die Kombination mit OpenStack. Wie beschrieben, taugt Firecracker aber kaum als vollwertiger Ersatz für KVM und Qemu. Eine mögliche Integration mit Libvirt oder OpenStack ergäbe also nur Sinn, wenn es explizit um den Betrieb entsprechender Workloads ginge.

Und da liegt der Hase im Pfeffer: Dass Administratoren auf einem Standard-Server mit KVM ohne umfassende Verwaltungssoftware drumherum kurzlebige Instanzen mit Firecracker ausführen und das von Libvirt steuern lassen, ist, wenn überhaupt, ein sehr seltener Use Case. Im Gespann mit OpenStack ergäbe Firecracker nur Sinn, um einen Dienst wie AWS Lambda nachzubauen. Dafür fehlt in OpenStack allerdings der gesamte Unterbau. Einen Nachbau von AWS Lambda gab es für OpenStack – wenn überhaupt – in Form von Qinling [3] nur in Ansätzen. Selbst dieses Subprojekt von OpenStack ist längst in die ewigen Jagdgründe eingegangen. Weder für den Betrieb mit Libvirt noch für den Betrieb innerhalb von OpenStack ergeben sich mithin sinnvolle Use Cases, zumindest im Augenblick.

Anders sieht die Sache aus, lässt man den Blick in die hippe Welt der Mikroarchitektur-Apps und der Container schweifen. Dort hat sich etwa Kata Containers seit einigen Jahren Meriten erarbeitet, und das mit einem relativ simplen Konzept: Die Lösung wirbt damit, klassische Workloads aus der Container-Welt auszuführen, allerdings in Kombination mit ebenfalls klassischer Virtualisierung. Wie OpenStack ist Kata Containers ein Projekt der OpenInfra Foundation. Im Grunde handelt es sich um ein Management-Framework für den Betrieb von Containern, das Kubernetes ähnelt.

Primär ist Kata jedoch eine CRI-O-kompatible Laufzeitumgebung für Container. Der offene Standard CRI-O definiert eine Laufzeitumgebung für Container und ermöglicht das Entwickeln verschiedener Implementierungen nach standardisierten Vorgaben. Anders als etwa bei der klassischen Docker-Laufzeitumgebung oder Podman von Red Hat sitzt bei Kata aber immer auch eine echte virtuelle Instanz im Boot. Laut Entwicklern erhöht das den Grad der Abstraktion und dadurch implizit die Sicherheit der Workloads in Containern. Weil Kata CRI-O implementiert, lässt es sich unmittelbar mit Kubernetes verwenden. Administratoren müssen sich also nicht zwischen den beiden entscheiden, sondern können die zwei Welten miteinander kombinieren (Abbildung 4).

Abbildung 4: Kata Containers bietet eine CRI-O-kompatible Laufzeitumgebung für den Betrieb von Containern, verschachtelt die Container dabei jedoch auf Wunsch in Firecracker-Instanzen. Quelle: Kata Containers

Zunächst setzte man bei Kata auf das Gespann aus KVM und Qemu, gerade im Container-Kontext tut der resultierende Overhead dieser Lösung ressourcentechnisch allerdings weh. So gesehen kam Firecracker den Kata-Entwicklern gerade recht: Mittlerweile lässt sich anstelle von Qemu auch Firecracker als Backend für den geschachtelten Betrieb von Containern einsetzen. Das stutzt die nutzlose Vergeudung von Ressourcen auf den eigentlichen Compute-Knoten erheblich.

Auch andere Projekte interessieren sich mittlerweile für Firecracker. Zu den bekannteren gehört dabei zweifelsohne OpenNebula: Es verspricht Administratoren ähnlich wie OpenStack den Aufbau und Betrieb einer privaten Cloud-Umgebung, kommt dabei aber deutlich weniger komplex daher und lässt sich insgesamt leichter einrichten. Obendrein verfügt OpenNebula über ein eigenes Framework zur Orchestrierung von Containern, analog zu Kubernetes (Abbildung 5). Für dieses Konstrukt kommt ähnlich wie bei Kata in OpenNebula mittlerweile Firecracker zum Einsatz. Auch hier geht es also nicht darum, für klassische Virtualisierungsszenarien Qemu den Garaus zu machen.

Abbildung 5: OpenNebula entwickelt eine alternative Managementlösung für Container und setzt dabei unter der Haube auf Firecracker. Dadurch spart man im Vergleich zum Betrieb mit Qemu erhebliche Ressourcen. Quelle: OpenNebula

Firecracker ausprobieren

Administratoren kritisieren an Firecracker häufig, dass man es kaum lokal testen könne, um ein Gefühl für die Funktion und die Features der Lösung zu bekommen. So pauschal trifft diese Aussage mittlerweile aber nicht mehr zu, denn tatsächlich lässt sich Firecracker lokal relativ problemlos ausprobieren.

Dabei stellt sich die Frage, ob man die Instanz aus Firecracker heraus lokal über einen API-Aufruf starten möchte – eigentlich der empfohlene Weg –, oder ob der Aufruf mittels einer lokalen Konfigurationsdatei für Testzwecke ausreicht. Falls ja, ist der Rest schnell erledigt: Listing 1 enthält die gesamte Konfiguration zum Start einer Firecracker-Instanz mit einer virtuellen Netzwerkkarte. Um das Beispiel auf der eigenen Hardware nachzustellen, laden Sie mit den Befehlen aus den ersten zwei Zeilen von Listing 2 einen Kernel und ein Dateisystem herunter.

# example_image.json
{
  "boot-source": {
    "boot_args": "ro console=ttyS0 noapic reboot=k panic=1 pci=off nomodules random.trust_cpu=on ip=10.10.10.1::10.10.10.2:255.255.255.252::eth0:off",
    "kernel_image_path": "/tmp/hello-vmlinux.bin"
  },
  "drives": [
    {
      "drive_id": "rootfs",
      "is_read_only": false,
      "is_root_device": true,
      "path_on_host": "/tmp/hello-rootfs.ext4"
    }
  ],
  "machine-config": {
    "mem_size_mib": 2048,
    "vcpu_count": 4
  },
  "network-interfaces": [
    {
      "guest_mac": "02:FC:00:00:00:05",
      "host_dev_name": "tap0",
      "iface_id": "eth0"
    }
  ]
}

$ curl -fsSL -o /tmp/hello-vmlinux.bin https://s3.amazonaws.com/spec.ccfc.min/img/hello/kernel/hello-vmlinux.bin
$ curl -fsSL -o /tmp/hello-rootfs.ext4 https://s3.amazonaws.com/spec.ccfc.min/img/hello/fsfiles/hello-rootfs.ext4
[...]
$ ./firecracker --api-sock /tmp/firecracker.socket --config-file example_vm.json

Damit das Beispiel funktioniert, muss auf dem Hostsystem KVM aktiviert und geladen sein. Zudem müssen Sie eine TAP-Netzwerkschnittstelle anlegen und mit dem eigentlichen Netzwerkgerät des Systems verbinden. Haben Sie alle Vorkehrungen getroffen, lässt sich die Instanz mit dem Kommando aus der letzten Zeile von Listing 2 starten. Das hier genutzte Abbild einer Instanz beherrscht zugegebenermaßen nicht sonderlich viele Befehle. Möchten Sie die virtuelle Firecracker-Instanz genauer untersuchen, finden Sie im Netz aber auch Abbilder für Ubuntu mit umfassenderer Ausstattung.

Fazit

Firecracker ist nach wie vor eine ausgesprochen spannende Technologie für die Verwendung im Rahmen des von AWS entwickelten Einsatzszenarios. Das Werkzeug adressiert spezifisch Einsatzgebiete, in denen vollständig vom Host abgeschirmte Rechenpower gefragt ist, um kurzlebige Aufgaben abzuwickeln. Als vollständiger Ersatz für das klassische Gespann aus KVM und Qemu taugt Firecracker hingegen nicht und will das auch gar nicht. Die AWS-Entwickler selbst weisen darauf hin, dass in Firecracker Features fehlen, um über Monate oder gar Jahre laufende virtuelle Instanzen sinnvoll zu betreiben, die kontinuierlich eine Anwendung beherbergen. Für solche Einsatzgebiete mangelt es Firecracker an den von seinen Entwicklern als unnötig betrachteten Funktionen, etwa an einer Form der interaktiven Speicherverwaltung zwischen Host und virtueller Instanz.

Tatsächlich beschränkt das in der Praxis die Einsatzzwecke von Firecracker weniger, als man glauben könnte. Ein großer Teil der Container in der Industrie läuft heute selbst in virtuellen Instanzen, was doppelt ineffektiv ist: Wer Container in KVM einpackt, holt sich neben dem satten Overhead von Qemu obendrein den impliziten Overhead der Container-Umgebung ins Haus. Gerade in der Container-Welt ist es normal, dass Instanzen kommen und gehen, beispielsweise beim Skalieren einer Anwendung in die Breite. Hier kann Firecracker eine valide Alternative zur Vollvirtualisierung mittels KVM und Qemu bieten. Entsprechend ist das Werkzeug heute – anders als noch vor vier Jahren – in entsprechende Lösungen wie Kata Containers eingebettet.

Hinzu kommt, dass Firecracker aus AWS-Sicht mittlerweile einigermaßen durchentwickelt zu sein scheint. Allzu große Sprünge hat die Firecracker-Entwicklung zumindest in der jüngeren Vergangenheit nicht mehr gemacht. Gut möglich also, dass die Lösung sich ein Standbein vor allem im Container-Kontext sowie im KI/ML-Umfeld erarbeiten wird, wo sie inhaltlich bestens aufgehoben ist. Wer 2019 noch die Palastrevolution im Hinblick auf KVM und Qemu ersehnte (oder je nach Standpunkt befürchtete), sieht sich jedenfalls eines Besseren belehrt. Damit Firecracker KVM und Qemu in der Breite ablösen könnte, müssten seine Entwickler erst einige zentrale Funktionen nachrüsten.

Ein Interesse daran hat Amazon allem Anschein nach allerdings nicht, und das aus gutem Grund: Niemand hätte schließlich etwas davon, bauten die Firecracker-Entwickler peu à peu ein Qemu mit anderen Mitteln nach. (jcb/jlu)