QEMU/KVM mit GPU Passthrough

Wiki ‹ weitere Dienste ‹ QEMU/KVM mit GPU Passthrough

Getestet: Dieser Hinweis soll dir dabei helfen, zu entscheiden, ob dieser Artikel auf deinem System funktionieren wird oder nicht. Solltest du feststellen, dass dieser Artikel bei einer ungetestet Version funktioniert, kannst du das gerne hier korrigieren oder im Forum anmerken.

Dieser Artikel wurde für Debian Stretch 9.0 getestet.
Dieser Artikel wurde für Debian Buster 10.0 getestet.
Dieser Artikel wurde für Debian Bullseye 11.0 getestet.

Hinweis: Dieser Artikel wurde auch mit Debian Bookworm getestet (Stand Oktober 2021)

Dieser Artikel wurde mit folgenden Gast Betriebssystemen getestet:

Windows 7
Windows 10

Dieser Artikel erläutert, wie man eine zusätzliche Grafikkarte an eine QEMU/KVM VM (Virtuelle Maschine) weiter reichen kann. Dadurch kann die VM die dedizierte Grafikkarte (mit nur kleinen Performance Verlusten) direkt ansprechen und somit können Grafik intensive Anwendungen in der VM genutzt werden. Beispielsweise kann eine Windows VM für Gaming unter GNU/Linux genutzt werden.

QEMU Logo

KVM Logo

Einführung

QEMU/KVM

Bei QEMU handelt es sich um eine verbreitete Virtualisierungslösung, wie z.B. auch Virtualbox, XEN oder VMWare. Bei KVM handelt es sich um eine Kernel Erweiterung, die seit Version 2.6.20 fester Bestandteil des Linux Kernels ist. Dadurch können die Hardware Virtualisierungstechniken VT (Intel) oder AMD-V (AMD) genutzt werden, was bei x86/x64 Gastsystemen (auf einem x86/x64 Host) zu Leistungssteigerungen führt.

Voraussetzungen

Hardware Virtualisierungstechniken

Damit eine Grafikkarte an eine VM weitergereicht werden kann, muss die CPU und das Mainboard die folgenden Techniken unterstützen und diese müssen per UEFI/Bios aktiviert werden:

bei Intel: sowohl Vt-x als auch Vt-d (IOMMU)
bei AMD: AMD-V (kann auch SVM genannt werden) und AMD-Vi (IOMMU)

Bei Intel Xeon und bei den meisten AMD Prozessoren sollte zusätzlich beachtet werden, dass viele keinen integrierten Grafikchip besitzen, so dass hier eine zweite dedizierte Grafikkarte nötig wird.

Stand 2021 sollten alle gängigen Mainboards und CPUs, mindestens der letzten 5 Jahre, IOMMU unterstützen.

Bei älterer Hardware sollte man sehr genau prüfen, ob sowohl die CPU, als auch das Mainboard/Chipsatz Vt-d unterstützen und ob dies per Bios aktivierbar ist. Eine Liste aller Intel CPUs die Vt-d unterstützen findet sich hier.

Hier wird IOMMU ausführlich beschrieben

Unvollständige Listen zur Vt-d/IOMMU Unterstützung finden sich hier und hier.

Grafikkarten und Monitore

Um eine Grafikkarte an eine VM weiterreichen zu können, muss das Host System mindestens über 2 Grafikkarten verfügen. Beispielsweise können hier die in vielen Intel und einigen AMD CPUs verbauten integrierten Grafiklösungen für den Host genutzt werden und eine zusätzliche dedizierte Grafikkarte an die VM weiter gereicht werden. Im Bios muss zusätzlich die für den Host gewünschte Grafiklösung als primäre Videoausgabe konfiguriert werden.

Die in manchen Notebooks verbauten Hybridvarianten wie Nvidia Optimus sind nicht geeignet.

Zusätzlich ist es sehr ratsam, dass man entweder 2 Monitore oder einen Monitor mit 2 Eingängen (die jeweils mit der Host- und der Guest- Grafikeinheit verbunden werden) hat. Ansonsten muss man bei jedem Wechsel zwischen VM und Host den Monitor an die andere Grafikeinheit umstecken.

Mainboard

Wenn man eine Grafikkarte in einem anderen PCIe Slot als dem Hauptslot durch reichen möchte, empfiehlt sich dringend ein Mainboard mit einem besseren Chipsatz (z.B. X570 statt B550), da diese Grafikkarte sonst nicht in ihrer eigenen IOMMU Gruppe ist und dann nur zusammen mit anderen Mainboard Komponenten/Geräten oder gar nicht durch gereicht werden kann(siehe Abschnitt 4.5). Der erste PCIe x16 Slot ist auch beim B550 in seiner eignen IOMMU Gruppe.

Peripherie

Wenn nur die weitergereichte Grafikkarte innerhalb der VM genutzt wird, wird ein zweites Set an Tastatur und Maus benötigt. Alternativ kann hier auch ein USB KVM Switch genutzt werden, der die Peripherie per Tastendruck/Schalter zwischen der VM und dem Host umschaltet.

Alternativ kann auf die proprietäre kostenpflichtige Synergy Softwarelösung zurück gegriffen werden.

Eine weitere Variante ist es ein SPICE Fenster am Host geöffnet zu lassen, um zurück zum Host wechseln zu können. Um die Maus im Falle, dass der Fokus aufs Gastsystem gewechselt ist, zu lösen hilft folgende Tastenkombination STRG+ALT.

UEFI Boot der Grafikkarte

Wenn der Host die integrierte Intel Grafik nutzt und eine dedizierte Grafikkarte an die VM als alleinige/primäre Grafikkarte weitergereicht werden soll, muss die dedizierte Grafikkarte den UEFI Boot Modus unterstützen. Zusätzlich muss die VM im UEFI Modus konfiguriert werden (siehe BIOS/UEFI Boot und OVMF). Ob die Grafikkarte dies unterstützt, kann hier geprüft werden. Wer gerne bastelt, kann teilweise auch die Firmware seiner Grafikkarte anpassen um UEFI zu unterstützen.

Hinweis: Sollte die Grafikkarte den UEFI Modus nicht unterstützen, oder der BIOS Boot für die VM gewählt werden, muss der VM eine QXL Grafikkarte zugewiesen sein und als primäre Grafikkarte genutzt werden.

Virt-Manager weist der VM bei der Erstellung automatisch eine QXL Grafikkarte als primäre Ausgabe zu.

Hinweis: Bitte hilf mit diesen Abschnitt zu überarbeiten, da diese Infos veraltet und nicht ganz korrekt sind!

Einrichtung

IOMMU im Host aktivieren

Zuerst muss bei einer Intel CPU sowohl Vt-x als auch Vt-d (IOMMU) und bei einer AMD CPU AMD-V (kann auch SVM genannt werden) und AMD-Vi (IOMMU) im Bios/UEFI aktiviert werden.

IOMMU muss per Bootparameter gestartet werden: Dazu muss als Root unter /etc/default/grub beim Eintrag GRUB_CMDLINE_LINUX_DEFAULT="..." folgendes hinzugefügt werden:

intel_iommu=on (für eine Intel CPU)
amd_iommu=on (für eine AMD CPU)

Beispiel:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on"

Anschließend muss Grub als Root upgedatet werden:

root@debian:~# update-grub

Nach einem Neustart kann man nun prüfen ob IOMMU aktiviert ist:

   bei Intel:

user@debian:~$ dmesg | grep "Virtualization Technology"

   oder bei AMD:

user@debian:~$ dmesg | grep AMD-Vi

Grafiktreiber blacklisten

