FreeBSD auf Firecracker

 (usenix.org)
3 Punkte von GN⁺ 2023-08-26 | 1 Kommentare | Auf WhatsApp teilen
  • Das Booten des FreeBSD-14-Kernels auf Firecracker VMM, einer Linux-zentrierten microVM für AWS Lambda, ist ein Beispiel dafür, wie eine minimale Virtualisierungsumgebung verborgene Annahmen und Engpässe im Initialisierungspfad eines Betriebssystems offenlegt
  • Der erste Boot scheiterte an Unterschieden im ELF-Note-Format des PVH boot mode, an Xen-spezifischen Hypercalls und an Firecrackers anderer Speicheranordnung; gelöst wurde dies durch Anpassungen am PVH-Code von FreeBSD
  • Da Firecracker kein ACPI bereitstellt, änderte sich der Weg, über den CPU- und Interrupt-Informationen ermittelt werden; zudem wurde die Option MPTABLE_LINUX_BUG_COMPAT hinzugefügt, um zu einem Fehler in der MPTable-Verarbeitung von Linux kompatibel zu sein
  • Beim Anbinden der seriellen Konsole und der Virtio-Geräte wurden Einschränkungen beim UART-Verhalten, beim Parsen der Kernel-Kommandozeile und bei nicht ausgerichtetem Disk-I/O sichtbar; FreeBSD setzt dafür hw.broken_txfifo, eine Umgehung zum Leeren des FIFO sowie Bounce-Verarbeitung auf Basis von busdma ein
  • Mit nicht committeten Patches bootet der FreeBSD-Kernel in einer VM mit 1 CPU und 128 MB RAM in unter 20 ms; offen bleiben das Mergen der PVH-Unterstützung, die Trennung des Xen-Codes, kleinere Kernel-Konfigurationen und die Prüfung einer FreeBSD-Portierung von Firecracker

Warum FreeBSD auf Firecracker gebracht werden sollte

  • Firecracker ist ein VMM, der auf Linux KVM für serverlose Ausführungsumgebungen wie AWS Lambda microVMs mit geringem Overhead erstellt und verwaltet
  • Die Portierungsarbeit für FreeBSD begann im Juni 2022
  • Die Motivation bestand darin, die Grenzen von FreeBSD und Firecracker gemeinsam auszuloten
    • Aufbauend auf Arbeiten zur Verbesserung der FreeBSD-Bootzeit sollte geprüft werden, wie schnell es auf einem minimalen Hypervisor werden kann
    • Wenn FreeBSD auf eine neue Plattform portiert wird, kommen Bugs sowohl in FreeBSD als auch in der jeweiligen Plattform zum Vorschein
    • AWS Lambda unterstützt derzeit nur Linux; unabhängig davon, ob Lambda FreeBSD übernimmt, ist Firecracker-Unterstützung durch FreeBSD eine notwendige Voraussetzung
    • Firecracker selbst ist eine interessante Plattform, daher sollte überprüft werden, ob es tatsächlich funktioniert

Erste Hürden bis zur Kernel-Ausführung

  • Firecracker wurde ursprünglich zum Ausführen von Linux-Kerneln entwickelt, erhielt 2020 aber einen Patch zur Unterstützung des PVH boot mode zusätzlich zu linuxboot
  • Da FreeBSD PVH-Boots unter Xen unterstützte, wurde derselbe Pfad mit Firecracker ausprobiert
  • Das erste Problem war, dass Firecracker nach dem Laden des FreeBSD-Kernels in den Speicher den kernel entry point nicht finden konnte
    • Das PVH-Boot-Protokoll speichert diesen Wert in einer ELF Note
    • Bei ELF Notes gibt es PT_NOTE und SHT_NOTE, und FreeBSD stellte nicht das Format bereit, das Firecracker suchte
    • Nach einer kleinen Änderung am Linker-Skript des FreeBSD-Kernels konnte Firecracker mit der Ausführung des FreeBSD-Kernels beginnen
  • Die Kernel-Ausführung brach nach etwa 1 Mikrosekunde erneut ab

Frühes Debugging und Entfernen von Xen-Abhängigkeiten

  • Wenn der Kernel stirbt, bevor Kernel-Debugger und serielle Konsole initialisiert sind, helfen die Debugging-Funktionen von FreeBSD kaum weiter
  • Die einzige Information aus dem Firecracker-Prozess war, dass der FreeBSD-Gast einen Triple Fault ausgelöst hatte
  • Durch Einfügen von hlt-Instruktionen in die Mitte des Kernel-Startcodes wurde eine Art „Kernel Bisection“ durchgeführt, um die Absturzstelle einzugrenzen
    • Wird hlt erreicht, läuft Firecracker weiter, die CPU-Auslastung des Hosts fällt aber auf 0 %
    • Wenn Firecracker beendet wird, lässt sich schließen, dass der Absturz vor dieser Stelle passiert ist
  • Die erste Ursache war ein Xen hypercall
    • Der PVH-Einstiegspunkt von FreeBSD war tatsächlich Code zum Booten unter Xen und ging davon aus, innerhalb von Xen zu laufen
    • Das von Firecracker verwendete KVM stellt keine Xen-Hypercalls bereit, daher stürzt die VM beim Aufruf ab
    • Anfangs wurden Xen-Hypercalls auskommentiert; später wurde die Logik so geändert, dass sie erst nach Prüfung der Xen-Signatur per CPUID aufgerufen werden
  • Das Auslesen der physischen Speicherkarte war eine wesentliche Funktion, die bisher von Xen-Hypercalls übernommen wurde
    • Seit PVH Version 1 wird ein Pointer auf die Speicherkarte über die start_info-Seite übergeben
    • FreeBSD wurde so geändert, dass es statt Xen-Hypercalls die Speicherkarte aus PVH Version 1 verwendet
  • Auch Unterschiede in der Speicheranordnung von Firecracker und Xen verursachten Probleme
    • Xen lädt zuerst den Kernel und platziert dann die start_info-Seite am Ende
    • Firecracker legt die start_info-Seite an eine feste niedrige Adresse und lädt danach den Kernel
    • Der FreeBSD-PVH-Code nahm an, dass der Bereich direkt hinter start_info als Scratch Space verfügbar ist; unter Firecracker wurde dadurch der frühe Kernel-Stack überschrieben
    • Gelöst wurde dies, indem Scratch Space hinter allen vom Hypervisor initialisierten Speicherbereichen alloziert wird

Fehlendes ACPI und MPTable-Kompatibilität

  • Auf x86 bezieht FreeBSD Informationen über Festplatten, Netzwerkadapter, CPUs und Interrupt-Controller normalerweise über ACPI
  • Firecracker stellt bewusst nur eine minimale Implementierung bereit und bietet kein ACPI
  • Stattdessen kann FreeBSD die MPTable-Struktur aus der früheren Intel MultiProcessor Specification verwenden
    • In der GENERIC-Kernel-Konfiguration ist sie standardmäßig nicht enthalten
    • In einer schlanken Kernel-Konfiguration für Firecracker konnte sie durch Hinzufügen von device mptable genutzt werden
  • Die von Firecracker bereitgestellte MPTable entsprach nicht dem Standard, sondern war auf die von Linux akzeptierte Form zugeschnitten
    • Linux hatte einen Bug in der Art, wie es MPTable findet und parst
    • Firecracker wurde mit dem Ziel entworfen, Linux zu booten, und stellt deshalb eine nicht standardkonforme Anordnung bereit, die Linux unterstützt
    • Das standardkonform und unabhängig implementierte FreeBSD fand die falsch platzierte MPTable nicht und konnte sie selbst dann nicht parsen, wenn es sie fand
  • In FreeBSD wurde die Kernel-Option options MPTABLE_LINUX_BUG_COMPAT hinzugefügt
    • Sie wird verwendet, wenn Bug-for-Bug-Kompatibilität zur MPTable-Verarbeitung von Linux nötig ist
    • Mit dieser Option kam der FreeBSD-Boot unter Firecracker weiter voran

