ibm9001
Lt. Junior Grade
- Registriert
- Juli 2005
- Beiträge
- 474
Hallo zusammen,
ich möchte hier meine Erfahrungen zum Durchreichen einer Grafikkarte in eine virtuelle Maschine (GPU-Passtrough) wiedergeben. Meine Idee war, das Windows 10 auf meiner Workstation zu virtualisieren (mit Linux als Hostsystem).
Das Gehäuse dieser Workstation (eine ein wenig gemoddete SUN SPARCstation 10) bietet nur wenig Platz im Inneren, deshalb die Verwendung eines ITX Mainboards (hier: BIOSTAR B550T-Silver).
Die nachfolgende Beschreibung ist die Schritt für Schritt Anleitung, die ich für mich erstellt habe, damit ich ein solches System schnell selbst aufsetzen kann. Da ich kein IT-Profi bin, hat es entsprechend lange gedauert, bis ich das ganze ans Laufen bekommen habe. Von daher dachte ich mir, gib deine Erfahrungen hier weiter, vielleicht wird damit anderen Leuten bei einem ähnlichen Vorhaben geholfen.
DISCLAIMER:
Dies ist kein Tutorial für Anfänger und soll auch kein allgemein gültiger Guide zum Thema GPU Passthrough werden, sondern sind das Ergebnis meiner Erfahrungen mit meiner eigenen Hardware bzw. das ganze ist auf meine Hard- und Software zugeschnitten.
ich möchte hier meine Erfahrungen zum Durchreichen einer Grafikkarte in eine virtuelle Maschine (GPU-Passtrough) wiedergeben. Meine Idee war, das Windows 10 auf meiner Workstation zu virtualisieren (mit Linux als Hostsystem).
Das Gehäuse dieser Workstation (eine ein wenig gemoddete SUN SPARCstation 10) bietet nur wenig Platz im Inneren, deshalb die Verwendung eines ITX Mainboards (hier: BIOSTAR B550T-Silver).
Die nachfolgende Beschreibung ist die Schritt für Schritt Anleitung, die ich für mich erstellt habe, damit ich ein solches System schnell selbst aufsetzen kann. Da ich kein IT-Profi bin, hat es entsprechend lange gedauert, bis ich das ganze ans Laufen bekommen habe. Von daher dachte ich mir, gib deine Erfahrungen hier weiter, vielleicht wird damit anderen Leuten bei einem ähnlichen Vorhaben geholfen.
DISCLAIMER:
Dies ist kein Tutorial für Anfänger und soll auch kein allgemein gültiger Guide zum Thema GPU Passthrough werden, sondern sind das Ergebnis meiner Erfahrungen mit meiner eigenen Hardware bzw. das ganze ist auf meine Hard- und Software zugeschnitten.
Zum Durchreichen einer Grafikkarte in eine VM benötigt man normalerweise zwei Grafikkarten. Eine für die VM und eine für das Host-System. Ein Mini-ITX-Board hat aber in der Regel nur einen Steckplatz zur Verfügung. Deshalb benötigt man in diesem Fall eine CPU mit integrierter Grafikeinheit. Bei Intel sind das Prozessoren mit UHD Graphics (iGPU), bei AMD die sogenannten APU´s. Ich habe mich letztendlich für AMD entschieden und daher folgende Hardware verbaut:
CPU: AMD APU Ryzen 5700G
Mainboard: Biostar B550T-Silver (mit BIOS 1.2.03C)
Arbeitsspeicher: 64 GByte KINGSTON FURY BEAST 3200
Dedizitierte Grafikkarte: GTX 1050
Laufwerk(e): Host=Kingston SA2000 / 1TB NVMe , VM=Samsug Sata-SSD
Monitore: 1xSamsung an GTX 1050, 1xDELL an APU
Verwendete Software: Windows 10 Pro in der VM, AlamaLinux als Host Betriebssystem.
Zum Erstellen und Einrichten einer Windows 10 VM mit GPU Passthrough habe ich nacheinander folgende Schritte ausgeführt:
1) Mainboard-BIOS
Damit das Vorhaben gelingen kann ist es notwendig, das IOMMU bzw. IOMMU Groups vom Mainboard unterstützt werden. D.h es geht als erstes mit dem Mainboard-BIOS los, dort sind die folgenden Voreinstellungen notwendig:
Advanced -> CPU Configuration -> SVM Mode = Enabled
Advanced -> CPU Configuration -> SMT Mode = Auto
Advanced -> CSM Configuration -> CSM Support = Enabled
Advanced -> CSM Configuration -> CSM Support = Enabled -> Network = UEFI
Advanced -> CSM Configuration -> CSM Support = Enabled -> Storage = UEFI
Advanced -> CSM Configuration -> CSM Support = Enabled -> Video = Legacy
Advanced -> CSM Configuration -> CSM Support = Enabled -> other PCI Device ... = UEFI
(Normalerweise würde man CSM mit modernen Betriebssystemen nicht aktivieren, jedoch wird
die separate Grafikkarte mit der Einstellung UEFI zuerst initialisiert [bei diesem Mainboard hier] und
macht das Durchreichen derselben in eine VM aufwendiger bis die Konfiguration läuft)
Chipset -> North Bridge -> IOMMU = Enabled
Chipset -> North Bridge -> GFX Configuration -> Primary Video Device = IGD Video
Chipset -> North Bridge -> GFX Configuration -> Surround View = Auto
CPU: AMD APU Ryzen 5700G
Mainboard: Biostar B550T-Silver (mit BIOS 1.2.03C)
Arbeitsspeicher: 64 GByte KINGSTON FURY BEAST 3200
Dedizitierte Grafikkarte: GTX 1050
Laufwerk(e): Host=Kingston SA2000 / 1TB NVMe , VM=Samsug Sata-SSD
Monitore: 1xSamsung an GTX 1050, 1xDELL an APU
Verwendete Software: Windows 10 Pro in der VM, AlamaLinux als Host Betriebssystem.
Zum Erstellen und Einrichten einer Windows 10 VM mit GPU Passthrough habe ich nacheinander folgende Schritte ausgeführt:
1) Mainboard-BIOS
Damit das Vorhaben gelingen kann ist es notwendig, das IOMMU bzw. IOMMU Groups vom Mainboard unterstützt werden. D.h es geht als erstes mit dem Mainboard-BIOS los, dort sind die folgenden Voreinstellungen notwendig:
Advanced -> CPU Configuration -> SVM Mode = Enabled
Advanced -> CPU Configuration -> SMT Mode = Auto
Advanced -> CSM Configuration -> CSM Support = Enabled
Advanced -> CSM Configuration -> CSM Support = Enabled -> Network = UEFI
Advanced -> CSM Configuration -> CSM Support = Enabled -> Storage = UEFI
Advanced -> CSM Configuration -> CSM Support = Enabled -> Video = Legacy
Advanced -> CSM Configuration -> CSM Support = Enabled -> other PCI Device ... = UEFI
(Normalerweise würde man CSM mit modernen Betriebssystemen nicht aktivieren, jedoch wird
die separate Grafikkarte mit der Einstellung UEFI zuerst initialisiert [bei diesem Mainboard hier] und
macht das Durchreichen derselben in eine VM aufwendiger bis die Konfiguration läuft)
Chipset -> North Bridge -> IOMMU = Enabled
Chipset -> North Bridge -> GFX Configuration -> Primary Video Device = IGD Video
Chipset -> North Bridge -> GFX Configuration -> Surround View = Auto
2) Installation des Host-Systems, d.h. hier AlmaLinux 8.5.
a) Die Iso (x86_64) downloaden Link1 und unter Windows mit Rufus Link2 auf einen USB Stick schreiben.
-> Die aktuellste Version von Rufus nutzen, ältere Versionen können bei der Installation Probleme
bereiten.
b) Vom so vorbereiteten USB-Stick booten (Bootauswahl mit der Taste F9 der Tastatur, den USB-Stick auswählen) und Almalinux auf die bereitgestellte NVMe, SSD oder HDD installieren (bei der Softwareauswahl des Installationsbildschirms kann dann die gewünschte Variante [hier: Workstation] ausgewählt werden.
c) Nach der Installation Almalinux auf den aktuellen Stand updaten. Dafür ein Terminal Fenster öffnen,
Root-Rechte erlangen,
(im Terminal den Befehl
ausführen und die nachfolgende Passwortabfrage beantworten). Jetzt mit
das Update ausführen (LAN muss aktiv sein). Anschließend das System neu starten.
d) Die notwendige Virtualisierungssoftware (hier QEMU-KVM) installieren. D.h. wieder Terminal öffnen,
Rootrechte mit
erlangen und mit
sowie
die Virtualisierungspakete installieren. Danach das System neu starten.
e) Prüfen in welcher IOMMU Gruppe sich die durchzureichende Grafikkarte (hier NVIDIA GTX 1050) befindet, sowie deren Geräte-ID ermitteln. D.h. Terminal öffnen und anschließend das Script aus Link3 eingeben (eher copy & paste) und ausführen lassen.
Als Ergebnis erhält man u. a. mit der hier verwendeten Hardwarekonfiguration:
...
IOMMU Group 8:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107 [GeForce GTX 1050] [10de:1c81] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation GP107GL High Definition Audio Controller [10de:0fb9] (rev a1)
....
Die Grafikkarten-ID lautet damit: [10de:1c81], die ID des verbauten Audio-Controllers auf der Grakfikkarte: [10de:0fb9]. Die so ermittelten ID´s können jetzt per Grub an den vfio Treiber angebunden werden. Wichtig ist hier, das alle Geräte dieser IOMMU Gruppe an die VM durchgereicht werden.
Hinweis: Die Grafikkarten-ID´ s sind natürlich Hardware abhängig, d.h. mit einer anderen Grafikkarte ändern sich natürlich auch die ID´s.
f) Jetzt den Bootloader Grub folgendermaßen anpassen:
Wieder ein Terminal öffnen, Rootrechte mit
erlangen und dann mit einem Editor, (z.B. nano oder vi) Grub bearbeiten:
In Grub die Zeile GRUB_CMDLINE_LINUX=" ...quiet" finden und nach quiet folgendes einfügen:
und speichern. Anschließend Grub neu konfigurieren:
g) Jetzt die Datei /etc/dracut.conf.d/10-vfio.conf mit folgenden Inhalt erzeugen:
add_drivers+=" vfio_pci vfio vfio_iommu_type1 vfio_virqfd "
Das ganze mit dem Editor der Wahl ausführen (z.B. nano oder vi). D.h. mit z.B. nano
aufrufen, die Zeile
add_drivers+=" vfio_pci vfio vfio_iommu_type1 vfio_virqfd "
einfügen, bzw. hinein kopieren und dann speichern.
h) Anschließend als root
im Terminal ausführen damit initramfs für das aktuell laufende System neu generiert wird.
Danach das Host System neu starten (reboot).
Wenn alles richtig funktioniert, dann wird nach dem Neustart des Systems nur noch der Monitor, der an der APU angeschlossen ist von Almalinux initialisiert und benutzt (dies ist dem Eintrag
Jetzt kann zusätzlich mit
geprüft werden, ob die Einbindung des Treibers gelungen ist. Dazu muss die Grafikkarte, die durchgereicht werden soll, folgenden Eintrag enhalten: Kernel driver in use: vfio-pci
Das gilt für die Grafikarte selbst, und falls vorhanden, dem auf der Karte verbautem Audiochip.
Nachtrag: Nach dem Installieren der Virtualisierungsumgebung sollte man noch der Gruppe libvirt beitreten.
Dazu als root
eingeben.
Anderenfalls wird man beim Starten der Virtuellen Maschinenverwaltung immer nach dem root Passwort gefragt.
a) Die Iso (x86_64) downloaden Link1 und unter Windows mit Rufus Link2 auf einen USB Stick schreiben.
-> Die aktuellste Version von Rufus nutzen, ältere Versionen können bei der Installation Probleme
bereiten.
b) Vom so vorbereiteten USB-Stick booten (Bootauswahl mit der Taste F9 der Tastatur, den USB-Stick auswählen) und Almalinux auf die bereitgestellte NVMe, SSD oder HDD installieren (bei der Softwareauswahl des Installationsbildschirms kann dann die gewünschte Variante [hier: Workstation] ausgewählt werden.
c) Nach der Installation Almalinux auf den aktuellen Stand updaten. Dafür ein Terminal Fenster öffnen,
Root-Rechte erlangen,
(im Terminal den Befehl
[vm@linux ~]$ suausführen und die nachfolgende Passwortabfrage beantworten). Jetzt mit
[root@linux]# dnf updatedas Update ausführen (LAN muss aktiv sein). Anschließend das System neu starten.
d) Die notwendige Virtualisierungssoftware (hier QEMU-KVM) installieren. D.h. wieder Terminal öffnen,
Rootrechte mit
[vm@linux ~]$ suerlangen und mit
[root@linux]# dnf groupinstall "Virtualization Host" -ysowie
[root@linux]# dnf install virt-install virt-manager -ydie Virtualisierungspakete installieren. Danach das System neu starten.
e) Prüfen in welcher IOMMU Gruppe sich die durchzureichende Grafikkarte (hier NVIDIA GTX 1050) befindet, sowie deren Geräte-ID ermitteln. D.h. Terminal öffnen und anschließend das Script aus Link3 eingeben (eher copy & paste) und ausführen 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;Als Ergebnis erhält man u. a. mit der hier verwendeten Hardwarekonfiguration:
...
IOMMU Group 8:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107 [GeForce GTX 1050] [10de:1c81] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation GP107GL High Definition Audio Controller [10de:0fb9] (rev a1)
....
Die Grafikkarten-ID lautet damit: [10de:1c81], die ID des verbauten Audio-Controllers auf der Grakfikkarte: [10de:0fb9]. Die so ermittelten ID´s können jetzt per Grub an den vfio Treiber angebunden werden. Wichtig ist hier, das alle Geräte dieser IOMMU Gruppe an die VM durchgereicht werden.
Hinweis: Die Grafikkarten-ID´ s sind natürlich Hardware abhängig, d.h. mit einer anderen Grafikkarte ändern sich natürlich auch die ID´s.
f) Jetzt den Bootloader Grub folgendermaßen anpassen:
Wieder ein Terminal öffnen, Rootrechte mit
[vm@linux ~]$ suerlangen und dann mit einem Editor, (z.B. nano oder vi) Grub bearbeiten:
[root@linux]# nano /etc/sysconfig/grubIn Grub die Zeile GRUB_CMDLINE_LINUX=" ...quiet" finden und nach quiet folgendes einfügen:
amd_iommu=on rd.driver.pre=vfio-pci vfio-pci.ids=10de:1c81,10de:0fb9 video=efifb:off kvm.ignore_msrs=1und speichern. Anschließend Grub neu konfigurieren:
[root@linux]# grub2-mkconfig -o /etc/grub2-efi.cfgg) Jetzt die Datei /etc/dracut.conf.d/10-vfio.conf mit folgenden Inhalt erzeugen:
add_drivers+=" vfio_pci vfio vfio_iommu_type1 vfio_virqfd "
Das ganze mit dem Editor der Wahl ausführen (z.B. nano oder vi). D.h. mit z.B. nano
[root@linux]# nano /etc/dracut.conf.d/10-vfio.confaufrufen, die Zeile
add_drivers+=" vfio_pci vfio vfio_iommu_type1 vfio_virqfd "
einfügen, bzw. hinein kopieren und dann speichern.
h) Anschließend als root
[root@linux]# dracut -fim Terminal ausführen damit initramfs für das aktuell laufende System neu generiert wird.
Danach das Host System neu starten (reboot).
Wenn alles richtig funktioniert, dann wird nach dem Neustart des Systems nur noch der Monitor, der an der APU angeschlossen ist von Almalinux initialisiert und benutzt (dies ist dem Eintrag
video=efifb:offin GRUB zu verdanken.Jetzt kann zusätzlich mit
[vm@linux ~]$ lspci -nnkgeprüft werden, ob die Einbindung des Treibers gelungen ist. Dazu muss die Grafikkarte, die durchgereicht werden soll, folgenden Eintrag enhalten: Kernel driver in use: vfio-pci
Das gilt für die Grafikarte selbst, und falls vorhanden, dem auf der Karte verbautem Audiochip.
Nachtrag: Nach dem Installieren der Virtualisierungsumgebung sollte man noch der Gruppe libvirt beitreten.
Dazu als root
[root@linux ~]$ usermod -aG libvirt BENUTZERNAMEeingeben.
Anderenfalls wird man beim Starten der Virtuellen Maschinenverwaltung immer nach dem root Passwort gefragt.
3) VM einrichten
Jetzt kann mit dem Einrichten einer Windows 10 VM begonnen werden. Dazu wird ein Windows
10 ISO-Abbild benötigt. Falls das nicht schon vorhanden ist, dann sollte jetzt ein ISO-Abbild von
der Microsoft Homepage herunter geladen werden (Link4).
Um eine virtuelle Maschine aufzusetzen ist nun die virtuelle Maschinenverwaltung über die Desktop-
oberfläche des Hostsystems zu starten.
Nach dem Start sollte in der Maschinenverwaltung unter dem Menüpunkt
Bearbeiten -> Einstellungen
der Haken an „Enable XML editing“ gesetzt werden. Somit ist es später möglich den XML Code der
VM zwecks Anpassungen zu bearbeiten.
Die eigentliche Erstellung einer VM gestaltet sich wie folgt:
a) Unter Datei den Menüpunkt „Neue virtuelle Maschine“ anwählen.
Die Vorauswahl „Lokales Installationsmedium (ISO-Abbild oder CDROM)“ stehen lassen und auf
den Button „Vor“ klicken.
b) Das Installationsmedium auswählen.
Dazu auf „Durchsuchen“ klicken und das vorher herunter geladene ISO-Abbild von Windows 10
auswählen. Anschließend wieder die Taste „Vor“ anklicken.
c) Speicher (RAM) und CPU Settings.
Die Voreinstellungen für Speicher und CPU stehen lassen, diese können noch im späteren Verlauf
angepasst werden. Daher wieder die Taste „Vor“ anklicken.
d) Speicherplatz für die virtuelle Maschine einrichten
Für erste Versuche die Voreinstellungen stehen lassen, eventuell den Speicherplatz für den Daten-
träger auf 60 oder mehr GB erhöhen (sofern genügend Platz auf dem System zur Verfügung steht).
Anschließend wieder die Taste „Vor“ anklicken.
e) Installation beginnen
Wichtig: Hier einen Haken bei „Konfiguration bearbeiten vor der Installation“ setzen und danach die Taste
„Fertig“ anklicken.
Jetzt erscheint das Fenster zum Start der Installation.
Bevor man damit beginnt sind noch einige Einstellungen vorzunehmen.
Der Reihe nach wären das wie auf den nachfolgenden Bildern gezeigt:
Die Firmware von BIOS auf UEFI... umzustellen:
Die CPU und den Arbeitsspeicher (RAM) zu konfigurieren:
Die Bootreihenfolge (Reihenfolge der Startgeräte) festlegen, dazu einen Haken bei SATA CDROM1 setzen
und das CDROM Laufwerk mittels Pfeiltasten an erster Stelle setzen.
[Generell empfiehlt es sich, ebenfalls einen Haken bei „Startmenü aktivieren“ zu setzen.]
Anschließend erfolgt das Hinzufügen der durchzureichenden Grafikkarte und deren Audiochip über
den Button „Gerät hinzufügen“ und dann die Auswahl der Geräte unter PCI Host-Gerät.
[Hinweis: Das Hinzufügen von Grafikkarte und Audiochip kann auch nachträglich, nach der Installa-
tion des Betriebssystem, erfolgen.]
1. Grafikkarte auswählen und auf "Fertig" klicken, danach
2. das gleiche nochmals für den Audiochip, der auf der Grafikkarte verbaut ist, ausführen.
Nach dem Hinzufügen von Grafikkarte und Audio Chip kann die Installation der VM gestartet werden indem man auf das Feld „Installation beginnen“ klickt.
Die Installation beginnt und die VM will von dem virtuellen CDROM Laufwerk booten. Jetzt muss man
schnell sein und eine Taste auf der Tastatur betätigen damit die Installation per CDROM in der VM erfolgen
kann.
Verpasst man den Zeitpunkt des Tastendrucks, dann landet man im BIOS der VM. Diese verläßt man
wieder durch Anwahl von „Continue“ und die Abfrage des Tastendrucks erfolgt von neuem. Nach Betätigen
der selbigen beginnt eine normale Windows Installation.
Hinweis: Nicht vergessen unter "Anzeigen" den Menüpunkt "Console" anwählen, damit der Installations-
bildschirm zu sehen ist!
Nach erfolgreicher Installation wird man in der Konsole vom Windows Desktop begrüßt.
Zum jetzigen Zeitpunkt läuft Windows nur in der Konsole. Um das zu ändern muss der Treiber der
dedizierten Grafikkarte installiert werden. D.h. den Treiber (hier Nvidia) der durchgereichten Grafikkarte
in der VM von der Herstellerseite downloaden und dort installieren. Nach Installation des Treibers wird jetzt
auch die dedizierte Grafikkarte angesteuert und auf dem zweiten Bildschirm erscheint jetzt der Windows
Desktop (wenn die Grafikkarte zuvor in die VM durchgereicht wurde).
In dieser Konfigutation muss man immer zuerst auf den Desktop in der Konsole klicken, damit ein Arbeiten
in der VM auf dem zweiten Bildschirm überhaupt möglich ist. Dieser Zustand ändert sich,wenn die Einträge
für die emulierte Grafikkarte aus der Maschinenkonfiguration der VM entfernt werden („Konsole“, „Anzeige
Spice“, „Video QXL“). Beim nachfolgenden Neustart der VM wird diese jetzt nur noch auf der dedizitieren
Grafikkarte gestartet. [Dazu ist dann etwas Geduld notwendig, es dauert einen Moment bis quasi der
zweite Rechner hochgefahren ist]
Jetzt wäre es allerdings auch notwendig eine zweite Maus / Tastatur in die VM durchzureichen, damit
sowohl Host als auch VM gleichzeitig bedient werden können. Das läßt sich z.B. mit einem KVM Switch
(mit zusätzlichen Kosten) umgehen.
Oder man löst das Problem per Software, z.B. mittels Evdev. Um was es sich bei Evdev handelt wird auf
der Seite passthroughpo.st unter dem nachfolgenden Link5 erklärt.
Jetzt kann mit dem Einrichten einer Windows 10 VM begonnen werden. Dazu wird ein Windows
10 ISO-Abbild benötigt. Falls das nicht schon vorhanden ist, dann sollte jetzt ein ISO-Abbild von
der Microsoft Homepage herunter geladen werden (Link4).
Um eine virtuelle Maschine aufzusetzen ist nun die virtuelle Maschinenverwaltung über die Desktop-
oberfläche des Hostsystems zu starten.
Nach dem Start sollte in der Maschinenverwaltung unter dem Menüpunkt
Bearbeiten -> Einstellungen
der Haken an „Enable XML editing“ gesetzt werden. Somit ist es später möglich den XML Code der
VM zwecks Anpassungen zu bearbeiten.
Die eigentliche Erstellung einer VM gestaltet sich wie folgt:
a) Unter Datei den Menüpunkt „Neue virtuelle Maschine“ anwählen.
Die Vorauswahl „Lokales Installationsmedium (ISO-Abbild oder CDROM)“ stehen lassen und auf
den Button „Vor“ klicken.
b) Das Installationsmedium auswählen.
Dazu auf „Durchsuchen“ klicken und das vorher herunter geladene ISO-Abbild von Windows 10
auswählen. Anschließend wieder die Taste „Vor“ anklicken.
c) Speicher (RAM) und CPU Settings.
Die Voreinstellungen für Speicher und CPU stehen lassen, diese können noch im späteren Verlauf
angepasst werden. Daher wieder die Taste „Vor“ anklicken.
d) Speicherplatz für die virtuelle Maschine einrichten
Für erste Versuche die Voreinstellungen stehen lassen, eventuell den Speicherplatz für den Daten-
träger auf 60 oder mehr GB erhöhen (sofern genügend Platz auf dem System zur Verfügung steht).
Anschließend wieder die Taste „Vor“ anklicken.
e) Installation beginnen
Wichtig: Hier einen Haken bei „Konfiguration bearbeiten vor der Installation“ setzen und danach die Taste
„Fertig“ anklicken.
Jetzt erscheint das Fenster zum Start der Installation.
Bevor man damit beginnt sind noch einige Einstellungen vorzunehmen.
Der Reihe nach wären das wie auf den nachfolgenden Bildern gezeigt:
Die Firmware von BIOS auf UEFI... umzustellen:
Die CPU und den Arbeitsspeicher (RAM) zu konfigurieren:
Die Bootreihenfolge (Reihenfolge der Startgeräte) festlegen, dazu einen Haken bei SATA CDROM1 setzen
und das CDROM Laufwerk mittels Pfeiltasten an erster Stelle setzen.
[Generell empfiehlt es sich, ebenfalls einen Haken bei „Startmenü aktivieren“ zu setzen.]
Anschließend erfolgt das Hinzufügen der durchzureichenden Grafikkarte und deren Audiochip über
den Button „Gerät hinzufügen“ und dann die Auswahl der Geräte unter PCI Host-Gerät.
[Hinweis: Das Hinzufügen von Grafikkarte und Audiochip kann auch nachträglich, nach der Installa-
tion des Betriebssystem, erfolgen.]
1. Grafikkarte auswählen und auf "Fertig" klicken, danach
2. das gleiche nochmals für den Audiochip, der auf der Grafikkarte verbaut ist, ausführen.
Nach dem Hinzufügen von Grafikkarte und Audio Chip kann die Installation der VM gestartet werden indem man auf das Feld „Installation beginnen“ klickt.
Die Installation beginnt und die VM will von dem virtuellen CDROM Laufwerk booten. Jetzt muss man
schnell sein und eine Taste auf der Tastatur betätigen damit die Installation per CDROM in der VM erfolgen
kann.
Verpasst man den Zeitpunkt des Tastendrucks, dann landet man im BIOS der VM. Diese verläßt man
wieder durch Anwahl von „Continue“ und die Abfrage des Tastendrucks erfolgt von neuem. Nach Betätigen
der selbigen beginnt eine normale Windows Installation.
Hinweis: Nicht vergessen unter "Anzeigen" den Menüpunkt "Console" anwählen, damit der Installations-
bildschirm zu sehen ist!
Nach erfolgreicher Installation wird man in der Konsole vom Windows Desktop begrüßt.
Zum jetzigen Zeitpunkt läuft Windows nur in der Konsole. Um das zu ändern muss der Treiber der
dedizierten Grafikkarte installiert werden. D.h. den Treiber (hier Nvidia) der durchgereichten Grafikkarte
in der VM von der Herstellerseite downloaden und dort installieren. Nach Installation des Treibers wird jetzt
auch die dedizierte Grafikkarte angesteuert und auf dem zweiten Bildschirm erscheint jetzt der Windows
Desktop (wenn die Grafikkarte zuvor in die VM durchgereicht wurde).
In dieser Konfigutation muss man immer zuerst auf den Desktop in der Konsole klicken, damit ein Arbeiten
in der VM auf dem zweiten Bildschirm überhaupt möglich ist. Dieser Zustand ändert sich,wenn die Einträge
für die emulierte Grafikkarte aus der Maschinenkonfiguration der VM entfernt werden („Konsole“, „Anzeige
Spice“, „Video QXL“). Beim nachfolgenden Neustart der VM wird diese jetzt nur noch auf der dedizitieren
Grafikkarte gestartet. [Dazu ist dann etwas Geduld notwendig, es dauert einen Moment bis quasi der
zweite Rechner hochgefahren ist]
Jetzt wäre es allerdings auch notwendig eine zweite Maus / Tastatur in die VM durchzureichen, damit
sowohl Host als auch VM gleichzeitig bedient werden können. Das läßt sich z.B. mit einem KVM Switch
(mit zusätzlichen Kosten) umgehen.
Oder man löst das Problem per Software, z.B. mittels Evdev. Um was es sich bei Evdev handelt wird auf
der Seite passthroughpo.st unter dem nachfolgenden Link5 erklärt.
Maus und Tastatur, die per USB-Schnittstelle an den Host Rechner angeschlossen sind, lassen sich per
Evdev wechselweise sowohl in einer VM als auch im darunter liegenden Hostsystem nutzen.
Dazu müssen zuerst die Geräte-IDs der am Hostsystem angeschlossenen Maus /Tastatur ermittelt werden. Das geht folgendermaßen:
a) In einem Terminal folgendes eingeben:
Darauf erscheint (bei dem System hier) folgende Ausgabe:
usb-0566_3032-event-if01 usb-275d_USB_OPTICAL_MOUSE-event-mouse
usb-0566_3032-event-kbd usb-275d_USB_OPTICAL_MOUSE-mouse
Benötigt werden die Angaben die "event" im Namen enthalten. Ignoriert werden Geräte-ID´s
die If01 oder If02 usw. enthalten.
b) Jetzt per Terminal (als Root) die Datei
mit dem Editor der Wahl
öffnen und die nachfolgende Passage
cgroup_device_acl = [
"/dev/null", "/dev/full", "/dev/zero",
"/dev/random", "/dev/urandom",
"/dev/ptmx", "/dev/kvm", "/dev/kqemu",
"/dev/rtc","/dev/hpet",
"/dev/input/by-id/usb-0566_3032-event-kbd",
"/dev/input/by-id/usb-275d_USB_OPTICAL_MOUSE-event-mouse",
]
user = "root"
group = "root"
clear_emulator_capabilities = 0
security_default_confined = 0
am Ende einfügen und speichern.
Anschliesend im Terminal mit
libvirtd neu starten.
c) Jetzt in der virtuellen Maschinenverwaltung, in der XML Ansicht, die erste Zeile
durch
ersetzen.
Anschließend, ganz am Ende, vor </domain> folgendes einfügen
<qemu:commandline>
<qemu:arg value='-object'/>
<qemu:arg value='input-linux,id=kbd1,evdev=/dev/input/by-id/usb-0566_3032-event-kbd,grab_all=on,repeat=on'/>
<qemu:arg value='-object'/>
<qemu:arg value='input-linux,id=mouse1,evdev=/dev/input/by-id/usb-275d_USB_OPTICAL_MOUSE-event-mouse'/>
</qemu:commandline>
und mit dem Anklicken von „Anwenden“ übernehmen.
Wird die virtuelle Maschine jetzt gestartet geht die Kontrolle von Maus und Tastatur sofort
an die VM über. D.h. jetzt ist es möglich in der Windows VM mit Maus und Tastatur zu arbeiten.
Werden Maus und Tastatur wieder auf dem Host System benötigt, dann kann mit dem gleich-
zeitigen Betätigen der beiden Steuerungstasten [Strg] auf der Tastatur von der VM auf das Host
System umgeschaltet werden.Das ganze funktioniert wechselseitig, damit wird das bequeme
Umschalten von Maus und Tastatur zwischen VM und Host einfach möglich.
Möchte man das ganze nicht mit root Rechten ausführen lassen, dann kann folgendermaßen vor-
gegangen werden um das zu verhindern. Nämlich indem man einen neuen Nutzer/Gruppe anlegt,
z.B. „evdev“. In einem Terminal Fenster also folgendes eingeben :
[root@localhost vm]# useradd -s /usr/sbin/nologin -r -M -d /dev/null evdev
[root@localhost vm]# groupadd evdev
[root@localhost vm]# usermod -a -G input evdev
Damit hat man einen Nutzer angelegt, der kein Homeverzeichnis hat und sich nicht über eine
Login Shell anmelden kann. Zusätzlich wurde der Nutzer „evdev“ zur input Gruppe hinzugefügt.
Jetzt muss noch die Datei /etc/libvirt/qemu.conf
folgendermaßen angepasst werden:
user = "evdev"
group = "evdev"
d.h. aus
user = "root" und group = "root"
wird jetzt
user = "evdev", group = "evdev"
Danach die VM neu starten.
Wenn sich jetzt noch Probleme mit Zugriffsberechtigungen ergeben, dann kann man noch
folgende Anweisung in die qemu.conf einfügen:
clear_emulator_capabilities = 0
Hinweis 1: Eine Alternative zu EvDev wäre z.B. die Verwendung von Barrier, sofern nicht Wayland
benutzt wird, d.h. Barrier läuft auf der Linux Seite nur unter X11.
Hinweis 2: Laut der Quelle gibt es Probleme mit Pulseaudio falls man evdev nutzt. Tatsächlich
war es nicht möglich mittels Pulseaudio einer Arco Linux VM irgend einen Ton zu entlocken.
Link: https://passthroughpo.st/using-evdev-passthrough-seamless-vm-input/
Evdev wechselweise sowohl in einer VM als auch im darunter liegenden Hostsystem nutzen.
Dazu müssen zuerst die Geräte-IDs der am Hostsystem angeschlossenen Maus /Tastatur ermittelt werden. Das geht folgendermaßen:
a) In einem Terminal folgendes eingeben:
[vm@localhost ~]$ ls /dev/input/by-idDarauf erscheint (bei dem System hier) folgende Ausgabe:
usb-0566_3032-event-if01 usb-275d_USB_OPTICAL_MOUSE-event-mouse
usb-0566_3032-event-kbd usb-275d_USB_OPTICAL_MOUSE-mouse
Benötigt werden die Angaben die "event" im Namen enthalten. Ignoriert werden Geräte-ID´s
die If01 oder If02 usw. enthalten.
b) Jetzt per Terminal (als Root) die Datei
/etc/libvirt/qemu.confmit dem Editor der Wahl
[root@localhost vm]# nano /etc/libvirt/qemu.conföffnen und die nachfolgende Passage
cgroup_device_acl = [
"/dev/null", "/dev/full", "/dev/zero",
"/dev/random", "/dev/urandom",
"/dev/ptmx", "/dev/kvm", "/dev/kqemu",
"/dev/rtc","/dev/hpet",
"/dev/input/by-id/usb-0566_3032-event-kbd",
"/dev/input/by-id/usb-275d_USB_OPTICAL_MOUSE-event-mouse",
]
user = "root"
group = "root"
clear_emulator_capabilities = 0
security_default_confined = 0
am Ende einfügen und speichern.
Anschliesend im Terminal mit
[root@localhost vm]# systemctl restart libvirtdlibvirtd neu starten.
c) Jetzt in der virtuellen Maschinenverwaltung, in der XML Ansicht, die erste Zeile
<domain type="kvm">
durch
<domain type='kvm' id='1' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
ersetzen.
Anschließend, ganz am Ende, vor </domain> folgendes einfügen
<qemu:commandline>
<qemu:arg value='-object'/>
<qemu:arg value='input-linux,id=kbd1,evdev=/dev/input/by-id/usb-0566_3032-event-kbd,grab_all=on,repeat=on'/>
<qemu:arg value='-object'/>
<qemu:arg value='input-linux,id=mouse1,evdev=/dev/input/by-id/usb-275d_USB_OPTICAL_MOUSE-event-mouse'/>
</qemu:commandline>
und mit dem Anklicken von „Anwenden“ übernehmen.
Wird die virtuelle Maschine jetzt gestartet geht die Kontrolle von Maus und Tastatur sofort
an die VM über. D.h. jetzt ist es möglich in der Windows VM mit Maus und Tastatur zu arbeiten.
Werden Maus und Tastatur wieder auf dem Host System benötigt, dann kann mit dem gleich-
zeitigen Betätigen der beiden Steuerungstasten [Strg] auf der Tastatur von der VM auf das Host
System umgeschaltet werden.Das ganze funktioniert wechselseitig, damit wird das bequeme
Umschalten von Maus und Tastatur zwischen VM und Host einfach möglich.
Möchte man das ganze nicht mit root Rechten ausführen lassen, dann kann folgendermaßen vor-
gegangen werden um das zu verhindern. Nämlich indem man einen neuen Nutzer/Gruppe anlegt,
z.B. „evdev“. In einem Terminal Fenster also folgendes eingeben :
[root@localhost vm]# useradd -s /usr/sbin/nologin -r -M -d /dev/null evdev
[root@localhost vm]# groupadd evdev
[root@localhost vm]# usermod -a -G input evdev
Damit hat man einen Nutzer angelegt, der kein Homeverzeichnis hat und sich nicht über eine
Login Shell anmelden kann. Zusätzlich wurde der Nutzer „evdev“ zur input Gruppe hinzugefügt.
Jetzt muss noch die Datei /etc/libvirt/qemu.conf
folgendermaßen angepasst werden:
user = "evdev"
group = "evdev"
d.h. aus
user = "root" und group = "root"
wird jetzt
user = "evdev", group = "evdev"
Danach die VM neu starten.
Wenn sich jetzt noch Probleme mit Zugriffsberechtigungen ergeben, dann kann man noch
folgende Anweisung in die qemu.conf einfügen:
clear_emulator_capabilities = 0
Hinweis 1: Eine Alternative zu EvDev wäre z.B. die Verwendung von Barrier, sofern nicht Wayland
benutzt wird, d.h. Barrier läuft auf der Linux Seite nur unter X11.
Hinweis 2: Laut der Quelle gibt es Probleme mit Pulseaudio falls man evdev nutzt. Tatsächlich
war es nicht möglich mittels Pulseaudio einer Arco Linux VM irgend einen Ton zu entlocken.
Link: https://passthroughpo.st/using-evdev-passthrough-seamless-vm-input/
An einigen Stellen wird hier darauf hingewiesen, dass es notwendig ist, Secure Boot im Bios der
virtuellen Maschine auszuschalten (insbesondere bei Verwendung von Virtio Treibern).
Wie geht das? Nun, ziemlich einfach, es muss nur sofort nach dem Starten der VM die Taste F2
mehrfach betätigt werden. Dann wird ähnlich wie bei einem normalen PC das BIOS der VM aufgerufen.
Wichtig ist hierbei, das die VM (noch oder wieder) in der Konsolenansicht läuft.
Das ganze sieht danach (in der Konsolenansicht) dann folgenermaßen aus:
Jetzt mit den Pfeiltasten der Tastatur auf den Eintrag Device Manager wechseln und mit der Enter
Taste bestätigen. Dann zeigt sich folgendes Bild:
Die Secure Boot Configuration anwählen und das [X] im Menüpunkt Attempt Secure Boot
abwählen (mit der Space- bzw. Leer-Taste).
Die so geänderte Einstellung dann mit der Taste F10 speichern (und mit der Z-Taste bestätigen
[bei einem deutschen Tastaturlayout]).
Diese Beschreibung funktioniert sofern die VM in der Konsole läuft. Wurde die VM bereits mit
durchgereichter Grafikkarte betrieben, dann war das Aufrufen des BIOS in der VM so nicht mehr
möglich.
Deshalb muss temporär die Videoausgabe (wieder) per SPICE Server erfolgen. Dazu in der vir-
tuellen Maschinenverwaltung die Taste „Gerät hinzufügen“ anklicken, dann den Eintrag Grafik
anwählen und als virtuelles Gerät den SPICE-Server auswählen.
Anschließend den neuen Eintrag Video Cirrus nach Virtio umstellen.
Jetzt noch eine Konsole zur Ausgabe hinzufügen.
Hinweis: Wird Evdev zur gemeinsamen Benutzung von Maus und Tastatur in VM und Host benutzt,
dann den entsprechenden Eintrag löschen (damit die VM in der Konsolenansicht bedient werden kann).
Jetzt zur grafischen Konsole wechseln, die VM starten, mit der Maus auf das Feld der Konsolen-
ausgabe klicken und dann sofort die Taste F2 betätigen.
Kommt man jetzt nicht ins BIOS und die VM hängt sich scheinbar auf,
dann „Zurücksetzen erzwingen“ anwählen,
die VM neu starten, wieder auf der Feld der Konsoleausgabe klicken, Taste F2 betätigen, jetzt
sollte in der Konsolenansicht das VM BIOS zu sehen sein.
Hinweis: Die Maus läßt sich mit der Tastenkombination STRG + Alt + L wieder aus der Konsole
lösen.
Wurden alle Änderungen im BIOS durchgeführt, dann können die Einträge für „Anzeige Spice“,
„Video Virtio“, „SATA CDROM 1“ und „Console 1“ wieder aus der virtuellen Maschinenver-
waltung gelöscht werden.
Soll Evdev wieder genutzt werden, dann kann es wie im Kapitel
„Optionen: Maus und Tastatur gemeinsam in VM und Hostsystem nutzen“
unter Punkt c) beschrieben, wieder eingerichtet werden.
virtuellen Maschine auszuschalten (insbesondere bei Verwendung von Virtio Treibern).
Wie geht das? Nun, ziemlich einfach, es muss nur sofort nach dem Starten der VM die Taste F2
mehrfach betätigt werden. Dann wird ähnlich wie bei einem normalen PC das BIOS der VM aufgerufen.
Wichtig ist hierbei, das die VM (noch oder wieder) in der Konsolenansicht läuft.
Das ganze sieht danach (in der Konsolenansicht) dann folgenermaßen aus:
Jetzt mit den Pfeiltasten der Tastatur auf den Eintrag Device Manager wechseln und mit der Enter
Taste bestätigen. Dann zeigt sich folgendes Bild:
Die Secure Boot Configuration anwählen und das [X] im Menüpunkt Attempt Secure Boot
abwählen (mit der Space- bzw. Leer-Taste).
Die so geänderte Einstellung dann mit der Taste F10 speichern (und mit der Z-Taste bestätigen
[bei einem deutschen Tastaturlayout]).
Diese Beschreibung funktioniert sofern die VM in der Konsole läuft. Wurde die VM bereits mit
durchgereichter Grafikkarte betrieben, dann war das Aufrufen des BIOS in der VM so nicht mehr
möglich.
Deshalb muss temporär die Videoausgabe (wieder) per SPICE Server erfolgen. Dazu in der vir-
tuellen Maschinenverwaltung die Taste „Gerät hinzufügen“ anklicken, dann den Eintrag Grafik
anwählen und als virtuelles Gerät den SPICE-Server auswählen.
Anschließend den neuen Eintrag Video Cirrus nach Virtio umstellen.
Jetzt noch eine Konsole zur Ausgabe hinzufügen.
Hinweis: Wird Evdev zur gemeinsamen Benutzung von Maus und Tastatur in VM und Host benutzt,
dann den entsprechenden Eintrag löschen (damit die VM in der Konsolenansicht bedient werden kann).
Jetzt zur grafischen Konsole wechseln, die VM starten, mit der Maus auf das Feld der Konsolen-
ausgabe klicken und dann sofort die Taste F2 betätigen.
Kommt man jetzt nicht ins BIOS und die VM hängt sich scheinbar auf,
dann „Zurücksetzen erzwingen“ anwählen,
die VM neu starten, wieder auf der Feld der Konsoleausgabe klicken, Taste F2 betätigen, jetzt
sollte in der Konsolenansicht das VM BIOS zu sehen sein.
Hinweis: Die Maus läßt sich mit der Tastenkombination STRG + Alt + L wieder aus der Konsole
lösen.
Wurden alle Änderungen im BIOS durchgeführt, dann können die Einträge für „Anzeige Spice“,
„Video Virtio“, „SATA CDROM 1“ und „Console 1“ wieder aus der virtuellen Maschinenver-
waltung gelöscht werden.
Soll Evdev wieder genutzt werden, dann kann es wie im Kapitel
„Optionen: Maus und Tastatur gemeinsam in VM und Hostsystem nutzen“
unter Punkt c) beschrieben, wieder eingerichtet werden.
Wer eine VM lieber auf ein eigenes Laufwerk statt in einer Imagedatei installieren möchte, der geht
beim Aufsetzen dieser VM folgendermaßen vor:
Im Kapitel "Grundlegende Installation - VM einrichten" wird unter Punkt:
„d) Speicherplatz für die virtuelle Maschine einrichten“ beschrieben, wie man ein Image
zur Installation einer VM erstellt.
Soll nun, statt auf einem Datenträger Image, die VM auf einem eigenen Laufwerk installiert werden,
dann wählt man [Benutzerdefinierten Speicher auswählen oder erstellen] an und trägt dort das Lauf-
werk ein, daß für die virtuelle Maschine verwendet werden soll.
Das wäre auf dem System hier: /dev/sda.
Anschließend wird die Installation wie in "Grundlegende Installation - VM einrichten" unter
"e) Installation beginnen" beschrieben weiter fortgesetzt.
beim Aufsetzen dieser VM folgendermaßen vor:
Im Kapitel "Grundlegende Installation - VM einrichten" wird unter Punkt:
„d) Speicherplatz für die virtuelle Maschine einrichten“ beschrieben, wie man ein Image
zur Installation einer VM erstellt.
Soll nun, statt auf einem Datenträger Image, die VM auf einem eigenen Laufwerk installiert werden,
dann wählt man [Benutzerdefinierten Speicher auswählen oder erstellen] an und trägt dort das Lauf-
werk ein, daß für die virtuelle Maschine verwendet werden soll.
Das wäre auf dem System hier: /dev/sda.
Anschließend wird die Installation wie in "Grundlegende Installation - VM einrichten" unter
"e) Installation beginnen" beschrieben weiter fortgesetzt.
Man kann für die Laufwerksansteuerung (Datenträgeranbindung) einer Windows VM statt SATA auch VirtIO
verwenden, weil diese Betriebsart die bessere Performance verspricht.
Dazu müssen die virtio-Treiber bei der Windows Installation geladen werden, das ganze wird dann
folgendermaßen umgesetzt:
Zuerst ist bei der Erstellung der VM die Laufwerksansteuerung von SATA auf VirtIO umzustellen.
Danach werden die Virtio Treiber benötigt, die man hier LINK finden kann (virtio-win.iso). Nach
dem Download muss die ISO Datei als zusätzliches CDROM Laufwerk zur Windows VM hinzu-
gefügt werden, um bei der Windows Installation die notwendigen Treiber laden zu können.
Beim anschließenden Start der VM Installation muss gleich zu Beginn des Startprozesses ins BIOS
der VM gewechselt werden, um dort Secure Boot auszuschalten.
(Secure Boot auszuschalten ist deshalb notwendig, weil Microsoft vor einiger Zeit die Reglen für das
Signieren von Treibern verschärft hat)
Wurde die VM-Installation gestartet, wird das Windows Setup zunächst kein Laufwerk für die Installtion
finden.
Das liegt daran, das als Festplattenbus VirtIO aus-
gewählt wurde. Deshalb muß als nächstes [Treiber
laden] angeklickt und das zuvor eingebundene CD-
Laufwerk mit dem virtio-win-0.1.x.x.iso ausgewählt
werden.
Jetzt den Treiber auswählen, dazu viostor -> win10 ->amd64 anwählen und fortfahren.
Das Laufwerk sollte nach kurzer Zeit erkannt werden und die Installation von Windows 10 kann
wie gewohnt fortgesetzt werden.
Nachtrag: Wer die Windows 10 VM nicht mit dauerhaft ausgeschaltenem Secure Boot betreiben möchte,
kann nach erfolgter Installation von Windows 10 den nachfolgenden Registey-Eintrag im Windows der VM
per Regedit anlegen:
Damit wird dem in der VM laufenden Windows suggeriert, daß es eine geupgratete Version ist.
Selbige läßt nämlich sogenannte "cross-signed kernel driver" zu. D.h. nach dem Anlegen dieses
Registery Eintrags kann nach einem Reboot der VM die Einstellung Secure Boot wieder im BIOS
der VM zugeschaltet werden.
verwenden, weil diese Betriebsart die bessere Performance verspricht.
Dazu müssen die virtio-Treiber bei der Windows Installation geladen werden, das ganze wird dann
folgendermaßen umgesetzt:
Zuerst ist bei der Erstellung der VM die Laufwerksansteuerung von SATA auf VirtIO umzustellen.
Danach werden die Virtio Treiber benötigt, die man hier LINK finden kann (virtio-win.iso). Nach
dem Download muss die ISO Datei als zusätzliches CDROM Laufwerk zur Windows VM hinzu-
gefügt werden, um bei der Windows Installation die notwendigen Treiber laden zu können.
Beim anschließenden Start der VM Installation muss gleich zu Beginn des Startprozesses ins BIOS
der VM gewechselt werden, um dort Secure Boot auszuschalten.
(Secure Boot auszuschalten ist deshalb notwendig, weil Microsoft vor einiger Zeit die Reglen für das
Signieren von Treibern verschärft hat)
Wurde die VM-Installation gestartet, wird das Windows Setup zunächst kein Laufwerk für die Installtion
finden.
Das liegt daran, das als Festplattenbus VirtIO aus-
gewählt wurde. Deshalb muß als nächstes [Treiber
laden] angeklickt und das zuvor eingebundene CD-
Laufwerk mit dem virtio-win-0.1.x.x.iso ausgewählt
werden.
Jetzt den Treiber auswählen, dazu viostor -> win10 ->amd64 anwählen und fortfahren.
Das Laufwerk sollte nach kurzer Zeit erkannt werden und die Installation von Windows 10 kann
wie gewohnt fortgesetzt werden.
Nachtrag: Wer die Windows 10 VM nicht mit dauerhaft ausgeschaltenem Secure Boot betreiben möchte,
kann nach erfolgter Installation von Windows 10 den nachfolgenden Registey-Eintrag im Windows der VM
per Regedit anlegen:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI\Policy]
"UpgradedSystem"=dword:00000001
Damit wird dem in der VM laufenden Windows suggeriert, daß es eine geupgratete Version ist.
Selbige läßt nämlich sogenannte "cross-signed kernel driver" zu. D.h. nach dem Anlegen dieses
Registery Eintrags kann nach einem Reboot der VM die Einstellung Secure Boot wieder im BIOS
der VM zugeschaltet werden.
Beim Betrieb einer Windows VM auf einer eigenen Partition oder Laufwerk kann es manchmal
nützlich sein, wenn man vom Linux Host System aus auf diese Laufwerke zugreifen kann.
Warnung: Niemals gleichzeitig mit 2 Betriebssystemen auf den selben Datenträger zugreifen!
Ansonsten kann man zu 100% von Datenverlust ausgegehen. D.h. wenn die Windows VM
läuft sollte auf keinen Fall vom Hostsystem aus auf deren Datenträger zugegriffen werden!
Das bedeutetd auch, während die VM läuft darf die entsprechende Partition bzw. das Laufwerk
nicht am Host System gemountet werden!
Um also vom Linux Host System auf NTFS Dateisysteme zugreifen zu können, muss der ntfs-3g
Treiber installiert werden. Das erfolgt als User mit root-Rechten in einem Terminal:
Schritt 1: Das Linux System updaten
Schritt 2: Das EPEL repository aktivieren
Schritt 3: Den ntfs-3g Treiber installieren
Schritt 4: Zuletzt kann man noch das Paket ntfsprogs installieren. Darin sind diverse Utilities rund
um das NTFS Dateisystem enthalten.
Welche Funktionen die einzelnen Utilities mitbringen kann man sich von der zugehörigen man page
anzeigen lassen.
nützlich sein, wenn man vom Linux Host System aus auf diese Laufwerke zugreifen kann.
Warnung: Niemals gleichzeitig mit 2 Betriebssystemen auf den selben Datenträger zugreifen!
Ansonsten kann man zu 100% von Datenverlust ausgegehen. D.h. wenn die Windows VM
läuft sollte auf keinen Fall vom Hostsystem aus auf deren Datenträger zugegriffen werden!
Das bedeutetd auch, während die VM läuft darf die entsprechende Partition bzw. das Laufwerk
nicht am Host System gemountet werden!
Um also vom Linux Host System auf NTFS Dateisysteme zugreifen zu können, muss der ntfs-3g
Treiber installiert werden. Das erfolgt als User mit root-Rechten in einem Terminal:
Schritt 1: Das Linux System updaten
[root@localhost vm]# dnf -y updateSchritt 2: Das EPEL repository aktivieren
[root@localhost vm]# dnf install epel-releaseSchritt 3: Den ntfs-3g Treiber installieren
[root@localhost vm]# dnf install epel-releaseSchritt 4: Zuletzt kann man noch das Paket ntfsprogs installieren. Darin sind diverse Utilities rund
um das NTFS Dateisystem enthalten.
[root@localhost vm]# dnf install ntfsprogsWelche Funktionen die einzelnen Utilities mitbringen kann man sich von der zugehörigen man page
anzeigen lassen.
[vm@localhost ~]$ man ntfsprogsBei Scream handelt es sich um eine virtuelle Netzwerk Soundkarte, genauer gesagt laut Übersetzung
der Funktionsbeschreibung auf der Projektseite Link1:
„Scream ist ein virtueller Gerätetreiber für Windows, der ein separates Soundgerät bereitstellt. Über
dieses Gerät wiedergegebenes Audio wird in Ihrem lokalen Netzwerk als PCM-Multicast-Stream ver-
öffentlicht. Empfänger im Netzwerk können den Stream aufnehmen und über ihre eigenen Audioaus-
gänge wiedergeben. Empfänger sind für Unix/Linux (mit Schnittstelle zu PulseAudio oder ALSA)
und für Windows erhältlich.“
Um Scream einsetzen zu können ist wie nachfolgend beschrieben vorzugehen:
a) Netzwerkeinstellungen der virtuellen Maschinenverwaltung
Die Netzwerkeinstellung der virtuellen Maschinenverwaltung müssen auf default stehen. Außerdem
ist es notwendig, dass der Haken bei Autostart [beim Start] gesetzt ist.
b) Die Einstellungen der virtuellen Netzwerkschnittstelle in der VM sollten folgendermaßen aussehen:
Als virtuelle Netzwerkschnittstellle muß virtio
verwendet werden, als Brückenname wird
(vom Autor hier) virbr0 vergeben.
c) Als nächstes werden die Windows Treiber für die virtuelle Netzwerkkarte in der VM benötigt.
Die findet man in der virtio-win.iso, welche von dieser Seite Link2 bezogen werden kann. Das
ISO-Abbild wird dann als CDROM Laufwerk in die VM eingebunden.
Bevor man die Treiber in der VM installieren kann, muss noch folgendes beachtet werden:
Microsoft hat für neuere Versionen von Windows 10 (ab 1607) die Regeln für das Signieren von
Kernelmodustreibern verschärft. Das läßt sich auf zweierlei Wegen umgehen:
1) Secure boot im BIOS der Windows VM ausschalten, oder
2) In der Windows VM folgenden Eintrag in der Registery anlegen:
(siehe Projektseite Scream, d.h. das muss vor der Installation des Windows Treibers geschehen,
damit erkennt sich das Windows in der VM als Upgrade-Version, was die Installation von
„cross-signed kernel driver" möglich macht).
Zusammengefasst heißt das, in der Windows VM muss zuerst entweder Secure boot ausge-
schaltet oder der oben beschriebene Registery Eintrag muss angelegt werden bevor der nächste
Installationsschritt erfolgen kann (siehe hierzu auch GPU-Passtrough-Teil-07).
d) Jetzt die Windows VM erneut starten und darin den Geräte Manager öffnen. Dort wird unter
„Andere Geräte“ ein Ethernet-Contoller ohne Treiber angezeigt. Für diesen muß jetzt der Virtio
Netzwerktreiber installiert werden. D.h.
werkadapter ein Red Hat VirtIO Ethernet Adapter.
e) Nun wird Scream für die Installation in der VM benötigt. Dazu die VM starten, in der VM
den Browser aufrufen und unter folgendem Link3 Scream3.x.zip downloaden. Anschließend
Scream3.x.zip entpacken. Mit dem Windows Explorer den entpackten Ordner Scream3.x
öffnen, dann wechseln zum Verzeichnis Install und dort mit Rechtsklick auf Install-x64 das
ganze als Administrator ausführen um die Installation durchzuführen. Nach erfolgter Instal-
lation kann in den Windows Einstellungen die Soundausgabe auf „Lautsprecher (Scream
(WDM))“ umgestellt werden. Anschließend die Windows VM wieder herunter fahren.
f) Scream Empfänger (Receiver) für den Linux Host bauen
Ein Scream Linux Receiver ist nicht als fertiges Paket erhältlich, sondern den muss man sich
selbst bauen. Bevor das möglich ist, müssen einige Werkzeuge und Bibliotheken geladen und
installiert werden.
Nach Lesen der Readme benötigen wir dazu libpcap-devel, pulseaudio-libs-devel, alsa-lib-devel, cmake,
make und damit auch gcc. Installiert wird das ganze (als root) mit :
Da sich libpcap-devel im Repostorie Powertools befindet wird es mit
installiert.
Jetzt von Link1 noch (Scream-) master.zip downloaden und entpacken. Nach dem entpacken
im so erzeugten Verzeichnis scream-master/Receivers/unix/ ein Terminalfenster öffnen. Hier
ein neues Verzeichnis build erzeugen,
dann nach build wechseln
und zuerst
danach
ausführen. Dadurch hat man nun das Programm scream im Verzeichnis build erzeugt.
Um das Programm starten zu können (d.h. ausführbar), noch
als root in der Konsole ausführen.
Anschließend das Scream Programm nach /usr/bin/ verschieben
Da Scream in Almalinux durch die Firewall geblockt wird muss noch ein Port geöffnet werden.
[root@localhost vm]# firewall-cmd --permanent --zone=libvirt --add-port=4010/udp
Danach das Host System neu starten.
Gestartet wird das ganze dann in einem Terminal mit
(virbr0 ist der Brückenname der unter Punkt b) „Einstellungen der virtuellen Netzwerkschnitt-
stelle“ vergeben wurde.)
Ob Scream auf dem Host läuft kann man dann in den Audio Einstellungen unter Anwendungen
sehen:
Solange jetzt Scream auf dem Host läuft, werden die Soundausgaben der Windows VM auf den Audio-
ausgängen des Host Systems wiedergegeben.
Im angegeben Link4 findet man noch optionale Einstellungen bezüglich der Soundqualität, ins-
besondere was die Einstellung der Abtastrate und Bittiefe angeht. Diese Einstellungen sollten auf
dem Host System und der VM identisch sein.
Verwendete Links:
Link1: https://github.com/duncanthrax/scream
Link2: https://github.com/virtio-win/virtio-win-pkg-scripts/blob/master/README.md
Link3: https://github.com/duncanthrax/scream/releases
Link4: https://geeksrepos.com/duncanthrax/scream
der Funktionsbeschreibung auf der Projektseite Link1:
„Scream ist ein virtueller Gerätetreiber für Windows, der ein separates Soundgerät bereitstellt. Über
dieses Gerät wiedergegebenes Audio wird in Ihrem lokalen Netzwerk als PCM-Multicast-Stream ver-
öffentlicht. Empfänger im Netzwerk können den Stream aufnehmen und über ihre eigenen Audioaus-
gänge wiedergeben. Empfänger sind für Unix/Linux (mit Schnittstelle zu PulseAudio oder ALSA)
und für Windows erhältlich.“
Um Scream einsetzen zu können ist wie nachfolgend beschrieben vorzugehen:
a) Netzwerkeinstellungen der virtuellen Maschinenverwaltung
Die Netzwerkeinstellung der virtuellen Maschinenverwaltung müssen auf default stehen. Außerdem
ist es notwendig, dass der Haken bei Autostart [beim Start] gesetzt ist.
b) Die Einstellungen der virtuellen Netzwerkschnittstelle in der VM sollten folgendermaßen aussehen:
Als virtuelle Netzwerkschnittstellle muß virtio
verwendet werden, als Brückenname wird
(vom Autor hier) virbr0 vergeben.
c) Als nächstes werden die Windows Treiber für die virtuelle Netzwerkkarte in der VM benötigt.
Die findet man in der virtio-win.iso, welche von dieser Seite Link2 bezogen werden kann. Das
ISO-Abbild wird dann als CDROM Laufwerk in die VM eingebunden.
Bevor man die Treiber in der VM installieren kann, muss noch folgendes beachtet werden:
Microsoft hat für neuere Versionen von Windows 10 (ab 1607) die Regeln für das Signieren von
Kernelmodustreibern verschärft. Das läßt sich auf zweierlei Wegen umgehen:
1) Secure boot im BIOS der Windows VM ausschalten, oder
2) In der Windows VM folgenden Eintrag in der Registery anlegen:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI\Policy]
"UpgradedSystem"=dword:00000001
(siehe Projektseite Scream, d.h. das muss vor der Installation des Windows Treibers geschehen,
damit erkennt sich das Windows in der VM als Upgrade-Version, was die Installation von
„cross-signed kernel driver" möglich macht).
Zusammengefasst heißt das, in der Windows VM muss zuerst entweder Secure boot ausge-
schaltet oder der oben beschriebene Registery Eintrag muss angelegt werden bevor der nächste
Installationsschritt erfolgen kann (siehe hierzu auch GPU-Passtrough-Teil-07).
d) Jetzt die Windows VM erneut starten und darin den Geräte Manager öffnen. Dort wird unter
„Andere Geräte“ ein Ethernet-Contoller ohne Treiber angezeigt. Für diesen muß jetzt der Virtio
Netzwerktreiber installiert werden. D.h.
- Rechtsklick mit der Maus auf den Ethernet-Controller,
- Treiber aktualisieren,
- “Auf meinem Computer nach Treibern suchen“ auswählen,
- jetzt das CDROM Laufwerk anwählen,
- dort den Ordner NetKVM aufklapen,
- darunter den Ordner w10 aufklappen,
- amd64 anwählen und mit dem Button „OK“ bestätigen.
werkadapter ein Red Hat VirtIO Ethernet Adapter.
e) Nun wird Scream für die Installation in der VM benötigt. Dazu die VM starten, in der VM
den Browser aufrufen und unter folgendem Link3 Scream3.x.zip downloaden. Anschließend
Scream3.x.zip entpacken. Mit dem Windows Explorer den entpackten Ordner Scream3.x
öffnen, dann wechseln zum Verzeichnis Install und dort mit Rechtsklick auf Install-x64 das
ganze als Administrator ausführen um die Installation durchzuführen. Nach erfolgter Instal-
lation kann in den Windows Einstellungen die Soundausgabe auf „Lautsprecher (Scream
(WDM))“ umgestellt werden. Anschließend die Windows VM wieder herunter fahren.
f) Scream Empfänger (Receiver) für den Linux Host bauen
Ein Scream Linux Receiver ist nicht als fertiges Paket erhältlich, sondern den muss man sich
selbst bauen. Bevor das möglich ist, müssen einige Werkzeuge und Bibliotheken geladen und
installiert werden.
Nach Lesen der Readme benötigen wir dazu libpcap-devel, pulseaudio-libs-devel, alsa-lib-devel, cmake,
make und damit auch gcc. Installiert wird das ganze (als root) mit :
[root@localhost vm]# dnf install cmake make gcc pulseaudio-libs-devel alsa-lib-develDa sich libpcap-devel im Repostorie Powertools befindet wird es mit
[root@localhost vm]# dnf --enablerepo=powertools install libpcap-develinstalliert.
Jetzt von Link1 noch (Scream-) master.zip downloaden und entpacken. Nach dem entpacken
im so erzeugten Verzeichnis scream-master/Receivers/unix/ ein Terminalfenster öffnen. Hier
ein neues Verzeichnis build erzeugen,
[vm@localhost ~]$ mkdir builddann nach build wechseln
[vm@localhost ~]$ cd buildund zuerst
[vm@localhost ~]$ cmake ..danach
[vm@localhost ~]$ makeausführen. Dadurch hat man nun das Programm scream im Verzeichnis build erzeugt.
Um das Programm starten zu können (d.h. ausführbar), noch
[root@localhost vm]# chmod +x screamals root in der Konsole ausführen.
Anschließend das Scream Programm nach /usr/bin/ verschieben
[root@localhost vm]# mv scream /usr/bin/screamDa Scream in Almalinux durch die Firewall geblockt wird muss noch ein Port geöffnet werden.
[root@localhost vm]# firewall-cmd --permanent --zone=libvirt --add-port=4010/udp
Danach das Host System neu starten.
[vm@localhost ~]$ rebootGestartet wird das ganze dann in einem Terminal mit
[vm@localhost ~]$ /usr/bin/scream -i virbr0(virbr0 ist der Brückenname der unter Punkt b) „Einstellungen der virtuellen Netzwerkschnitt-
stelle“ vergeben wurde.)
Ob Scream auf dem Host läuft kann man dann in den Audio Einstellungen unter Anwendungen
sehen:
Solange jetzt Scream auf dem Host läuft, werden die Soundausgaben der Windows VM auf den Audio-
ausgängen des Host Systems wiedergegeben.
Im angegeben Link4 findet man noch optionale Einstellungen bezüglich der Soundqualität, ins-
besondere was die Einstellung der Abtastrate und Bittiefe angeht. Diese Einstellungen sollten auf
dem Host System und der VM identisch sein.
Verwendete Links:
Link1: https://github.com/duncanthrax/scream
Link2: https://github.com/virtio-win/virtio-win-pkg-scripts/blob/master/README.md
Link3: https://github.com/duncanthrax/scream/releases
Link4: https://geeksrepos.com/duncanthrax/scream
Der Onboard Soundchip des hier verwendeten Mainboards läßt sich nicht in eine VM durchreichen, da
er nicht in einer eigenen IOMMU Gruppe liegt.
Abhilfe bieten z.B. eine USB 2.0 Soundkarte für kleines Geld die sowohl Linux als auch Windows
unterstützt. Hier wäre das ein DeLOCK USB Sound Adapter 7.1 (LINK) der sich einfach als USB
Device in eine VM einbinden läßt. In der virtuellen Maschinenverwaltung sieht das Einbinden der USB
Soundkarte wie nachfolgend gezeigt aus:
1. „Gerät hinzufügen“ anklicken.
2. USB Host-Gerät auswählen.
3. Audio Adapter auswählen.
4. „Fertig“ anklicken.
Das kann man bei praktisch allen Arten von VM´s (Windows, Linux usw.) so machen und man hat
dann noch zusätzlich den Onboard Sound des Mainboards für das Hostsystem zur Verfügung.
er nicht in einer eigenen IOMMU Gruppe liegt.
Abhilfe bieten z.B. eine USB 2.0 Soundkarte für kleines Geld die sowohl Linux als auch Windows
unterstützt. Hier wäre das ein DeLOCK USB Sound Adapter 7.1 (LINK) der sich einfach als USB
Device in eine VM einbinden läßt. In der virtuellen Maschinenverwaltung sieht das Einbinden der USB
Soundkarte wie nachfolgend gezeigt aus:
1. „Gerät hinzufügen“ anklicken.
2. USB Host-Gerät auswählen.
3. Audio Adapter auswählen.
4. „Fertig“ anklicken.
Das kann man bei praktisch allen Arten von VM´s (Windows, Linux usw.) so machen und man hat
dann noch zusätzlich den Onboard Sound des Mainboards für das Hostsystem zur Verfügung.
Zur Performancesteigerung einer VM kann CPU Pinning angewendet werden, was wiederum
Kenntnisse über den Aufbau der CPU Struktur bzw. der Kerne und den zugehörigen Threads
notwendig macht. Die Topologie der CPU läßt sich mit dem nachfolgenden Befehl
in einer Konsole anzeigen,
bzw. mit
die Zuordnung der Kerne und Threads anzeigen.
Beispiel: Eine VM mit 8 Kernen mit je 1 Thread = 8 logische Rechner CPU´s
Damit ergeben sich im CPU-Z Bench innerhalb der VM folgende Werte:
Single Thread: 496.0 ; Multi Thread: 2532.0
Um jetzt die CPU Kerne anzupinnen gibt man folgendes in die XML - Konfiguration ein: Unter die Zeile
<vcpu placement="static">8</vcpu> folgenden Block einfügen und übernehmen:
<cputune>
<vcpupin vcpu="0" cpuset="8"/>
<vcpupin vcpu="1" cpuset="9"/>
<vcpupin vcpu="2" cpuset="10"/>
<vcpupin vcpu="3" cpuset="11"/>
<vcpupin vcpu="4" cpuset="12"/>
<vcpupin vcpu="5" cpuset="13"/>
<vcpupin vcpu="6" cpuset="14"/>
<vcpupin vcpu="7" cpuset="15"/>
<emulatorpin cpuset="0-1"/>
</cputune>
Damit bindet man die Kerne 0-7 der VM an die CPU Kerne 8-15. E/A-Aufgaben werden an die CPU
Kerne 0 und 1 gebunden.
Als Ergebnis erhält man dann im CPU-Z Bench:
Single Thread: 588.7 ; Multi Thread: 4496.9
CPU-Pinning ist Prozessor- und architekturabhängig und muss daher entsprechend ausgeführt werden.
Im Link wird das ganze ausführlicher erklärt.
Kenntnisse über den Aufbau der CPU Struktur bzw. der Kerne und den zugehörigen Threads
notwendig macht. Die Topologie der CPU läßt sich mit dem nachfolgenden Befehl
[root@localhost vm]# lstopo --of console -pin einer Konsole anzeigen,
bzw. mit
[vm@localhost ~]$ lscpu -edie Zuordnung der Kerne und Threads anzeigen.
Beispiel: Eine VM mit 8 Kernen mit je 1 Thread = 8 logische Rechner CPU´s
Damit ergeben sich im CPU-Z Bench innerhalb der VM folgende Werte:
Single Thread: 496.0 ; Multi Thread: 2532.0
Um jetzt die CPU Kerne anzupinnen gibt man folgendes in die XML - Konfiguration ein: Unter die Zeile
<vcpu placement="static">8</vcpu> folgenden Block einfügen und übernehmen:
<cputune>
<vcpupin vcpu="0" cpuset="8"/>
<vcpupin vcpu="1" cpuset="9"/>
<vcpupin vcpu="2" cpuset="10"/>
<vcpupin vcpu="3" cpuset="11"/>
<vcpupin vcpu="4" cpuset="12"/>
<vcpupin vcpu="5" cpuset="13"/>
<vcpupin vcpu="6" cpuset="14"/>
<vcpupin vcpu="7" cpuset="15"/>
<emulatorpin cpuset="0-1"/>
</cputune>
Damit bindet man die Kerne 0-7 der VM an die CPU Kerne 8-15. E/A-Aufgaben werden an die CPU
Kerne 0 und 1 gebunden.
Als Ergebnis erhält man dann im CPU-Z Bench:
Single Thread: 588.7 ; Multi Thread: 4496.9
CPU-Pinning ist Prozessor- und architekturabhängig und muss daher entsprechend ausgeführt werden.
Im Link wird das ganze ausführlicher erklärt.
Manche Software unter Windows 10 verweigert den Dienst, wenn sie erkennt, daß das OS in einer
virtuellen Maschine läuft. Das kann man überprüfen, in dem man in der Windows VM den Taskmanager
öffnet, auf den Reiter Leistung geht und dort der Eintrag „Virtueller Computer: Ja“ angezeigt wird. Oder
man öffnet die Systeminformationen App, klickt auf Systemübersicht dann wird rechts unten der Eintrag
„Es wurde ein Hypervisor erkannt“ eingeblendet.
Das kann man ändern, in dem man in der virtuellen Maschinenverwaltung in der XML-Ansicht folgende Zeilen einfügt:
Unter
<features>
...
...
<kvm>
<hidden state="on"/>
</kvm>
...
eintragen, sowie die Zeile
<cpu mode="host-model" check="partial">
nach
<cpu mode="host-passthrough" check="partial">
ändern.
Direkt darunter die Zeile
<feature policy='disable' name='hypervisor'/>
einfügen und anschließend übernehmen.
Wird die Windows VM jetzt gestartet sind die Einträge zum Hypervisor aus der Systeminfo und dem
Taskmanager verschwunden.
Man sollte hierzu beachten, das es u. a. einige Online Spiele als Cheaten bewerten wenn das ent-
sprehende Spiel in einer VM läuft. Was dann wiederum zu einem Bann führen kann.
In einem der verlinkten Artikeln wird darauf hingewiesen, das vielen Programme nach dem
Vorhandensein von virtio - Treibern suchen. Hier in dieser GPU-Passthrough Beschreibung
werden an zwei Stellen virtio - Treiber verwendet.
Einmal zur Laufwerksansteuerung und einmal bei der Verwendung von SCREAM.
D.h. man muss abwägen, ob der Einsatz von virtio - Treibern für den entsprechenden Einsatz sinnvoll
ist oder eben nicht.
Link1: https://forums.unraid.net/topic/94498-solved-i-need-hide-vm-status-in-application/
Link2: https://catgirl.is/posts/tips-for-evading-virtual-machine-detection-with-libvirtd-qemu/
virtuellen Maschine läuft. Das kann man überprüfen, in dem man in der Windows VM den Taskmanager
öffnet, auf den Reiter Leistung geht und dort der Eintrag „Virtueller Computer: Ja“ angezeigt wird. Oder
man öffnet die Systeminformationen App, klickt auf Systemübersicht dann wird rechts unten der Eintrag
„Es wurde ein Hypervisor erkannt“ eingeblendet.
Das kann man ändern, in dem man in der virtuellen Maschinenverwaltung in der XML-Ansicht folgende Zeilen einfügt:
Unter
<features>
...
...
<kvm>
<hidden state="on"/>
</kvm>
...
eintragen, sowie die Zeile
<cpu mode="host-model" check="partial">
nach
<cpu mode="host-passthrough" check="partial">
ändern.
Direkt darunter die Zeile
<feature policy='disable' name='hypervisor'/>
einfügen und anschließend übernehmen.
Wird die Windows VM jetzt gestartet sind die Einträge zum Hypervisor aus der Systeminfo und dem
Taskmanager verschwunden.
Man sollte hierzu beachten, das es u. a. einige Online Spiele als Cheaten bewerten wenn das ent-
sprehende Spiel in einer VM läuft. Was dann wiederum zu einem Bann führen kann.
In einem der verlinkten Artikeln wird darauf hingewiesen, das vielen Programme nach dem
Vorhandensein von virtio - Treibern suchen. Hier in dieser GPU-Passthrough Beschreibung
werden an zwei Stellen virtio - Treiber verwendet.
Einmal zur Laufwerksansteuerung und einmal bei der Verwendung von SCREAM.
D.h. man muss abwägen, ob der Einsatz von virtio - Treibern für den entsprechenden Einsatz sinnvoll
ist oder eben nicht.
Link1: https://forums.unraid.net/topic/94498-solved-i-need-hide-vm-status-in-application/
Link2: https://catgirl.is/posts/tips-for-evading-virtual-machine-detection-with-libvirtd-qemu/
Anmerkungen / Erfahrungswerte
1. Datenhaltung virtueller Maschinen und ISO Dateien
Es empfiehlt sich (aus Platzgründen), statt im eigenen (User) Homeverzeichnis die Daten für die ver-
schiedenen VM´s und insbesondere die Imagedateien unter einer eigenen Ordnerstruktur abzulegen.
Das könnte dann z.B. so aussehen:
Unter dem home-Verzeichnis folgende Ordnerstruktur anlegen
home\vmmaschinen\images -> Ordner welche die VM Images enthalten
home\vmmaschinen\iso -> Ordner für notwendige ISO-Dateien
Dazu in einem Terminal Fenster im home Verzeichnis nacheinander folgende Befehle ausführen:
a) Als root die Verzeichnisse erstellen
[root@linux ~]$ mkdir vmmaschinen
[root@linux ~]$ cd vmmaschinen
[root@linux ~]$ mkdir images
[root@linux ~]$ mkdir iso
[root@linux ~]$ cd ..
b) Und dann die Berechtigungen ändern
[root@linux ~]$ chmod -R a+rwx \vmmaschinen
bzw.
[root@linux ~]$ chmod -R 777 \vmmaschinen
Sollen zum leichteren Bereitstellen von Treibern, Programmen usw. ISO Abbilder erzeugt werden,
dann kann man das folgendermaßen bewerkstelligen:
als CDROM Laufwerk in eine VM eingebunden werden.
2. Betrieb von mehreren gleichzeitig angeschlossenen Monitoren an Host und VM
Wenn man, wie der Autor hier, z.B. zwei Monitore gleichzeitig am Host und der per Passthrough
angebundenen VM betreibt, dann kann das insbesondere bei der Installation eines Betriebssystems
in einer VM zu Problemen führen. Speziell dann, wenn die GPU das Bild nicht am gewünschten
Signalausgang liefert, sondern statt dessen die Bildausgabe am gleichen Bildschirm wie die des Hosts
erfolgt.
Das kann passieren, wenn an der Grafikkarte der VM zwei Monitore angeschlossen sind und die
APU des Hostsystems ebenfalls an einen der beiden Monitore angeschlossen wurde.
D.h. man startet die neu erstellte VM zur Installation und sieht kein Bild, obwohl das Laufen der VM
in der Maschinenverwaltung zu sehen ist.
Abhilfe: Entweder am Monitor die Signalumschaltung nutzen oder das entsprechende Kabel vor der
Installation abziehen. Ist das System dann installiert, kann man mit der Bildschirmverwaltung der
VM die Anzeigen (hoffentlich) entsprechend einrichten.
3. UEFI Einstellungen am Mainboard
Unter Punkt GPU-Passthrough-Teil-01 wurde bereits auf die UEFI Einstellungen eingegangen. Dort wird
u. a. der CSM Support zur leichteren Installation des Hostsystems eingeschaltet.
Anfangs erfolgte die Installation von ALMA Linux auf einer SSD. Da war es dann möglich, nach
Einrichtung des Betriebssystems, den CSM Support des Mainboards wieder auszuschalten und
ganz normal zu booten.
Seit der Installation von Almalinux auf eine NVMe ist das nicht mehr möglich. Wird der CSM
Support jetzt deaktiviert, dann erscheint zwar noch der Almalinux Bootloader, es wird jedoch ins
Nirwana gebootet, der Bildschirm wird dunkel. Offensichtlich wird der entsprechende Ein-
sprunkpunkt nicht mehr gefunden.
Das zu ändern ist mir jetzt zuviel Arbeit, eventuell gehe ich das bei einem BIOS Update an.
1. Datenhaltung virtueller Maschinen und ISO Dateien
Es empfiehlt sich (aus Platzgründen), statt im eigenen (User) Homeverzeichnis die Daten für die ver-
schiedenen VM´s und insbesondere die Imagedateien unter einer eigenen Ordnerstruktur abzulegen.
Das könnte dann z.B. so aussehen:
Unter dem home-Verzeichnis folgende Ordnerstruktur anlegen
home\vmmaschinen\images -> Ordner welche die VM Images enthalten
home\vmmaschinen\iso -> Ordner für notwendige ISO-Dateien
Dazu in einem Terminal Fenster im home Verzeichnis nacheinander folgende Befehle ausführen:
a) Als root die Verzeichnisse erstellen
[root@linux ~]$ mkdir vmmaschinen
[root@linux ~]$ cd vmmaschinen
[root@linux ~]$ mkdir images
[root@linux ~]$ mkdir iso
[root@linux ~]$ cd ..
b) Und dann die Berechtigungen ändern
[root@linux ~]$ chmod -R a+rwx \vmmaschinen
bzw.
[root@linux ~]$ chmod -R 777 \vmmaschinen
Sollen zum leichteren Bereitstellen von Treibern, Programmen usw. ISO Abbilder erzeugt werden,
dann kann man das folgendermaßen bewerkstelligen:
- ein beliebiges Verzeichnis erstellen, z.B. MyFolderName
- dorthin die gewünschten Dateien hineinkopieren
- vom darüberliegenden Verzeichnis aus den folgenden Befehl in einer Konsole ausführen:
- [vm@linux ~]$ mkisofs -R -l -D -o data.iso MyFolderName
als CDROM Laufwerk in eine VM eingebunden werden.
2. Betrieb von mehreren gleichzeitig angeschlossenen Monitoren an Host und VM
Wenn man, wie der Autor hier, z.B. zwei Monitore gleichzeitig am Host und der per Passthrough
angebundenen VM betreibt, dann kann das insbesondere bei der Installation eines Betriebssystems
in einer VM zu Problemen führen. Speziell dann, wenn die GPU das Bild nicht am gewünschten
Signalausgang liefert, sondern statt dessen die Bildausgabe am gleichen Bildschirm wie die des Hosts
erfolgt.
Das kann passieren, wenn an der Grafikkarte der VM zwei Monitore angeschlossen sind und die
APU des Hostsystems ebenfalls an einen der beiden Monitore angeschlossen wurde.
D.h. man startet die neu erstellte VM zur Installation und sieht kein Bild, obwohl das Laufen der VM
in der Maschinenverwaltung zu sehen ist.
Abhilfe: Entweder am Monitor die Signalumschaltung nutzen oder das entsprechende Kabel vor der
Installation abziehen. Ist das System dann installiert, kann man mit der Bildschirmverwaltung der
VM die Anzeigen (hoffentlich) entsprechend einrichten.
3. UEFI Einstellungen am Mainboard
Unter Punkt GPU-Passthrough-Teil-01 wurde bereits auf die UEFI Einstellungen eingegangen. Dort wird
u. a. der CSM Support zur leichteren Installation des Hostsystems eingeschaltet.
Anfangs erfolgte die Installation von ALMA Linux auf einer SSD. Da war es dann möglich, nach
Einrichtung des Betriebssystems, den CSM Support des Mainboards wieder auszuschalten und
ganz normal zu booten.
Seit der Installation von Almalinux auf eine NVMe ist das nicht mehr möglich. Wird der CSM
Support jetzt deaktiviert, dann erscheint zwar noch der Almalinux Bootloader, es wird jedoch ins
Nirwana gebootet, der Bildschirm wird dunkel. Offensichtlich wird der entsprechende Ein-
sprunkpunkt nicht mehr gefunden.
Das zu ändern ist mir jetzt zuviel Arbeit, eventuell gehe ich das bei einem BIOS Update an.
Erfahrungsbericht Teil 2: GPU Passthrough mit AMD Ryzen 5900X und einer AMD Radeon RX470 sowie NVIDIA GT 1030 auf einen MSI B450 Mortar Titanium.
Den zweiten Teil meines Erfahrungsberichts findet man hier.Anhänge
Zuletzt bearbeitet:
