QEMU/KVM unter Linux Mint 22.x – Vollständige Anleitung

Eine praxisorientierte Anleitung zur Einrichtung von QEMU/KVM mit virt-manager als grafisches Frontend, optimiert für Windows 10/11 als Gastsystem. Inklusive wachsender qcow2-Laufwerke, virtio-Gasttreibern und Verzeichnisfreigaben aus dem Linux-Host an den Windows-Gast.

0. Option: VirtualBox verabschieden

Falls du VirtualBox bereits installiert hast und dich wunderst, warum KVM nicht will: herzlich willkommen im Club der „habe-mal-irgendwo-gelesen-dass-man-KVM-abschalten-muss"-Geschädigten. Die beiden Hypervisoren vertragen sich ungefähr so gut wie zwei Katzen in einem Karton – theoretisch möglich, praktisch nervig.

Dieser Abschnitt ist optional. Wenn du VirtualBox behalten möchtest (oder nie hattest), spring direkt zu Abschnitt 1. Wenn du aber den Umstieg ernst meinst und keine Lust auf Gebastel mit duellierenden Kernel-Modulen hast, lies weiter.

0.1 Bestandsaufnahme: Was hat VirtualBox eigentlich angerichtet?

VirtualBox und KVM kämpfen beide um exklusiven Zugriff auf die CPU-Virtualisierungserweiterungen. Früher bedeutete das: Entweder VirtualBox oder KVM – Schluss, aus, Feierabend. Seit VirtualBox 6.1 kann VirtualBox theoretisch über KVM laufen, aber in der Praxis führt das oft zu kreativ formulierten Fehlermeldungen und nächtlichen Debugging-Sessions.

Typische Nebenwirkungen einer VirtualBox-Installation:

• KVM-Module wurden blacklistet, weil ein Tutorial aus dem Jahr 2014 das empfohlen hat.
• Der vboxdrv-Service läuft im Hintergrund und hält die Virtualisierung exklusiv besetzt, auch wenn gerade keine VM läuft.
• Kernel-Parameter wurden verbogen, z. B. nested=0 für kvm_intel.
• DKMS-Module im Secure-Boot-Konflikt – VirtualBox baut bei jedem Kernel-Update neue Module, die dann von Secure Boot abgelehnt werden, was dich irgendwann dazu bringt, irgendwelche MOK-Keys zu signieren, von denen du nicht mal weißt, wofür die gut sind.

Klingt nach Spaß? Dann lies weiter.

0.2 Schritt 1: VirtualBox-VMs exportieren (falls du sie behalten willst)

Bevor du VirtualBox vom System wirfst, solltest du bestehende VMs sichern – falls du sie später in QEMU/KVM weiterverwenden möchtest. Das geht über den VirtualBox-Export oder manuell über die .vdi-Dateien.

Export über VirtualBox-GUI

1. VirtualBox starten.
2. VM auswählen → Datei → Appliance exportieren.
3. Format OVF 2.0 wählen, Zielverzeichnis festlegen, fertig.

Die .ova-Datei kann später in virt-manager importiert werden (mit etwas Handarbeit, weil die virtio-Treiber fehlen werden – aber das ist ein anderes Thema).

Manuelle Sicherung der Disk-Images

VirtualBox legt seine .vdi-Dateien normalerweise unter ~/VirtualBox VMs/ ab. Einfach kopieren:

cp -r ~/VirtualBox\ VMs/ ~/vbox-backup/

Die .vdi-Dateien lassen sich mit qemu-img nach qcow2 konvertieren:

qemu-img convert -p -O qcow2 ~/vbox-backup/MeineVM/MeineVM.vdi /var/lib/libvirt/images/MeineVM.qcow2

Damit hast du die Disk gesichert. Der Rest (Netzwerk, USB-Passthrough, Shared Folders) muss in virt-manager neu konfiguriert werden – aber du verlierst wenigstens nicht das installierte System.

0.3 Schritt 2: VirtualBox komplett deinstallieren

Jetzt wird's ernst. Alle laufenden VMs schließen, dann:

sudo apt remove --purge virtualbox virtualbox-* virtualbox-dkms virtualbox-ext-pack
sudo apt autoremove

Der --purge-Schalter löscht auch die Konfigurationsdateien. autoremove räumt verwaiste Abhängigkeiten auf, die nur für VirtualBox installiert wurden.

Falls du VirtualBox aus dem offiziellen Oracle-Repository installiert hattest (statt aus den Mint-Quellen), taucht es bei apt list --installed | grep virtualbox evtl. mit anderen Paketnamen auf. Dann zusätzlich:

sudo apt remove --purge virtualbox-7.0   # oder welche Version auch immer

0.4 Schritt 3: Aufräumen der hinterlassenen Spuren

VirtualBox hinterlässt gerne ein paar Andenken im System. Zeit für die Spurenbeseitigung.

a) Kernel-Module-Blacklist prüfen

grep -r "kvm" /etc/modprobe.d/ 2>/dev/null

Wenn dort Zeilen wie blacklist kvm, blacklist kvm_intel oder blacklist kvm_amd auftauchen, hat irgendein Tutorial aus der Steinzeit des Internets empfohlen, KVM abzuschalten. Kommentiere die Zeilen aus oder lösche die Datei:

sudo nano /etc/modprobe.d/blacklist-kvm.conf

Zeilen mit # auskommentieren oder die ganze Datei löschen:

sudo rm /etc/modprobe.d/blacklist-kvm.conf

Anschließend initramfs neu bauen, damit die Änderung beim nächsten Boot greift:

sudo update-initramfs -u

b) VirtualBox-Kernel-Module entfernen

Falls noch DKMS-Reste von VirtualBox herumliegen:

sudo dkms status | grep vbox

Wenn etwas auftaucht, mit voller Versions-Angabe entfernen:

sudo dkms remove vboxhost/7.0.12 --all   # Versionsnummer anpassen

c) Übrig gebliebene Dienste stoppen

Falls der vboxdrv-Service noch irgendwo läuft:

sudo systemctl stop vboxdrv 2>/dev/null
sudo systemctl disable vboxdrv 2>/dev/null

Die 2>/dev/null fangen Fehlermeldungen ab, falls der Dienst schon weg ist – elegant ist das nicht, aber funktional.

d) Benutzergruppe vboxusers aufräumen

Dein User war vermutlich Mitglied der Gruppe vboxusers. Die Gruppe selbst bleibt beim Deinstallieren oft bestehen und macht nichts kaputt, aber wenn dich das stört:

sudo delgroup vboxusers

Falls die Gruppe nicht existiert, kommt eine harmlose Fehlermeldung – ignorieren.

0.5 Schritt 4: KVM-Module reaktivieren

Jetzt, da VirtualBox weg ist, können die KVM-Module endlich wieder ans Tageslicht.

sudo modprobe kvm
sudo modprobe kvm_intel    # bei Intel-CPU
# ODER
sudo modprobe kvm_amd      # bei AMD-CPU

Wenn das mit Operation not permitted fehlschlägt, liegt's meist an Secure Boot (siehe nächster Abschnitt). Ansonsten prüfen, ob die Module geladen sind:

lsmod | grep kvm

Sollte kvm plus kvm_intel oder kvm_amd zeigen. Wenn ja: Glückwunsch, KVM lebt. Wenn nein: weiterlesen.

Nested Virtualization reaktivieren (falls abgeschaltet)

Manche VirtualBox-Anleitungen empfehlen, nested KVM zu deaktivieren. Prüfen:

cat /sys/module/kvm_intel/parameters/nested

Y oder 1 = aktiv, N oder 0 = aus. Wieder einschalten (Intel):

echo "options kvm_intel nested=1" | sudo tee /etc/modprobe.d/kvm.conf
sudo modprobe -r kvm_intel
sudo modprobe kvm_intel

Bei AMD entsprechend kvm_amd statt kvm_intel.

0.6 Schritt 5: Secure Boot und MOK-Keys (der Endgegner)

Wenn du Secure Boot aktiv hast und VirtualBox seine eigenen DKMS-Module signiert hatte, kann es sein, dass jetzt ein selbst erzeugter MOK-Key im System herumgeistert, der KVM blockiert. Prüfen:

mokutil --sb-state

Wenn SecureBoot enabled und gleichzeitig dmesg | grep -i "key was rejected" Treffer liefert, gibt es zwei Lösungen:

Option A: Secure Boot im UEFI deaktivieren (einfach, aber unelegant)

Ins BIOS/UEFI booten, Secure Boot ausschalten, fertig. Die KVM-Module aus dem Mint-Kernel sind offiziell signiert und funktionieren dann problemlos.

Option B: MOK-Key entfernen (eleganter, aber fummeliger)

Liste der installierten MOK-Keys anzeigen:

mokutil --list-enrolled

Wenn dort ein Key mit VirtualBox-Bezug auftaucht, kannst du ihn entfernen – aber Vorsicht, nicht den Shim-Key oder den Microsoft-Key löschen, sonst bootet das System nicht mehr. Im Zweifel: Option A wählen.

0.7 Funktionstest

Nach all dem Aufräumen:

kvm-ok

Sollte mit KVM acceleration can be used antworten. Dann weiter zu Abschnitt 1 – die eigentliche QEMU/KVM-Installation steht noch bevor.

Falls kvm-ok immer noch meckert: dmesg | grep -i kvm liefert meist den entscheidenden Hinweis, wo es noch klemmt.

1. Voraussetzungen prüfen

Bevor du Pakete installierst, sollte sichergestellt sein, dass die CPU Virtualisierung unterstützt und diese im BIOS/UEFI aktiv ist (Intel VT-x bzw. AMD-V).

egrep -c '(vmx|svm)' /proc/cpuinfo

Gibt einen Wert > 0 zurück, wenn Hardware-Virtualisierung verfügbar ist. vmx steht für Intel, svm für AMD.

kvm-ok

Liefert eine Klartext-Ausgabe, ob KVM nutzbar ist. Das Tool stammt aus dem Paket cpu-checker und wird im nächsten Schritt mitinstalliert. Wenn das Kommando jetzt noch fehlt, ist das in Ordnung – einfach nach der Installation erneut ausführen.

lsmod | grep kvm

Zeigt die geladenen KVM-Kernelmodule (kvm, kvm_intel oder kvm_amd). Sind sie nicht geladen, ist die Virtualisierung im BIOS/UEFI deaktiviert.

2. Installation der Pakete

Linux Mint 22.x basiert auf Ubuntu 24.04 LTS, alle benötigten Pakete sind in den Standard-Quellen vorhanden.

sudo apt update
sudo apt install -y qemu-system-x86 qemu-utils libvirt-daemon-system libvirt-clients \
                    bridge-utils virt-manager ovmf cpu-checker virtiofsd

Kurzbeschreibung der Pakete:

• qemu-system-x86 – der eigentliche Emulator/Hypervisor für x86-Gäste.
• qemu-utils – Werkzeuge wie qemu-img zum Erzeugen und Konvertieren von Disk-Images.
• libvirt-daemon-system – der libvirtd-Dienst, der VMs verwaltet (Konfiguration, Netzwerk, Storage).
• libvirt-clients – Kommandozeilen-Werkzeuge wie virsh.
• bridge-utils – Hilfsprogramme für Netzwerkbrücken (für Bridged Networking, falls später benötigt).
• virt-manager – die grafische Verwaltungsoberfläche.
• ovmf – UEFI-Firmware (für moderne Windows-11-Gäste mit Secure Boot zwingend nötig).
• cpu-checker – stellt kvm-ok bereit.
• virtiofsd – Daemon für virtiofs-Verzeichnisfreigaben (wird in Abschnitt 8 verwendet).

3. Dienste, Gruppen und erster Start

Damit dein Benutzer ohne sudo mit libvirt arbeiten kann, muss er den passenden Gruppen angehören.

sudo systemctl enable --now libvirtd

Aktiviert den libvirtd-Dienst dauerhaft und startet ihn sofort.

sudo usermod -aG libvirt,kvm $USER