Unterstützung für serielle Konsole und Virtio-Geräte

  • Eines der wenigen von Firecracker bereitgestellten emulierten Geräte ist ein serieller Port
    • In einer üblichen Konfiguration werden Standardein- und -ausgabe des Firecracker-Prozesses zur Ein- und Ausgabe des seriellen Ports der VM
  • Der FreeBSD-Kernel bootete mit einer im Kernel-Image enthaltenen Root-Disk, und auch die Konsolenausgabe des Kernels ließ sich lesen
  • Beim Übergang zum Userland-Boot blieb die Konsolenausgabe nach 16 Zeichen stehen
    • Das entsprach den Symptomen eines früheren UART-Bugs in QEMU
    • Wenn das Transmit-FIFO des UART leer war, kam kein Interrupt, sodass FreeBSD nach 16 Bytes nicht weiterschreiben konnte
    • Gelöst wurde dies, indem der bestehende Workaround des FreeBSD-Kernels, hw.broken_txfifo="1", als Kernel-Umgebungsvariable einkompiliert wurde
  • Auch die Konsoleneingabe funktionierte nicht
    • Firecracker nahm an, dass das Receive-FIFO des emulierten UART voll sei, und las deshalb nicht von der Konsole
    • FreeBSD füllte während der UART-Initialisierung das Receive-FIFO mit Müllwerten, um dessen Größe zu messen, und leerte es anschließend über das FIFO Control Register
    • Firecracker implementiert das FIFO Control Register nicht, sodass das FIFO dauerhaft voll blieb
    • FreeBSD wurde so geändert, dass es nach dem Leeren des FIFO, falls LSR_RXRDY weiterhin gesetzt ist, Zeichen einzeln ausliest und verwirft, um das FIFO zu leeren
  • Für Disk- und Netzwerkzugriff waren Virtio block/network-Geräte nötig
    • Firecracker stellt sie als mmio-Geräte bereit
    • In die FreeBSD-Firecracker-Kernel-Konfiguration wurde device virtio_mmio aufgenommen
  • FreeBSD erwartete ursprünglich, mmio-Geräte über FDT zu entdecken, während Firecracker auf der Kernel-Kommandozeile Direktiven wie virtio_mmio.device=4K@0x1001e000:5 übergibt
    • FreeBSD fügte Code hinzu, der diese Direktiven parst und Geräteknoten für virtio_mmio erstellt
    • Sobald ein Geräteknoten existiert, erkennt der bestehende Probe-Prozess von FreeBSD den Virtio-Gerätetyp und bindet den passenden Treiber an
  • Bei mehreren Virtio-Geräten entstand ein Problem beim Parsen der Kernel-Kommandozeile
    • Firecracker übergibt mehrere key=value-Paare nach Linux-Art
    • FreeBSD parst die Kernel-Kommandozeile als Umgebungsvariablen; wenn es zwei Einträge mit dem gleichen Namen virtio_mmio.device= gibt, bleibt nur einer erhalten
    • Der frühe Parser für die Kernel-Umgebung wurde so geändert, dass doppelte Variablen mit einem nummerierten Suffix bewahrt werden, etwa als virtio_mmio.device= und virtio_mmio.device_1=
  • Nach einem abnormalen Shutdown kam es beim nächsten Boot zu einer Kernel Panic, sobald fsck lief
    • fsck ist einer der seltenen Fälle, die unter FreeBSD nicht seitenausgerichtetes Disk-I/O erzeugen
    • Firecrackers Virtio-Implementierung akzeptiert nur einen einzelnen Datenpuffer und unterstützt nicht den üblichen Virtio-Ansatz, Puffer über Seitengrenzen hinweg in mehrere Segmente aufzuteilen
    • Der Virtio-Block-Treiber von FreeBSD wurde auf die Verwendung von busdma umgestellt; nicht ausgerichtete Requests werden über temporäre Puffer per Bounce-Verarbeitung an die Firecracker-Beschränkungen angepasst