Wenn man nur jeweils 1 Nvidia oder AMD Karte im Rechner hat und diese an die VM durch reichen möchte, kann man deren Grafiktreiber blacklisten: Dazu erstellt man als Root folgende Datei /etc/modprobe.d/blacklist.conf und fügt je nach Grafikkarte einen der folgenden Punkte ein:

für eine Nvida Karte: blacklist nouveau
für eine AMD Karte: blacklist radeon(für alte Karten) oder blacklist amdgpu(für aktuelle Karten)
am besten prüft man vor dem blacklisten mit
```
user@debian:~$ lspci -vnn
```
welches Treiber Modul verwendet wird

Danach muss man als Root

root@debian:~# depmod -ae

ausführen um die Blacklist einzulesen und

root@debian:~# update-initramfs -u -k all

ausführen, um das Initramfs zu updaten.

Nach einem Neustart ist dann nur die primäre Grafikkarte aktiv.

Alternativ kann man die Guest Grafikkarte auch über einen Kernelparameter (/etc/grub/default unter GRUB_CMDLINE_LINUX_DEFAULT="...") blacklisten. (modprobe.blacklist=nouveau, modprobe.blacklist=radeon oder modprobe.blacklist=amdgpu)

VFIO Zuweisung

Die Unterstützung für VFIO ist ab der Linux Kernel Version 4.1 in diesem integriert. Die veraltete Alternative pci-stub sollte nicht mehr verwendet werden.

root@debian:~# lspci -vnn

Hiermit kann man prüfen, welche PCI IDs die dedizierte Grafikkarte und deren integrierter Audiochip haben.

Nun muss man als Root eine Configdatei /etc/modprobe.d/vfio.conf erstellen und darin zum Beispiel folgendes einfügen:

options vfio-pci ids=1002:6818,1002:aab0

Bei 1002:6818,1002:aab0 handelt es sich hier beispielsweise um eine AMD Radeon 7870 Grafikarte und deren HDMI Audiochip. Dies sorgt dafür, das der Grafikkarte beim Boot der VFIO Treiber zugewiesen wird.

Hinweis: Es ist nicht unbedingt notwendig hier auch die ID des Audiochips mit anzugeben. Ich hatte bei meinem neusten Versuch keine Probleme diesbezüglich.

Bei anderen PCI Geräten ist dies normalerweise nicht nötig und passiert automatisch beim Start der entsprechenden VM (bei der Grafikkarte kann .

Hinweis: Wenn der Grafiktreiber geblacklistet wird, kann dies entfallen. Ich würde es aber trotzdem empfehlen um sicherzustellen dass die Grafikkarte nicht von einem anderen Treiber vereinnahmt wird.

Hat man den Grafiktreiber nicht geblacklistet, oder hat mehr als 1 Nvidia bzw. AMD Grafikkarte muss am besten noch folgendes in die Datei /etc/modprobe.d/vfio.conf hinzugefügt werden: für Intel:

softdep nouveau pre: vfio-pci

für AMD:notwenig

softdep amdgpu pre: vfio-pci

bzw. für alte AMD Karten:

softdep radeon pre: vfio-pci

Dies stellt sicher, dass das entsprechende Modul erst nach vfio-pci geladen wird und somit der Grafikkarte vfio.pci zugeweisen werden kann. (Quelle)

[https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF#Using_identical_guest_and_host_GPUs Hier werden auf Englisch Möglichkeiten aufgezeigt, für den Fall dass es sich bei der Host und der Guest Grafikkarte um das selbe Modell vom selben Hersteller handelt.

Laden der Module beim Start

Hierzu muss man als Root in der Datei /etc/modules folgendes anfügen:

vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd

Paketinstallation

Um QEMU/KVM nutzen zu können müssen folgende Pakte installiert werden (zusammen mit deren empfohlenen Paketen): qemu-system libvirt-clients libvirt-daemon-system Für Debian Buster und älter: qemu qemu-kvm libvirt-clients libvirt-daemon-system

UM UEFI in der VM nutzen zu können wird zusätzlich ovmf benötigt.

Um eine GUI zur VM Verwaltung zu erhalten kann virt-manager installiert werden.

In dieser Anleitung wird auf Virt-Manager zur Einrichtung und Erstellung der VM zurückgegriffen.

Anpassen der Berechtigungsgruppen

Um die VMs mit normalen Benutzer Rechten erstellen und bearbeiten zu können, muss der entsprechende Benutzer Mitglied in folgenden Berechtigungsgruppen sein:

Für Debian Bullseye und neuere Releases: libvirt
Für Debian Jessie-Backports, Stretch und Buster: libvirt und (libvirt-qemu)
Für Debian Jessie und älter: libvirt und kvm

Liste der Debian Releases

Benutzer1 kann als Root mit folgendem Befehl zu Gruppe1 hinzugefügt werden:

root@debian:~# usermod -a -G Gruppe1 Benutzer1

Damit die Berechtigungen aktiv werden, muss Benutzer1 sich aus und wieder neu einloggen.

VM Installation

Es wird empfohlen die Windows VM erst einmal ohne die dedizierte Grafikkarte zu installieren und diese dann erst nach erfolgreicher Installation an die VM weiter zu reichen.

Über Virt-Manager kann eine neue Windows VM erstellt werden. Bevor man Schritt 5 abschließt, sollte man den haken setzen, dass man die Konfiguration erst anpassen möchte, bevor die VM zum ersten mal gestartet wird.

Virtuelle Festplatte

Für die beste Performance empfiehlt es sich eine separate SSD für die VM zu verwenden und diese per LVM oder direkt weiterzugeben. Siehe hier. Sofern man einen separaten Festplattencontroller verbaut hat, kann dieser auch direkt durch gereicht werden und alle daran angeschlossenen Geräte sind automatisch der VM zugewiesen.

qcow2 Image (am einfachsten)

Hierzu erstellt man ein qcow2 Image auf einer SSD/HDD oder auf einem Netzlaufwerk, welches dann als virtuelle Festplatte für die VM genutzt werden kann. Mit qcow2 lassen sich einfach Snapshots der VM erstellen. Mit Virt-Manager wir automatisch ein Image vom Typ qcow2 erstellt, wenn man im Dialog ein Image-Laufwerk hinzufügt. Sofern der Pfad zum Standard Storage Pool nicht geändert wurde, liegen diese Images unter: /var/lib/libvirt/images/

dedizierte Festplatte

Eine Festplatte (HDD oder SSD) kann auch direkt an die VM weitergereicht werden. Dazu gibt man direkt den Pfad /dev/sdx zum Laufwerk an.

dedizierte Festplatte mit LVM

Um LVM Snapshots mit der separaten SSD zu nutzen, muss man diese wie folgt konfigurieren: Aus der SSD wird ein LVM PV (physical volume) erstellt und darin eine VG (volume group)

Diese VG kann dann als Storage Pool im Virt-Manager eingebunden werden

Schritt 1: Der Name kann frei gewählt werden und muss nicht der der VG sein; Der Type muss LVM sein
Schritt 2: Als Ziel/Target wird /dev/<Name der VG>; Die Quelle/Source kann leer bleiben und "build pool" darf in diesem Fall nicht angehakt werden, da das LVM bereits vorher konfiguriert wurde. (Alternativ kann die VG auch hierüber komplett angelegt werden)

In diesem Virt-Manager Storage Pool können dann die VM Volumes angelegt werden (1 Volume wird als 1 physische Platte in der VM angezeigt, es reicht also aus 1 Volume / VM zu zuweisen)

Pool Erstellung

Fertiger Pool

Mit LVM lassen sich einfach Snapshots erzeugen, sofern man in der Volume Group (VG) noch unzugewiesenen Speicher übrig gelassen hat.

Performance

Die beste Performance erhält man, wenn man eine separate Festplatte direkt (oder über LVM) an die VM durchreicht.

Festplatten Einstellungen

Bei den Einstellungen der Festplatte sollte man für die beste Performance bei allen drei Varianten SCSI wählen. Hierzu muss noch ein SCSI Controller vom Typ "VirtIO SCSI" hinzugefügt werden.

Allerdings muss der Treiber während der Installation geladen werden, da dieser Controller sonst nicht von Windows unterstützt wird. Hierzu kann man einfach ein 2. DVD Laufwerk hinzufügen und dort die Treiber ISO mounten. (siehe Abschnitt Virtio Treiber) Für Windows 10 findet sich der passende Treiber dann beispielsweise unter <x>:\vioscsi\w10\amd64 auf der Treiber CD.

Festplatten Eigenschaften

SCSI-Controller

TRIM

Sofern man eine SSD weiterreicht (direkt oder per LVM) oder das qcow2 Image auf einer SSD liegt, sollte TRIM aktiviert werden. Dazu führt man folgenden Befehl aus:

user@debian:~$ virsh --connect qemu:///system edit Name-der-VM

Dann sucht man Nach der Festplattenzeile und fügt hier discard='unmap' ein. Die entsprechenden Zeilen sehen dann beispielsweise so aus:

<disk type='block' device='disk'>
  <driver name='qemu' type='raw' cache='none' io='native' 'discard='unmap'/>
  ...

Netzwerk

Für die bestmögliche Netzwerk Performance kann beim Netzwerkkarten Typ auch "virtio" ausgewählt werden. Will man im Guest eine IP aus dem Adressbereich des Hosts, muss eine Bridge eingerichtet werden.

Netzwerk-Bridge erstellen

[Hier https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-network_configuration-bridged_networking] findet sich eine Anleitung (auf Englisch) vom RHEL Projekt.

Hinweis: Dieser Abschnitt muss noch ausgearbeitet werden.

BIOS/UEFI Boot

Vor dem ersten Start muss unter dem Reiter Übersicht/Overview gewählt werden ob die VM im BIOS oder UEFI Modus betrieben werden soll.

Außerdem sollte der virtuelle Mainboard Chipsatz auf i440FX belassen werden. (sowohl im BIOS wie auch im UEFO Boot Modus)

Mit dem Q35 gab es beim Booten immer wieder Abstürze von Windows (spätestens beim Installieren des Grafikkartentreibers) , sobald die Grafikkarte an die VM weitergereicht wurde.

Bei aktuellerer Hardware kann getrost der UEFI Modus verwendet werden.

Windows Virtio Treiber

Die Virtio Treiber, wie der Virtio SCSI, der Virtio Treiber (Festplatte vom Typ Virtio, ohne zusätzlichen Controller) sowie weitere Treiber für die Windows VM finden sich auf folgedner Github Seite als ISO: Virtio Treiber.

Grafikkarte (oder andere PCI/PCIe Geräte) an die VM weiter reichen

Nach erfolgreicher VM Installation, muss diese beendet werden. Danach kann im Virt-Manager über "Hardware hinzufügen/Add Hardware -> PCI/PCI Host device" die Grafikkarte, sowie deren Sounchip ausgewählt werden.

Jetzt kann man in die VM booten und den Grafikkartentreiber installieren. Bei Bedarf kann jetzt die QXL Videokarte in der VM entfernen werden (nur wenn die Audioausgabe nicht über SPICE erfolgt).

Wenn man einen zweiten USB Controller hat, kann es Sinn machen, diesen der VM zuzuweisen und dort die zusätzliche Peripherie für die VM (oder der zweite USB-KVM Port) anzuschließen.

PCIe Grafikkarte an VM durch reichen

Hinweis: Um Probleme zu vermeiden, ist es wichtig, immer den in der Grafikkarte integrierten Soundchip mit durch zu reichen. Ebenso, ist es wichtig, dass die Grafikkarte von keinem Treiber (außer vfio-pci) genutzt wird (siehe Grafiktreiber blacklisten).

Es müssen immer alle Geräte einer VFIO Gruppe an die VM weitergereicht werden (Eine Ausnhame bildet eine PCI bridge in der Gruppe, welche nicht durchgereicht werden sollte). Mit folgendem Skript, kann man sich die Geräte in den VFIO Gruppen anzeigen lassen:

#!/bin/bash
shopt -s nullglob
for g in `find /sys/kernel/iommu_groups/* -maxdepth 0 -type d | sort -V`; do
    echo "IOMMU Group ${g##*/}:"
    for d in $g/devices/*; do
        echo -e "\t$(lspci -nns ${d##*/})"
    done;