Fügt den aktuellen Benutzer den Gruppen libvirt (Verwaltung von VMs) und kvm (Zugriff auf /dev/kvm) hinzu. Anschließend einmal komplett ab- und wieder anmelden, sonst greifen die Gruppenrechte nicht.

virsh list --all

Schneller Funktionstest. Wenn statt einer Fehlermeldung eine (leere) Tabelle erscheint, ist alles bereit. Danach virt-manager aus dem Menü starten oder im Terminal aufrufen:

virt-manager

4. Wachsende Laufwerke (qcow2)

QEMU unterstützt mit dem Format qcow2 sparse, mitwachsende Disk-Images: das Image wird mit einer maximalen virtuellen Größe angelegt, belegt auf der Host-Festplatte aber nur den tatsächlich genutzten Speicherplatz. Dazu kommen Snapshots, optionale Kompression und Verschlüsselung.

4.1 Neues qcow2-Image manuell erzeugen

qemu-img create -f qcow2 -o preallocation=off,cluster_size=65536 \
    /var/lib/libvirt/images/win11.qcow2 100G

Erklärung:

• -f qcow2 – Format qcow2.
• -o preallocation=off – keine Vorabreservierung, das Image wächst bei Bedarf. Das ist die Default-Einstellung; explizit gesetzt zur Klarheit.
• cluster_size=65536 – 64 KiB Cluster, ein guter Kompromiss aus Performance und Fragmentierung für Windows-Gäste.
• 100G – maximale virtuelle Größe. Tatsächlich belegt das Image direkt nach dem Anlegen nur wenige hundert KiB.

Status prüfen:

qemu-img info /var/lib/libvirt/images/win11.qcow2

Zeigt unter anderem virtual size (logische Größe) und disk size (real belegt) – der Unterschied ist genau das „wachsende“ Verhalten.

4.2 In virt-manager beim VM-Erstellungsassistenten

Beim Anlegen einer neuen VM im virt-manager wird im Schritt „Speicher zuweisen“ standardmäßig ein qcow2-Image im Storage-Pool default (/var/lib/libvirt/images/) erzeugt. Das Häkchen „Speicherplatz für virtuelle Festplatte jetzt zuweisen“ nicht setzen – nur dann ist das Image wirklich sparse. Mit Häkchen wird der volle Platz beim Anlegen reserviert (preallocation=metadata bzw. falloc), und der Vorteil eines wachsenden Laufwerks geht verloren.

4.3 Image vergrößern

Reicht der virtuelle Platz im Gast nicht mehr, lässt sich qcow2 nachträglich aufblasen. VM vorher herunterfahren.

qemu-img resize /var/lib/libvirt/images/win11.qcow2 +50G

Hängt 50 GiB an die virtuelle Größe an. Innerhalb des Windows-Gasts muss anschließend die Partition über die Datenträgerverwaltung (diskmgmt.msc) erweitert werden.

5. Bestehende Disk auf qcow2 umstellen

Falls schon eine VM existiert, deren Laufwerk im Format raw oder als feste Allokation vorliegt, lässt sich das mit Bordmitteln auf ein wachsendes qcow2 umstellen.

5.1 Sicherung anlegen

cp /var/lib/libvirt/images/altes_image.img /var/lib/libvirt/images/altes_image.img.bak

Erst kopieren, dann konvertieren – falls etwas schiefgeht, ist das Original noch da.

5.2 Konvertieren

qemu-img convert -p -O qcow2 -o cluster_size=65536 \
    /var/lib/libvirt/images/altes_image.img \
    /var/lib/libvirt/images/altes_image.qcow2

Erklärung:

• -p – zeigt einen Fortschrittsbalken.
• -O qcow2 – Zielformat.
• -o cluster_size=65536 – passende Cluster-Größe für Windows.

Da qemu-img convert standardmäßig nur tatsächlich belegte Sektoren schreibt, wird das Ergebnis automatisch sparse, auch wenn das Quellbild voll alloziert war.

5.3 VM-Konfiguration anpassen