Von Firecracker offengelegte Boot-Optimierungen

  • Nachdem FreeBSD unter Firecracker zu laufen begann, wurden Ansatzpunkte zur Reduktion von Bootzeit und Speicherverbrauch deutlich
  • In einer VM mit 128 MB RAM war fast die Hälfte des Systemspeichers im Zustand wired, und Prozesse wurden häufig beendet
    • Die Untersuchung ergab, dass busdma 32 MB für Bounce Pages reservierte
    • Wegen der Firecracker-Beschränkungen braucht jedes Disk-I/O höchstens eine Bounce Page von 4 KB
    • Ein Patch, der die Reservierung von Bounce Pages für Geräte mit nur wenigen unterstützten I/O-Segmenten begrenzt, reduzierte den Speicherverbrauch auf 512 KB
  • Optimierungen am Kernel-Zufallszahlengenerator verkürzten die Bootzeit
    • In VMs ist hardwaregerätebasierte Entropie möglicherweise nicht effektiv
    • RDRAND auf x86 wird als Backup-Entropiequelle genutzt, aber pro Anfrage wurde nur wenig Entropie abgerufen, und das nur alle 100 ms
    • Die Logik wurde so geändert, dass genug Entropie angefordert wird, um den Fortuna-Zufallszahlengenerator vollständig zu seeden, was 2,3 Sekunden einspart
  • Auch die Verarbeitung der Host ID wurde beschleunigt
    • Üblicherweise setzt der Bootloader smbios.system.uuid anhand von BIOS- oder UEFI-Informationen
    • In Firecracker gibt es keinen Bootloader, daher wird keine ID bereitgestellt
    • Das Verhalten wurde so geändert, dass bei fehlerhaften Hardware-IDs nach einer Warnung 2 Sekunden gewartet wird, bei komplett fehlender ID aber still und schnell fortgefahren wird
  • Die Wartebedingung für IPv6 DAD wurde eingegrenzt
    • FreeBSD wartete auf Duplicate Address Detection, wenn IPv6 auf einem Netzwerk-Interface aktiviert war
    • Auf dem loopback-Interface war IPv6 immer aktiviert
    • Durch die Änderung, nur dann auf DAD zu warten, wenn auf einem Nicht-loopback-Interface IPv6 vorhanden ist, wurden 2 Sekunden eingespart
  • Feste Wartezeiten beim Reboot- und Shutdown-Prozess wurden entfernt
    • Das Verhalten, beim Reboot nach der Meldung Rebooting... 1 Sekunde auf Abschluss von printf und Lesezeit zu warten, wurde durch das sysctl kern.reboot_wait_time ersetzt; der Standardwert ist 0
    • Auch die zusätzliche Wartezeit von 1 Sekunde, nachdem der BSP beim Shutdown oder Reboot das Stoppsignal der anderen CPUs erhalten hat, wurde entfernt
  • Mit TSLOG wurde ein Boot-Flame-Chart analysiert
    • Die minimale Umgebung von Firecracker enthält wenig Rauschen, wodurch verbleibende Engpässe leichter sichtbar wurden
    • Da die VM sehr schnell startet, waren neuer Kernel-Build, Ausführung und Erstellung des Flame Chart oft in weniger als 30 Sekunden möglich
  • Durch die TSLOG-Analyse wurden mehrere Engpässe im Millisekundenbereich reduziert
    • Die 100000-Iterationen-Kalibrierungsschleife in lapic_init wurde auf 1000 Iterationen reduziert und spart 10 ms
    • ns8250_drain rief bisher für jedes Zeichen DELAY auf; durch die Änderung, erst LSR_RXRDY zu prüfen und nur bei Bedarf zu verzögern, werden 27 ms eingespart
    • Firecracker wurde dazu gebracht, ein CPUID leaf zu implementieren, das die Frequenzen von TSC und local APIC clock meldet, was 20 ms spart
    • kern.nswbuf wurde von einem konstanten Wert 256 auf 32 * mp_ncpus geändert, was in einer 1-CPU-VM 5 ms spart
    • Wird die Bubblesort-Implementierung in mi_startup durch Quicksort ersetzt, lassen sich 2 ms einsparen; Stand 22. August 2023 ist dies noch nicht committet
    • Wird vm_mem von der sofortigen Initialisierung der vm_page-Strukturen für den gesamten physischen Speicher auf Lazy-Initialisierung umgestellt, lassen sich 2 ms einsparen; zum selben Datum ist dies noch nicht committet
    • Wenn MAP_POPULATE zum mmap des Guest Memory in Firecracker hinzugefügt wird, sinken die Linux-Kosten zum Erzeugen der Seitenstrukturen beim ersten Seitenzugriff um 2 ms; zum selben Datum ist dies noch nicht committet