done;

Sound

Man kann das QXL Videogerät und Spice für die VM aktiviert lassen, da dann darüber die Soundausgabe der VM auf den Host geleitet wird. In den Bildschirmeinstellungen unter Windows kann der 2. Monitor (der an QXL hängt) aber abgeschaltet werden. Diese Lösung führt allerdings zu leichten Glitches in der Soundausgabe die von der VM kommt.

Alternativ kann man den Sound über den HDMI Ausgang der dedizierten Grafikkarte oder über einen zusätzlichen Soundcontroller ausgeben.

VM Erstellung mit virt-install

Die VM kann auch ohne Virt-Manager (GUI) in der Shell erstellt werden. Hierzu bietet sich der Befehl virt-install an.

Hinweis: Bitte hilf mit diesen Abschnitt auszubauen, wenn du Erfahrung hiermit hast.

Weitere VM Infos, Anpassungen und Optimierungen

Windows Lizenzen

Für die VM wird ein separater Windows Aktivierungsschlüssel benötigt. Ob es zulässig wäre, den gleichen Schlüssel in einer Dual-Boot Umgebung und unter GNU/Linux in der VM zu nutzen, müsste rechtlich geklärt werden.
Natürlich kann auch Windows 10, wie seine Vorgänger, 30 Tage ohne Aktivierung zu Testzwecken genutzt werden.
Stand Oktober 2020 können während der Installation von Windows 10 weiterhin Aktivierungsschlüssel/Keys für Windows 8/8.1 und Windows 7 (unbestätigt) genutzt werden. Nachträglich lassen sich diese nicht aktivieren (Telefonaktivierung könnte eventuell noch funktionieren).