Im virt-manager: VM öffnen → „Anzeigen → Details“ → linke Liste, Eintrag der Festplatte auswählen → unter „Quellpfad“ das neue .qcow2 eintragen und unter „Erweiterte Optionen → Disk-Bus“ ggf. auf virtio umstellen (siehe Abschnitt 7). Mit „Übernehmen“ speichern.

Alternativ direkt in der XML editieren:

virsh edit name-der-vm

Im <disk>-Block type='file', <driver name='qemu' type='qcow2'/> und den neuen <source file='…qcow2'/> setzen. virsh edit validiert die XML beim Speichern.

5.4 Aufräumen

Erst nach erfolgreichem Bootvorgang der VM mit dem neuen Image die alte Datei löschen:

rm /var/lib/libvirt/images/altes_image.img
rm /var/lib/libvirt/images/altes_image.img.bak

6. Windows 10/11 in der VM installieren

Kurzfassung der wichtigsten Einstellungen, weil Windows 11 ein paar Eigenheiten hat.

1. Windows-ISO und das aktuelle virtio-win.iso bereitlegen. Letzteres von Fedora/Red Hat, Direktlink: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso.
2. In virt-manager „Neue virtuelle Maschine erstellen“ → lokale ISO → Windows-ISO auswählen.
3. RAM/CPU nach Bedarf, für Windows 11 mindestens 4 GiB RAM und 2 vCPUs.
4. Disk wie in Abschnitt 4.2 als wachsendes qcow2.
5. Im letzten Schritt „Konfiguration vor der Installation anpassen“ anhaken.
6. In der Detailansicht:
   • Übersicht → Firmware: UEFI x86_64: …OVMF_CODE_4M.fd (Pflicht für Windows 11).
   • CPUs: Modell host-passthrough für maximale Performance.
   • SATA Disk 1 → Disk-Bus: VirtIO (während der Installation muss dafür der Treiber von der virtio-ISO geladen werden – siehe nächster Abschnitt).
   • NIC: Gerätemodell virtio.
   • Hinzufügen → Speicher → zweites CD-ROM-Laufwerk mit virtio-win.iso.
   • Für Windows 11: Hinzufügen → TPM → Modell TPM 2.0, Backend Emulated.
7. Installation starten. Wenn Windows nach der Festplatte fragt, „Treiber laden“ wählen, vom virtio-Laufwerk den Pfad amd64\w11\ (bzw. w10) auswählen und den viostor-Treiber laden – erst dann sieht Windows die virtio-Disk.

7. Gasterweiterungen / virtio-Treiber

Anders als bei VirtualBox gibt es bei QEMU/KVM keine einzelne „Gasterweiterung“ – die entsprechenden Funktionen verteilen sich auf zwei Komponenten, beide auf der virtio-win.iso.

7.1 virtio-Treiber via Installer

Im laufenden Windows-Gast die virtio-ISO im zweiten CD-ROM-Laufwerk öffnen und virtio-win-gt-x64.msi ausführen. Der Installer richtet alle Standard-Treiber ein: Storage (viostor), Netzwerk (NetKVM), Balloon-Speicher, Serial, Input. Anschließend Neustart.

7.2 QEMU Guest Agent

Der Guest Agent erlaubt dem Host, mit dem Gast zu kommunizieren – sauberes Herunterfahren, Dateisystem einfrieren bei Snapshots, IP-Adressen abfragen, Zeitsynchronisation.

Auf der virtio-ISO im Verzeichnis guest-agent\ die Datei qemu-ga-x86_64.msi installieren.

Damit der Host den Agent auch ansprechen kann, muss in virt-manager unter VM-Details → Hinzufügen → Channel ein Kanal mit Name org.qemu.guest_agent.0 und Gerät unix socket existieren. Bei in virt-manager neu angelegten VMs ist das standardmäßig der Fall.

7.3 SPICE-Tools (Zwischenablage, dynamische Auflösung)

Für Drag & Drop sowie geteilte Zwischenablage zwischen Host und Windows-Gast zusätzlich spice-guest-tools installieren. Die ausführbare Datei wird nicht von Red Hat, sondern von SPICE selbst angeboten:

https://www.spice-space.org/download/windows/spice-guest-tools/spice-guest-tools-latest.exe