Aktueller Stand und verbleibende Arbeit

  • FreeBSD bootet unter Firecracker und läuft sehr schnell
  • Mit nicht committeten Patches in FreeBSD und Firecracker kann der FreeBSD-Kernel in einer VM mit 1 CPU und 128 MB RAM in unter 20 ms booten
  • Die verbleibende Arbeit konzentriert sich auf die Bereinigung der PVH-Unterstützung und kleinere Kernel-Konfigurationen
    • Die oben genannten Patches müssen committet werden
    • Die Unterstützung für den PVH boot mode muss in Firecracker mainline gemergt werden
    • Der PVH-Boot-Code ist mit Xen-Unterstützung vermischt und muss davon getrennt werden
    • Der FreeBSD-arm64-Kernel kann derzeit nicht ohne PCI- oder ACPI-Unterstützung gebaut werden; durch Entfernen falscher Abhängigkeiten ließe sich ein FreeBSD/Firecracker-Kernel weiter verkleinern
    • Für die Prüfung, ob eine Speicherreservierung für Intel-GPUs nötig ist, werden 25 µs aufgewendet; eine kleinere Kernel-Konfiguration könnte die Bootzeit noch um einige Mikrosekunden senken
  • Längerfristig besteht auch die Möglichkeit, Firecracker so zu portieren, dass es auf FreeBSD läuft
    • Firecracker wurde unter der Annahme geschrieben, Linux KVM zu verwenden
    • Es wird kein grundlegender Grund gesehen, warum es nicht so angepasst werden könnte, dass es den Kernel-Teil des FreeBSD-Hypervisors bhyve nutzt
  • Wer experimentieren möchte, kann einen FreeBSD-14.0-Kernel für amd64 mit der FIRECRACKER-Kernel-Konfiguration bauen und den feature/pvh-Branch des Firecracker-Projekts verwenden
    • Falls dieser Branch nicht mehr existiert, bedeutet das, dass der Code in den mainline-Firecracker-Tree gemergt wurde

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-08-26
Meinungen auf Hacker News

  • Mir war nicht wirklich klar, dass Firecracker-VMs nicht einfach nur eine Linux-Container-Technologie sind, sondern vollwertige virtuelle Maschinen.
    Anfangs mag das ineffizient klingen, aber wenn man sich reale Einsatzfälle wie fly.io ansieht, ist es erstaunlich, dass Micro-VMs so klein und trotzdem leistungsfähig genug sein können.

    • Wer mehr wissen möchte, sollte sich unser NSDI'20-Paper dazu ansehen, warum wir diesen Weg gewählt haben (https://www.usenix.org/conference/nsdi20/presentation/agache), sowie den Firecracker-Quellcode und die Dokumentation (https://github.com/firecracker-microvm/firecracker).
      Dank KVM und minimaler Hardware-Unterstützung (kein PCI, kein ACPI usw.) ist der Firecracker-Quellcode ziemlich einfach und auch für Nicht-Spezialisten vergleichsweise gut lesbar.
    • Ein Cloud-Anbieter auf Enterprise-Niveau wie AWS würde niemals zulassen, dass Container verschiedener Kunden in ECS oder Lambda gemeinsam in einer einzelnen VM liegen.
      Genau deshalb gibt es Firecracker.
    • Firecracker ist keine „vollwertige“ Maschine, weil vieles entfernt wurde, was Lambda und zufällig auch der Anwendungsfall von fly.io nicht brauchen.
      ACPI, das im Artikel genannt wird, ist ein Beispiel dafür. Trotzdem stimmt es, dass Hardware und nicht der Kernel virtualisiert wird, und die Initialisierung ist so schnell, dass die meisten Nutzer wohl keinen Unterschied merken würden, wenn sie normales containerd durch firecracker-containerd ersetzen.
    • KVM ist erstaunlich.
      Neben Firecracker werden derzeit mehrere Micro-VMs wie crosvm, cloud-hypervisor und Dragonball von Kata auf KVM entwickelt.
    • Ich finde es überraschend, dass es nicht Standard ist, einen Mikrokernel zu bauen, der einen Linux-Userspace oder *NIX-Userspace nachbildet, zugeschnitten auf die Teilmenge virtueller Hardware, die Firecracker und QEMU bereitstellen.
      Ich habe nicht den Eindruck, dass es besonders schwierig ist, ein neues Target für Programmiersprachen zu implementieren. Wenn man also ein betriebssystemähnliches Target wie WASI/WASM baut und PRs an die unterstützten Sprachen schickt, ließe sich wohl der Großteil des Overheads reduzieren. Der schwierigste Teil dürfte sein, den Linux-Userspace hinreichend exakt nachzubilden; weil dessen Oberfläche aber so groß ist, scheint mir der Weg über ein betriebssystemähnliches Target sogar am besten zu sein.

  • Wenn Colins Patches in FreeBSD und Firecracker landen, liegt die gesamte Kernel-Bootzeit unter 20 ms.
    Wir leben wirklich in einer kaum zu glaubenden Zeit.

    • Ich frage mich, wie das im Vergleich zu Linux auf Firecracker aussieht.
      Eine kurze Suche liefert zwar Zahlen, aber die stammen von vor ein paar Jahren, und es ist unklar, ob die Bootzeit auf dieselbe Weise gemessen wurde oder ob „Bootzeit“ überhaupt gleich definiert ist. Daher weiß ich nicht, ob sie vergleichbar sind.

  • Das ist Colins jüngster BSDCan-Vortrag, der vor ein paar Tagen veröffentlicht wurde.
    https://youtu.be/MT3cdeuRTzs?si=l6baNriUjcvy0ZOE

    • Zur Einordnung: Das ist nahezu derselbe Inhalt.
      Nach dem BSDCan-Vortrag fragte das FreeBSD Journal, ob er den guten Vortrag in einen Artikel umwandeln könne; nachdem der FreeBSD-Journal-Artikel erschienen war, fragte ;login:, ob sie ihn erneut veröffentlichen dürften.

  • In qemu gibt es ein von Firecracker inspiriertes microvm.
    https://qemu.readthedocs.io/en/latest/system/i386/microvm.ht...

    • Ich frage mich, wie viele solcher Workarounds in QEMU nötig sind.
      Natürlich sind einige davon FreeBSD-Bugfixes und daher unvermeidlich.

  • Interessant ist, dass sich herausstellt, dass ein großer Teil der 1-Sekunden-Wartezeit eigentlich gar nicht nötig ist.
    Ich frage mich, wie viele Systemadministratoren tatsächlich etwas Sinnvolles getan haben, wenn das System wegen einer falschen Maschinen-UUID angehalten wurde.

    • Vermutlich hat ein ziemlich großer Anteil der Systemadministratoren, die diese 1-Sekunden-Wartezeit erlebt haben, irgendetwas unternommen.
      Anders ist es dagegen bei „dem Benutzer eine Meldung ausgeben, dass neu gestartet wird, eine Sekunde warten, damit er die Konsole lesen kann, und dann rebooten“.

  • Ich will nicht besserwisserisch klingen, aber ich frage mich, für welche Anwendungsfälle so etwas wie Firecracker-Instanzen geeignet ist.
    Ich nutze FreeBSD überall, vom Colocation-Server bis zum privaten PC, und bin eher ein alter Unix-Administrator als ein Entwickler. Ich bevorzuge Bare Metal, begrüße aber Zukunftstechnologien, die zum Betriebssystem beitragen. Bei Buzzwords wie Lambda oder Firecracker weiß ich allerdings trotz allem nicht wirklich, wofür sie praktisch eingesetzt werden. Docker und Container verstehe ich, k8s gerade so, aber ich verstehe nicht, warum man eine VM starten und direkt wieder entfernen sollte, statt einfach eine VM hochzufahren und bei Bedarf zu nutzen. Geht es rein um Cloud-Erfahrung oder Kosteneinsparungen?

    • Anwendungsinstanzen werden als Teil des Request/Response-Lebenszyklus erzeugt.
      So kann jeder Knoten in der Compute Plane beliebigen Anwendungstraffic verarbeiten. Eine Anwendung kann wachsen, indem sie je nach verändertem Traffic-Muster dynamisch freie Compute-Ressourcen der Plane nutzt, und verbraucht keine Ressourcen, wenn sie keinen Traffic verarbeitet. Die Kapazität der Compute Plane zu erhöhen bedeutet, mehr Knoten online zu bringen. Abgesehen von der Verwaltung vieler großer Deployments fällt mir kein besonderer Anwendungsfall ein; in Umgebungen, in denen es nicht um „Scale“ geht, bleibt diese Technik unterhalb der Anbietergrenze verborgen.
    • Der wichtigste Anwendungsfall sind gelegentlich genutzte APIs.
      Wenn man einen Service betreibt, dessen API nicht häufig genutzt wird, der bei einem Aufruf aber schnell antworten muss, passen Lambda oder ähnliche Ansätze gut. Tatsächlich fallen viele APIs für Smartphone-Apps in diese Kategorie, und man möchte nicht 99 % der Zeit eine Maschine im Leerlauf laufen lassen, nur um auf solche API-Aufrufe zu reagieren.
    • „Einfach eine VM hochfahren und bei Bedarf nutzen. Sie ist immer eingeschaltet und immer bereit“ bedeutet eben auch, dass sie immer abgerechnet wird.
    • Fast jedes Unternehmen kann von Scaling profitieren, weil der Traffic nicht rund um die Uhr konstant ist.
      Die meisten tun es nur nicht, weil der Aufwand größer ist als die Einsparungen; Potenzial ist aber vorhanden. Dinge wie Lambda und Firecracker machen das deutlich einfacher.

  • Schade, dass weder AWS noch macOS auf ARM Nested Virtualization unterstützen
    Wenn sie das unterstützen würden, wäre es deutlich einfacher, Firecracker-basierte Technologien zu entwickeln und bereitzustellen.

    • Soweit ich weiß, kann man auf .metal-Instanzen virtualisieren
      Eigentlich ist Virtualisierung auf jedem Instanztyp möglich, aber Hardwarebeschleunigung kann meines Wissens nur auf .metal-Instanzen genutzt werden.
    • Nebenbei: AWS-a1.metal-Instanzen sind ziemlich klein und daher für die Arbeit mit Virtualisierungstechnik im Kosten-Nutzen-Verhältnis vernünftig.

  • Firecracker ist beeindruckend, hat aber viele Sonderfälle, die dokumentiert werden müssen
    Ich bin Colin Percival sehr dankbar, dass er das geteilt hat. Besonders gefällt mir der Satz „nachdem die niedrig hängenden Früchte gepflückt waren“; für Colin sind damit die Custom-bus_dma-Patches gemeint. Jetzt kann jeder kostenlos davon profitieren, dass „ein FreeBSD-Kernel mit 1 CPU und 128 MB RAM in unter 20 ms bootet“. Wenn man an DevOps mit k8s-Clustern oder vielen Docker-Containern gewöhnt ist, ist das wirklich erstaunlich.

  • Ich habe ein wenig mit Firecracker herumgespielt; die Bootzeit ist wie versprochen, aber die Nutzungserfahrung ist ziemlich steinig
    Nachdem ich zum Beispiel gejubelt hatte, weil der Boot gelungen war, war ich ernüchtert, als ich merkte, dass ich für das Networking wieder einem langen Tutorial folgen musste.

    • Hier gibt es eindeutig Raum, mit Automatisierungstools viel Mehrwert zu schaffen
      Es wäre wirklich schön, wenn man ein einzelnes Binary herunterladen und ausführen könnte, woraufhin sowohl ein Webinterface als auch eine API starten, sich alles schnell konfigurieren lässt und die nötigen Dinge automatisch heruntergeladen werden.

  • „Ein FreeBSD-Kernel kann in einer virtuellen Maschine mit 1 CPU und 128 MB RAM in unter 20 ms booten“
    Meine Güte, wie könnte man dasselbe ohne VM auf echter Hardware erreichen? ;)

    • Auch auf echter Hardware ist der Kernel-Boot schnell genug und liegt normalerweise unter 1 Sekunde
      Langsam ist alles andere. Auf meiner Maschine heißt es zum Beispiel: Startup finished in 14.552s (firmware) + 2.885s (loader) + 741ms (kernel) + 23.116s (initrd) + 11.191s (userspace) = 52.488s