- Quickemu ist ein Wrapper für QEMU. Wählt man das auszuführende Betriebssystem aus, übernimmt es automatisch die für die Erstellung einer virtuellen Maschine nötige Konfiguration und erstellt bzw. startet Windows-, macOS- und Linux-VMs schnell.
quickget lädt automatisch das gewünschte Upstream-OS-Image herunter und erstellt die VM-Konfigurationsdatei, während quickemu die Hardware erkennt und die VM mit einer zum Rechner passenden Konfiguration startet.- Das ursprüngliche Ziel war es, Linux-Distributionen schnell zu testen. VMs und Konfigurationen können an beliebigen Orten wie externem USB-Speicher oder im Home-Verzeichnis abgelegt werden, und für den Start sind keine erhöhten Rechte erforderlich.
- Inzwischen werden macOS, Windows, die meisten BSDs, FreeDOS, Haiku, KolibriOS, OpenIndiana, ReactOS und weitere Systeme unterstützt — insgesamt fast 1000 Betriebssystem-Editionen.
- Es läuft auf Linux- und macOS-Hosts und bietet die für den VM-Einsatz nötigen Funktionen wie SPICE, Dateifreigabe, QEMU Guest Agent, VirGL, USB-Passthrough, Port-Forwarding, Audio sowie EFI- und Legacy-BIOS-Boot.
Was Quickemu macht
- Quickemu ist ein Wrapper um QEMU, der die bei der Erstellung virtueller Maschinen nötige Konfiguration automatisch übernimmt.
- Nutzer müssen nur das auszuführende Betriebssystem auswählen und viele Konfigurationsoptionen nicht selbst festlegen.
- Es gibt zwei zentrale Werkzeuge:
quickget: lädt das gewünschte Upstream-OS automatisch herunter und erzeugt die VM-Konfigurationsdateiquickemu: erfasst die Host-Hardware und startet die virtuelle Maschine mit einer für den jeweiligen Rechner optimierten Konfiguration
Ausgangspunkt des Projekts und heutiger Umfang
- Das ursprüngliche Ziel war, Linux-Distributionen schnell zu testen.
- VMs und Konfigurationen lassen sich an beliebigen Orten speichern, etwa auf externem USB-Speicher oder im Home-Verzeichnis.
- Zum Start virtueller Maschinen sind keine erhöhten Rechte erforderlich.
- Der heutige Support geht über Linux-Distributionen hinaus und umfasst macOS, Windows, die meisten BSDs sowie verschiedene Nicht-Linux-Betriebssysteme.
- Beispiele dafür sind FreeDOS, Haiku, KolibriOS, OpenIndiana und ReactOS.
Unterstützte Betriebssysteme und Hosts
- Unterstützte Hosts sind Linux und macOS.
- Zu den Gastbetriebssystemen gehören unter anderem:
- macOS Sequoia, Sonoma, Ventura, Monterey, Big Sur, Catalina, Mojave
- Windows 10 und 11, einschließlich TPM 2.0
- Windows Server 2022, 2019, 2016
- Ubuntu und alle offiziellen Ubuntu-Flavours
- die meisten BSDs und zahlreiche Nicht-Linux-Betriebssysteme
- ARM64-Gäste werden unterstützt, sodass sich aarch64-VMs ausführen lassen.
- Auf ARM-Hosts nativ
- Auf x86_64-Hosts emuliert
- Die Zahl der unterstützten Betriebssystem-Editionen liegt bei fast 1000.
VM-Funktionen
- Es bietet vollständige SPICE-Unterstützung, einschließlich gemeinsamer Zwischenablage zwischen Host und Gast.
- Für Dateifreigabe werden je nach Gastbetriebssystem mehrere Verfahren unterstützt.
- VirtIO-webdavd: Dateifreigabe für Linux- und Windows-Gäste
- VirtIO-9p: Dateifreigabe für Linux- und macOS-Gäste
- Samba: Dateifreigabe für Linux-, macOS- und Windows-Gäste; auf dem Host muss
smbd installiert sein
- Der QEMU Guest Agent wird unterstützt, sodass per Standard-QMP-Befehl auf den System-Level-Agent zugegriffen werden kann.
- Bei Grafik- und Gerätefunktionen werden VirGL-Beschleunigung, USB-Geräte-Passthrough und Smartcard-Passthrough unterstützt.
- Auch Netzwerk- und I/O-Funktionen sind enthalten:
- automatisches SSH-Port-Forwarding zum Gast
- Netzwerk-Port-Forwarding
- Vollduplex-Audio
- Braille-Unterstützung
- EFI-Boot mit oder ohne SecureBoot
- Legacy-BIOS-Boot
Schneller Startablauf
- Nach der Installation von Quickemu wird die VM in zwei Schritten erstellt und gestartet.
- Mit
quickget wird das ISO-Image heruntergeladen und die VM-Konfigurationsdatei erzeugt.
quickget nixos unstable minimal
- Mit
quickemu wird die VM anhand der von quickget erzeugten Konfigurationsdatei gestartet.
quickemu --vm nixos-unstable-minimal.conf
- Wird
quickget ohne Argumente ausgeführt, lässt sich die Liste aller unterstützten Betriebssysteme anzeigen.
Dokumentation und Referenzmaterial
- Das Wiki behandelt den Einstieg sowie erweiterte Konfiguration und Nutzung.
1 Kommentare
Meinungen auf Hacker News
Früher habe ich es ständig genutzt, als ich viele verschiedene VM-Hosts und lokale VMs verwaltet habe.
Man sollte die grundlegenden Begriffe rund um VMs einigermaßen kennen, aber es erinnert sehr an eine alte GUI, die randvoll mit Funktionen und Power ist.
Wenn der Bedarf simpel ist oder man mit VMs weniger vertraut ist, bietet Gnome Boxes mit demselben Backend eine aufgeräumte GUI. Durch die Einfachheit ist es weniger flexibel, aber gut ist, dass man eine Gnome-Boxes-VM später in virt-manager öffnen kann, wenn man Einstellungen anpassen muss, die in Boxes nicht sichtbar sind.
Wenn man es per SSH auf einem entfernten System ausführt, wird die QEMU-Konsole in die lokale Wayland-Sitzung von Fedora „per X-Forwarding“ weitergereicht.
Ich dachte zunächst, es laufe im Headless-Modus, war dann aber ziemlich überrascht, als ein Fenster aufging :)
Das bringt einen dazu, sich vorzustellen, wie es wäre, wenn die Konfiguration von der Software getrennt wäre, die konfiguriert wird. Statt zu lernen, wie jedes UI-Programm das Rad neu erfunden hat, könnte man einfach den bevorzugten Konfigurationsmanager auswählen.
Am nächsten dran sind derzeit Text-Konfigurationsdateien. Jedes Programm, das sie nutzt, muss eine bestimmte Sprache und einen Speicherort wählen.
Eine Idee, über die ich in letzter Zeit viel nachdenke, ist eine Vermittlungsschicht für Konfiguration. Die für Nutzer sichtbare Konfigurations-UI könnte die gewünschte Sprache bzw. das gewünschte Format verwenden, und diese Daten würden als Single Source of Truth dienen, aus der die Konfigurationsdateien erzeugt werden, die die Software dann liest.
Es gibt auch nützliche Verwaltungsfunktionen wie Start/Stopp auf Basis von Konfigurationsdateien oder Zugriff auf die serielle Konsole, aber so etwas lässt sich mit Shell-Skripten auch sehr einfach selbst umsetzen. Die Storage-Verarbeitung von libvirt ist furchtbar wortreich und komplex, kann aber trotzdem weder thin LVs noch ZFS vernünftig handhaben.
Wenn man es nicht auf die standardmäßige Enterprise-Art betreiben will und keine Lust hat, Basissoftware wie QEMU oder die Shell zu lernen, oder wenn man nicht zwingend irgendeine halbgare libvirt-Funktion braucht, würde ich empfehlen, QEMU direkt auf KVM zu verwenden und eigene Skripte zu nutzen. Man lernt mehr über QEMU als über einen schlechten Python-Wrapper und hat mehr Kontrolle über das System.
Außerdem scheint IBM/Red Hat virt-manager praktisch aufgegeben zu haben, während sie in Richtung der neuen Weboberfläche Copilot drängen.
Quickemu ist interessanter, weil man keine große, komplexe UI lernen muss, sondern nach kurzem Blick auf Beispiele sofort eine neue VM starten kann.
Dieses Tool lädt beliebige Dateien aus dem Internet herunter und vergleicht deren Prüfsummen dann mit einer anderen beliebigen Datei aus dem Internet[2].
Das ist nicht gerade Best Practice in Sachen Sicherheit. Der korrekte Weg wäre, die GPG-Keys der Distributionsentwickler ins Repository zu committen und alle Dateien mit diesen Keys zu verifizieren.
Damit will ich nicht die Arbeit dieses Projekts schmälern, die richtigen Flags zu finden, die man QEMU übergeben muss, um viele Betriebssysteme zu booten.
[1] https://news.ycombinator.com/item?id=28797129
[2] https://github.com/quickemu-project/quickemu/blob/0c8e1a5205...
Zusätzlich wird sogar noch ein Hash-Abgleich durchgeführt, was die meisten nicht machen.
Zu FTP-Zeiten waren Prüfsummen und GPG unverzichtbar. Bei HTTP/TCP übernimmt TCP Retries und Prüfsummen, wodurch GPG noch wichtiger wird, aber wegen Man-in-the-Middle-Angriffen war beides weiterhin nötig.
Aber warum ist das bei HTTPS immer noch wichtig? Ersetzt HTTPS nicht beide Prüfungen sowie die Signaturprüfung?
Ich hoffe, dass das Interesse auf Hacker News in diesem Jahr jemanden dazu motiviert, Signaturprüfung für Linux zu implementieren.
0. https://mac.getutm.app/
https://docs.getutm.app/installation/ios/
Ein aktuelles Beispiel für Alma Linux sieht so aus:
$ virt-install --name alma9 --memory 1536 --vcpus 1 --disk path=$PWD/alma9.img,size=20 --cdrom alma9.iso --unattendedWenn man sich einen Kaffee holt und zurückkommt, läuft eine fertig installierte Alma-Linux-VM. Die Liste der unterstützten OS hängt von der libvirt-Version ab; prüfen kann man sie so
$ osinfo-query osWenn man ein Fedora-39-Disk-Image braucht, gibt es auch virt-builder
$ virt-builder fedora-39Es lässt sich später mit
virt-install --importin libvirt importierenLädt virt-install die ISO automatisch herunter? Beim Versuch erscheint diese Meldung
$ virt-install --name alma9 --memory 1536 --vcpus 1 --disk path=$PWD/alma9.img,size=20 --cdrom alma9.iso --unattendedERROR Validating install media 'alma9.iso' failed: Must specify storage creation parameters for non-existent path '/home/foo/alma9.iso'.Es ist nicht klar, wie das Ergebnis aussehen wird. Interessant wäre etwa, wie der Hostname lautet, wie die Disk partitioniert wird, welche Pakete installiert werden und welche Zeitzone sowie welches Tastaturlayout gesetzt werden
Dafür musste ich libosinfo-bin installieren
Der Komfort solcher Tools ist großartig, aber die beiden wichtigsten Skripte zusammen umfassen etwa 5000 Zeilen Bash
Ich würde sie vor dem Ausführen gern prüfen, aber 5000 Zeilen Bash möchte ich nicht lesen
Keine Ahnung, ob das überzeugt, aber ich habe das Bash-Skript vor dem Ausführen gelesen und es war ziemlich gut strukturiert. Die Funktionalität ist sauber in Funktionen aufgeteilt, die Variablennamen sind vernünftig, es gibt hilfreiche Kommentare, keinen seltsamen Kontrollfluss oder indirekte Aufrufe, und der Einsatz schwer verständlicher Befehle ist minimal. Es gehört zu den am besten lesbaren Shell-Skripten, die ich bisher gesehen habe
Wenn man bedenkt, was dieses Skript tatsächlich tut, ergibt es auch Sinn, dass der Code relativ geradlinig ist. Im Kern wird ein Befehl ausgeführt, der QEMU startet. Der restliche Code prüft das lokale System, um festzulegen, welche Argumente diesem Befehl übergeben werden, oder lädt bei Bedarf ein paar Dateien herunter
Das heißt nicht, dass man blind alles ausführen sollte, aber unsere Kriterien dafür, welche Software wir ausführen, hängen normalerweise nicht davon ab, ob wir mit dem Quellcode vertraut sind
“You are a linux guru, and you have extensive experience with bash and all forms of unix/linux. I am going to be pasting a large amount of code in a little bit at a time. Every time I paste code and send it to you, you are going to add it to the previous code and ask me if I am done. When I am done we are going to talk about the code, and you are going to help me break it down and understand what is going on. If you understand you will ask me to start sending code, otherwise ask me any questions before you ask for the code.”
Ich habe diese Methode bei kürzerem Code ausprobiert, der trotzdem unter 1000 Zeilen lag und das Prompt-Limit sprengte, und sie funktionierte ziemlich gut. Ich gebe zu, dass ChatGPT heutzutage fauler geworden ist, und manchmal muss man ausdrücklich sagen, dass es nicht faul sein und die komplette gewünschte Ausgabe liefern soll, aber insgesamt erklärt es Code ziemlich gut
Der Satz „Given enough eyeballs, all bugs are shallow“ wirkt auf manche Nutzer wie ein Klischee, das das Denken beendet. Man nimmt an, es sei in Ordnung, weil der Code öffentlich und überprüfbar ist, und stellt sich eine Schar von Code-Auditoren vor, die alles prüfen; tatsächlich würde ich aber eher mit bösen als mit guten Absichten rechnen
Unter Windows gibt es seit Jahrzehnten ununterbrochen Tuning-Utilities. Sie ziehen Leute an, die glauben, dass Entwickler bei „großen Unternehmen“ keinen Anreiz haben, die Systemleistung voll auszureizen, und dass sich hinter schnellen Einstellungen oder Registry-Tweaks einfache Optionen verbergen, die für alle nützlich wären. Mir fällt das gelegentlich erwähnte TronScript ein: Aufgrund seiner Historie und Beteiligung würde es den Geruchstest wohl bestehen, was gut ist, aber unter dem Namen Automatisierung verbirgt es Details und lässt Nutzer erwarten, dass es in ihrem Namen gute Entscheidungen trifft. Man kann sich hineingraben, untersuchen und lernen, was passiert und warum, aber für viele ist es faktisch nicht anders als ein Binary
Der beruhigende Punkt ist, dass die meisten dieser Tools nur eine begrenzte Nutzerbasis haben und sich eine Kompromittierung daher kaum lohnt. Wenn eine bestimmte Marke breit genug genutzt wird, kann etwas wie bei Piriforms CCleaner passieren, in den 2017 eine Backdoor eingeschleust wurde
Sieht interessant aus; kann mir jemand erklären, welche Vorteile das für jemanden hat, der unter Ubuntu gelegentlich nur Windows 11 in VirtualBox laufen lässt?
Unter Linux kann ich Incus/LXD sehr empfehlen. Eine VM zu starten ist so einfach
Danach erhält man Shell-Zugriff so
Incus/LXD unterstützt auch System-Container
Was ich mag, worüber aber kaum gesprochen wird, ist systemd-nspawn. Man führt
docker create --name ubuntu ubuntu:22.04aus und erstellt mitdocker export ubuntuaus einem beliebigen Docker-Image ein Tar-Archiv.Dieses entpackt man dann nach
/var/lib/machines/ubuntu. Man muss ein Image wählen, das systemd enthält, oder systemd im Container installieren. Zum Schluss startet man es mitmachinectl start ubuntuund gelangt mitmachinectl shell ubuntuhinein.systemd-nspawn ist sehr einfach und leichtgewichtig und emuliert eine echte Linux-Maschine sehr gut. Wenn man eine beliebige systemd-basierte Root-Partition nimmt und sie mit systemd-nspawn bootet, funktioniert sie einfach so.
Gibt es Leistungskennzahlen im Vergleich dazu, eine VM einfach so auszuführen? Normalerweise lasse ich Linux-Gäste auf einem Linux-Host laufen und bin oft von der Guest-Performance enttäuscht.
Ich habe mich nie damit beschäftigt, das VM-Erlebnis zu tunen, daher frage ich mich, wie viel ich verpasse. Ist es 5 % schneller? 100 %?
Läuft es nativ auf Arm, also Apple Silicon? Wie sieht es mit den neuesten macOS-Versionen aus? Gibt es Grafikbeschleunigung? Wie wird das Netzwerk gehandhabt?
Ich frage mich, worin es sich von Proxmox unterscheidet und ob ich die Optimierungen von hier manuell in meiner Proxmox-Umgebung nachbilden kann.
Quickemu scheint hauptsächlich auf Desktop-Nutzung ausgerichtet zu sein.