Im Gast als Administrator ausführen, Neustart. Damit funktionieren auch automatische Auflösungswechsel, wenn das virt-manager-Fenster vergrößert wird.

8. Linux-Verzeichnis im Windows-Gast bereitstellen

Empfohlen ist virtiofs – schneller und mit besserer Semantik als die ältere 9p-Variante. Voraussetzung sind die in Abschnitt 2 installierten Pakete und die SPICE/virtio-Tools im Gast.

8.1 Vorbereitung im Host

Verzeichnis anlegen, das später freigegeben wird:

mkdir -p /home/$USER/vm-share

8.2 Filesystem-Eintrag in virt-manager

VM herunterfahren. In den VM-Details:

1. Hinzufügen → Filesystem.
2. Treiber: virtiofs.
3. Quellpfad: /home/<benutzername>/vm-share (absoluter Pfad auf dem Host).
4. Zielpfad / Tag: z. B. vmshare – das ist der Name, unter dem der Gast die Freigabe sieht.
5. Speichern.

8.3 Shared Memory aktivieren

virtiofs benötigt im VM-XML aktiviertes Memory-Backing. virt-manager fragt das in modernen Versionen automatisch ab und ergänzt es. Falls nicht, in VM-Details → Speicher → Erweiterte Optionen den Punkt „Speicher mit dem Host teilen“ (Shared Memory) aktivieren. Alternativ in der XML manuell:

<memoryBacking>
  <source type='memfd'/>
  <access mode='shared'/>
</memoryBacking>

Ohne diese Einstellung startet die VM mit virtiofs-Eintrag nicht.

8.4 Gast-seitig: WinFsp + virtiofs-Dienst

Im Windows-Gast:

1. WinFsp installieren (von https://winfsp.dev/) – stellt die FUSE-ähnliche Schnittstelle für Windows bereit.
2. Die virtio-Treiber aus Abschnitt 7.1 müssen installiert sein, sie enthalten den VirtIO-FS Service.
3. services.msc öffnen, den Dienst „VirtIO-FS Service“ auf Automatisch stellen und starten.

Nach dem Start erscheint die Freigabe als zusätzlicher Laufwerksbuchstabe (üblicherweise Z:) im Explorer. Der Inhalt entspricht 1:1 dem Linux-Verzeichnis /home/<benutzername>/vm-share. Berechtigungen werden auf den User abgebildet, unter dem der virtiofsd läuft – Lese-/Schreibrechte daher im Host korrekt setzen.

8.5 Test

Im Linux-Host eine Datei im freigegebenen Verzeichnis ablegen:

echo "Hallo aus dem Host" > /home/$USER/vm-share/test.txt

Im Windows-Gast unter Z:\test.txt öffnen – Inhalt sollte sofort sichtbar sein. Umgekehrt landen Dateien, die im Gast in Z: gespeichert werden, direkt im Host-Verzeichnis.

9. Anhang: Nützliche Befehle

Übersicht über installierte VMs und ihren Zustand:

virsh list --all

VM starten / sauber herunterfahren / hart abschalten:

virsh start name-der-vm
virsh shutdown name-der-vm
virsh destroy name-der-vm

destroy zieht VM-seitig „den Stecker“ – nur bei hängenden Gästen verwenden.

Snapshot eines qcow2-Images (interner Snapshot, VM kann laufen):

virsh snapshot-create-as --domain name-der-vm --name vor-update --description "Vor Windows-Update"

Liste der Snapshots:

virsh snapshot-list name-der-vm

Image-Informationen / Belegung prüfen:

qemu-img info /var/lib/libvirt/images/win11.qcow2

Disk auf tatsächlich belegte Sektoren reduzieren (Sparse-Status wiederherstellen, VM aus):

qemu-img convert -O qcow2 win11.qcow2 win11-trim.qcow2 && mv win11-trim.qcow2 win11.qcow2

Damit ist das Setup vollständig: QEMU/KVM mit virt-manager, wachsende qcow2-Disks, virtio-Treiber, Guest Agent, SPICE-Integration und ein durchgereichtes Linux-Verzeichnis im Windows-Gast.