Datenaustausch per Samba/SMB

Zum Datenaustausch zwischen der (Windows) VM und dem Host kann das Samba/SMB Protokoll genutzt werden. Hierzu wird entweder ein Ordner/Pfad in der VM freigegeben und am Host per Samba CLient darauf zu gegriffen, oder am Host ein Pfad per Samba Server freigegeben und in der VM darauf zugegriffen. Wird fürs Gastsystem ein NAT Netzwerkgerät verwendet, funktioniert diese Methode nicht.

LVM Volume der VM am Host mounten

Um die Partition der Vm am Host mounten zu können, wird das Paket kpartx benötigt. Dann kann als Root mit

root@debian:~# kpartx -av /dev/vg/lv

die einzelnen Partitionen nach /dev/mapper/ mappen. Die Partitionen erscheinen dann unter /dev/mapper/vg-lv1, /dev/mapper/vg-lv2, /dev/mapper/vg-lvx und können gemountet werden. Um de Verknüpfung/das Mapping zu entfernen:

root@debian:~# kpartx -dv /dev/vg/lv

Warnung: Die VM Partition sollte nie als RW am Host gemountet sein, während die VM läuft, da es sonst zu Datenverlusten kommen kann

Nvidia Grafikkarte unter Windows (Error Code 43) und AMD Treiberprobleme

Wenn man eine Nvidia Grafikkarte an eine VM weiter reicht und einen aktuellen Treiber nutzen möchte, meldet der Gerätemanager unter Windows den Error Code 43. Um dies zu verhindern muss Konfigurationsdatei der VM bearbeitet werden. Laut dem Arch Wiki kann dies auch bei Treiberproblemen mit neueren Versionen des AMD Grafiktreibers helfen. Dazu führt man folgenden Befehl aus:

user@debian:~$ virsh --connect qemu:///system edit Name-der-VM

und fügt

  <vendor_id state='on' value='whatever'/>

in folgenden Abschnitt ein:

<hyperv>
  ...
</hyperv>

Sollte der Gerätemanager weiterhin den Error Code 43 melden, hilft es

<kvm>
  <hidden state='on'/>
</kvm>

direkt unter dem Abschnitt

<hyperv>
  ...
</hyperv>

hinzuzufügen.

Warnung: Der folgende Abschnitt ist veraltet und nur der Vollständigkeit halber hier aufgelistet, da man diesen Tipp noch oft im Internet findet

Früher hat man folgende Abschnitte

<hyperv>
  <relaxed state='on'/>
  <vapic state='on'/>
  <spinlocks state='on' retries='8191'/>
</hyperv>

und

  <timer name='hypervclock' present='yes'/>

im Block

  <clock offset='localtime'>
  ...
  </clock>

entfernt, wovon aber inzwischen abgerraten wird, da es durch die Deaktivierung einiger Hypervisor Features zu einer verringerten Performance der VM führt.

Siehe auch hier

Bluescreens im Windows Guest

Treten immer wieder Bluescreens im Guest Windows auf und dmesg zeigt Fehler bezüglich MSR. In diesen Fällen kann man die Bluescreens verhindern, wenn man MSRs (Model Specific Registers) deaktiviert: Dazu erstellt man als Root folgende Datei /etc/modprobe.d/kvm.conf und fügt folgendes ein:

  options kvm ignore_msrs=1

Ich würde dazu raten, dies immer zu setzen, wenn Windows Guests genutzt werden sollen.

Black Screens nach dem Boot im Windows Guest mit dem Q35 Chipset

Nach dem Upgrade auf Windows 10 2004 zeigte mir das System nur noch einen schwarzen Bildschirm nach dem UEFI Boot Logo an.

Bei solchen Problemem kann es helfen in der QEMU Konfiguration

user@debian:~$ virsh --connect qemu:///system edit Name-der-VM

folgendes

  <ioapic driver='kvm'/>

im Block

  <features>
  ...
  </features>

hinzuzufügen.

Siehe auch hier

VM von BIOS Boot auf UEFI >Boot konvertieren

Als erstes sollte man ein Backup seiner virtuellen Festplatte erstellen. Dann muss die Partitionstabelle der virtuelle Festplatte von MBR auf GPT konvertiert werden. Unter Linux als Root per

gdisk /dev/sdX

> w > y

Unter Windows in einer Admin Powershell mit:

mbr2gpt /validate /allowFullOS
mbr2gpt /convert /disk:0 /allowFullOS

Als nächstes muss die VM heruntergefahren werden. Dann erstellt man eine neue VM, wählt die konvertierte virtuelle Festplatte und als Firmware UEFI statt Bios aus. Nun sollte die VM im UEFI Boot Modus starten. Siehe auch hier.

Verschachtelete (nested) Virtualisierung

Wenn man in der VM wiederum Virtualisierung mit Hardwarebeschleunigung nutzen möchte, muss man die Vierschachtelung am Host aktivieren: Mit folgendem Befehl kann geprüft werden ob diese aktiv ist:

Intel CPU:

cat /sys/module/kvm_intel/parameters/nested

AMD CPU:

cat /sys/module/kvm_amd/parameters/nested

Ein Wert von Y oder 1 bedeutet der Parameter ist aktiv. Analog bedeutet N oder 0, dass dieser inaktiv ist.

Um die Vierschachtelung zu aktivieren, muss als Root eine der beiden folgenden Zeilen in die /etc/modprobe.d/kvm.conf angefügt werden:

options kvm_intel nested=1 #für Intel
options kvm_amd nested=1 #für AMD

Um die Verschachtelung für eine VM zu aktivieren, sollte man "Copy host CPU configuration" (empfohlen) in den CPU Einstellungen anwählen oder host-passthrough als CPU Modell (nicht empfohlen). Hier findet sich eine ausführliche Anleitung (auf Englisch) vom Fedora Projekt.

Storage Pool Berechtigungen

Wird ein anderer Pfad als /var/lib/libvirt/images/ für den Storage Pool verwendet, muss sichergestellt werden, dass libvirt-qemu lesed darauf zugreifen kann. Es reicht hierzu other Lesezugriff zu gewähren (z.B. 744). Die Eigentümerschaft des Ordners kann bei root:root verbleiben.

AMD Reset Bug

Bei vielen AMD Grafikkarten mit den Codenamen Polaris, Vega and Navi kommt es zum sogenannten Reset Bug, bei dem sich der Host öfters aufhängt, wenn man versucht die VM nach dem herunterfahren ein zweites Mal zu starten (oder einen Restart durchführt), ohne vorher den Host neu gestartet zu haben. Dies liegt an den Grafikartenmodellen selbst und nicht am Linuxsystem. Allerdings gibt es seit kurzem ein tolles Kernel Modul, dass die Grafikkarte nach dem herunterfahren der VM resetet, so dass die VM problemlos wieder gestartet werden kann siehe * hier.

Hinweis: Zumindest mit Debian Bullseye in Kombination mit einer Radeon RX580 gab es bei mir bisher (Februar 2021) keine Probleme mehr durch den Reset Bug.

Folgende Debian Pakete müssen zum bauen des Modules installiert sein: git, dkms, build-essential Anschließend wechselt man in den Ordner in dem man das Modul bauen möchte und führt folgendes aus um die Quelle herunterzuladen und in den heruntergeladenen Ordner zu wechseln :

user@debian:~$ 
git clone https://github.com/gnif/vendor-reset.git
cd vendor-reset/

Um das Modul zu bauen und zu installieren führt man als Root folgendes aus:

root@debian:~# sudo dkms install .

Als Root muss nun folgendes in /etc/modules hinzugefügt werden:

vendor-reset

Nach dem Reboot nimmt das Kernel Modul nun automatisch seinen Dienst auf. Das ganze äußert sich im dmesg nach dem herunterfahren der VM zum Beispiel folgendermaßen:

[59096.460537] vfio-pci 0000:0b:00.0: AMD_POLARIS10: version 1.1
[59096.460540] vfio-pci 0000:0b:00.0: AMD_POLARIS10: performing pre-reset
[59096.460756] vfio-pci 0000:0b:00.0: AMD_POLARIS10: performing reset
[59096.460762] vfio-pci 0000:0b:00.0: AMD_POLARIS10: CLOCK_CNTL: 0x0, PC: 0x2a44
[59096.460763] vfio-pci 0000:0b:00.0: AMD_POLARIS10: performing post-reset
[59096.500407] vfio-pci 0000:0b:00.0: AMD_POLARIS10: reset result = 0

Bechmarks

Hier finden sich Benchmarks für den Vergleich einer normalen Windows Installation mit einer Windows Installation in einer QEMU/KVM Virtuellen Maschine mit durch gereichter dedizierter Grafikkarte. Bei beiden Versuchen wurden alle 4 CPU Kerne einer Intel i5-3470S CPU, die selbe SAMSUNG SSD 830, sowie die selbe Gigabyte HD7870 OC (AMD) Grafikkarte genutzt.

GPU lastiger Benchmark (3DMARK)

Dedizierte Windows 10 Pro Inst.	Windows 10 Pro in QEMU/KVM VM
3DMARK Time Spy V1.0	3DMARK Time Spy V1.0
3DMARK Fire Strike V1.1	3DMARK Fire Strike V1.1
3DMARK Sky Diver V1.0	3DMARK Sky Diver V1.0
3DMARK Cloud Gate V1.1	3DMARK Cloud Gate V1.1