Inhalt
1. Vorwort
2. Installation, Einrichtung Updates, PCI-Passthrough, Speicherplatz
3. Erstellen, Start und Installation der virtuellen Maschine, Grafikkarte an VM durchreichen
4. Bildausgabe der VM
5. Performance
6. ...
1. Vorwort
Als IT-Mensch muss man immer auf dem Laufenden bleiben, klar. Was mich dabei stört ist, dass ich immer nur Windows-Maschinen betreue, Clients und Server. Keine Frage: Microsofts HyperV ist eine tolle Virtualisierungsumgebung für den schnellen Hypervisor zwischendurch und das Windows "Ökosystem" mit der Vielzahl an Anwendungen sowie die Verbreitung geben den Rest.
Doch gelüstet es mich meinen Horizont zu erweitern. Mein Auge schielt in Richtung des Pinguins - zumindest Privat. Diverse Gehversuche mit Installationen auf Hardware sind müßig. Immer die SSD wechseln oder - bei DualBoot - das System rebooten. Neh, das mag ich nicht. Am Ende sind die Versuche auch Versuche geblieben... aber mir fehlt das "gekommen um zu bleiben" Gefühl. Klar, Windows kicken und eine Linux-Distribution direkt auf der Hardware betrieben ist einfach, aber am Ende kommt der Frust und der Wechsel auf Windows zurück, weil halt doch was fehlt oder nicht funktioniert, ist ebenso müßig.
Bevor der 42. Versuch gestartet wird, stelle ich die Frage in den Raum: geht das nicht einfacher? Quasi ein Switch, ohne was am PC zu friemeln? Mein Gedanke: Virtualisierung mit GPU-Passthrough. Was das bedeutet das?
Nun, man kombiniert den Vorteil der Plattformunabhängigkeit einer virtuellen Maschine mit der Leistung eines physischen Rechners inklusive Grafikpower für Games und Co. - so die Theorie. Hier docke ich mit meinem Vorhaben an. Als Basis kann man jedes Linuxbasierte System nutzen, oder etwas vorgefertigtes mit dem Fokus auf virtualisierung. In meinem Fall werde ich Proxmox einsetzen.
Als Basis dient ein ausrangierter Server, quasi geschenkt. Einzig in ein paar Prozessoren habe ich günstig investiert. Die restliche Hardware fliegt hier halt so rum.
2. Installation, Einrichtung Updates, PCI-Passthrough, Speicherplatz
Anyway, legen wir los.
Damit ist die Grundinstallation abgeschlossen. Jetzt gehts an die Einrichtung
Generell kann Proxmox jetzt für die einfache Virtualisierung genutzt werden, halt eine VM ohne Grafikpower. Aber wir wollen mehr!
Als nächstes widmen wir uns den Speicherplatz im Host
Damit sind die Vorbereitungen abgeschlossen. Proxmox zieht vernünftig Updates und versteht es PCI-Geräte an virtuelle Maschinen durchzureichen. Ein bisschen Arbeit, die sich aber am Ende lohnt. Dazu weiß der Host nun, wie sein Speicherplatz aussieht.
3. Die virtuelle Maschine
Und schon geht es los, wir erstellen unsere erste virtuelle Maschine. Um GPU-Passthrough auf einfache weise zu testen, setzen wir eine VM mit Windows auf. Vorher aber brauchen wir Installationsmedien.
Eine Möglichkeit ist die Nutzung von DVDs mit dem ggf. vorhandenen DVD-Laufwerk im System. Alternativ kann ein USB-Stick mit der Installation als USB-Laufwerk in die VM eingebunden werden. Eleganter aber ist der Upload der Installationsmedien als ISO-Abbild direkt aufs System.
Jetzt können wir eine virtuelle Maschine erstellen.
Soweit die Vorbereitungen. Jetzt wird es spannend, denn wir starten die VM.
Mit "> Start" wird die VM gestartet. Mit "> Konsole" kann man den "Bildschirm" der VM öffnen. Ist schon eine coole Sache!
Somit ist die VM fertig und kann ausgeschaltet werden. Denn jetzt sind alle Vorbereitungen getroffen, um eine Grafikkarte an die VM durchzureichen.
Damit ist die Grafikkarte mit der VM verheiratet. Aber was mache ich damit jetzt?
4. Bildausgabe der VM
Im Grunde lässt sich die VM weiter über den VNC-Zugang im Webbrowser nutzen. Das ist aber nicht das gelbe vom Ei. Mensch, wir haben Grafikwums und wollen diese auch auf den Schirm bekommen. Ein paar Möglichkeiten.
5. Performance
Zugegeben, ich bin von Ryzen 3700x / RTX 2070 verwöhnt. Daher ist es schwierig als Fazit zu sagen, dass die Performance passt oder nicht, denn Unser Testsystem kommt bei Multithreading gut mit, bleibt bei Singlecore weit hinter dem Ryzen. Daher entscheidet hier das "Popometer". Es sei mir verziehen, dass ich keine aktuellen AAA Titel testen kann, da ich schlicht keine besitze. Daher greife ich auf das zu, was ich nun mal habe und schnell installieren kann.
Beim Thema Benchmark habe ich gar keinen Draht, daher freue ich mich auf Vorschläge von eurer Seite, was ich auf der VM "benchen" kann.
Die Konfig der VM-Win10
16 Core CPU
32GB RAM
R9 390 8GB GPU
1Gbit Netzwerk
Auflösung 1920x1080
Getestet wird
Farming Simulator 19 - Grafik "Sehr Hoch" - Daily Game
CS: Source - Grafik "Sehr hoch" - FPS Test
Die direkte Bedienung der VM präferiere ich in meinem Vorhaben weiterhin. Kommen wir zum Thema RDP-Verbindung
Dann habe ich die Möglichkeiten des In-Home-Streamings ebenfalls unter die Lupe genommen. Dabei wird sowohl die Auslastungs des Systems als auch die Bildqualität bei entsprechender Übertragungsrate betrachtet.
Wie zu erwarten, ist die Leistung und Bildqualität bei direkter Ausgabe auf Bildschirm am besten, danach folgt Moonlight / Sunshine, danach kommt Steam Remote Play. Die allgemeine Leistung beim Spielen kann ich nicht so einfach mit meinem Ryzen System vergleichen, dennoch schlägt sich die VM wacker.
Wenn Du es bis hierhin gelesen hast und dich das Projekt interessiert, freue ich mich auf eine rege Diskussion und Austausch von Know-How sowie Feedback zum Aufbau und dem Verständnis des Leserartikels.
1. Vorwort
2. Installation, Einrichtung Updates, PCI-Passthrough, Speicherplatz
3. Erstellen, Start und Installation der virtuellen Maschine, Grafikkarte an VM durchreichen
4. Bildausgabe der VM
5. Performance
6. ...
1. Vorwort
Als IT-Mensch muss man immer auf dem Laufenden bleiben, klar. Was mich dabei stört ist, dass ich immer nur Windows-Maschinen betreue, Clients und Server. Keine Frage: Microsofts HyperV ist eine tolle Virtualisierungsumgebung für den schnellen Hypervisor zwischendurch und das Windows "Ökosystem" mit der Vielzahl an Anwendungen sowie die Verbreitung geben den Rest.
Doch gelüstet es mich meinen Horizont zu erweitern. Mein Auge schielt in Richtung des Pinguins - zumindest Privat. Diverse Gehversuche mit Installationen auf Hardware sind müßig. Immer die SSD wechseln oder - bei DualBoot - das System rebooten. Neh, das mag ich nicht. Am Ende sind die Versuche auch Versuche geblieben... aber mir fehlt das "gekommen um zu bleiben" Gefühl. Klar, Windows kicken und eine Linux-Distribution direkt auf der Hardware betrieben ist einfach, aber am Ende kommt der Frust und der Wechsel auf Windows zurück, weil halt doch was fehlt oder nicht funktioniert, ist ebenso müßig.
Bevor der 42. Versuch gestartet wird, stelle ich die Frage in den Raum: geht das nicht einfacher? Quasi ein Switch, ohne was am PC zu friemeln? Mein Gedanke: Virtualisierung mit GPU-Passthrough. Was das bedeutet das?
Nun, man kombiniert den Vorteil der Plattformunabhängigkeit einer virtuellen Maschine mit der Leistung eines physischen Rechners inklusive Grafikpower für Games und Co. - so die Theorie. Hier docke ich mit meinem Vorhaben an. Als Basis kann man jedes Linuxbasierte System nutzen, oder etwas vorgefertigtes mit dem Fokus auf virtualisierung. In meinem Fall werde ich Proxmox einsetzen.
mein Vorhaben bezieht sich auf die Möglichkeit Desktop-VMs für den stationären Betrieb direkt mit Monitor, Maus und Tastatur zu nutzen und gleichzeitig im Hintergrund weitere Dienste laufen zu lassen, wie Nextcloud, Backupserver, PiHole... also eher weniger für den klassischen Anwender. Es wird am Anfang definitiv das Terminal zum Einsatz kommen. Die hier gezeigten Schritte lassen sich ggf. auch auf direkt auf dem PC installierten Desktop-Distributionen anwenden, sodass man als User mit Linux-Host im Notfall ein Windows mit Grafikpower als virtuelle Maschine nutzen kann. Die Funktion KVM für die Virtualisierung ist im Linux-Kernel fester Bestandteil.
Ich möchte noch hinzufügen, dass ich selbst noch mit Linux-Systemen laufen lerne. Ich zähle mich auch eher zu den Anfängern, mit dem Streben irgendwann das Ganze zu beherrschen.
Ich möchte noch hinzufügen, dass ich selbst noch mit Linux-Systemen laufen lerne. Ich zähle mich auch eher zu den Anfängern, mit dem Streben irgendwann das Ganze zu beherrschen.
Als Basis dient ein ausrangierter Server, quasi geschenkt. Einzig in ein paar Prozessoren habe ich günstig investiert. Die restliche Hardware fliegt hier halt so rum.
Intel Serverboard S2600CP, Dual Sockel 2011
2x Intel Xeon 2650v2, 2x 8C/16T = 32 Threads
128GB RAM DDR3
1.000 Watt Netzteil FSP
2x Samsung Evo 250GB Sata SSD
1x Kingston 60GB Sata SSD
1x 4TB Seagate Sata HDD
1x AMD R9 390 8GB
1x NVIDIA GTX 650ti 1GB
Etwas Hardware-Porn
WICHTIG ist, dass das System auf jeden Fall Intel VT-d unterstützt, bzw. das Equivalent AMD-V. Dies ist im BIOS/UEFI einzustellen. Vorher sollte das Handbuch / die Herstellerseite der bei dir verbauten Hardware konsultiert werden.
Über den Sinn oder Unsinn einer solchen Plattform möchte ich gar nicht reden. Im vergleich zu meinem Ryzen ist er ein Stromfresser und ist am Ende von der Leistung her gesehen gerade mal gleichauf mit meinem 3700x. Aber als Basis mit genug Leistung ist er super... Okay, als kleiner Nerd hat es schon was, sowas neben einem stehen zu haben
2x Intel Xeon 2650v2, 2x 8C/16T = 32 Threads
128GB RAM DDR3
1.000 Watt Netzteil FSP
2x Samsung Evo 250GB Sata SSD
1x Kingston 60GB Sata SSD
1x 4TB Seagate Sata HDD
1x AMD R9 390 8GB
1x NVIDIA GTX 650ti 1GB
Etwas Hardware-Porn
WICHTIG ist, dass das System auf jeden Fall Intel VT-d unterstützt, bzw. das Equivalent AMD-V. Dies ist im BIOS/UEFI einzustellen. Vorher sollte das Handbuch / die Herstellerseite der bei dir verbauten Hardware konsultiert werden.
Über den Sinn oder Unsinn einer solchen Plattform möchte ich gar nicht reden. Im vergleich zu meinem Ryzen ist er ein Stromfresser und ist am Ende von der Leistung her gesehen gerade mal gleichauf mit meinem 3700x. Aber als Basis mit genug Leistung ist er super... Okay, als kleiner Nerd hat es schon was, sowas neben einem stehen zu haben
2. Installation, Einrichtung Updates, PCI-Passthrough, Speicherplatz
Anyway, legen wir los.
Den Anfang macht das Proxmox VE als Hostsystem. VE steht hierbei für "Virtual Environment" (dt. virtuelle Umgebung). Proxmox basiert auf Debian, einer verdammt stabilen Linux-Distribution - so der O-Ton. Die ISO ziehen wir von deren Website und brennen es auf eine DVD oder packen es per Rufus oder BalenaEtcher auf einen USB Stick mit mind. 8GB Speicher.
Ausgerüstet mit DVD/USB-Stick starten wir den Rechner damit. Begrüßt wird man mit einem selbst erklärenden grafischen Installer, der klassisch mit Maus/Tastatur zu bedienen ist. Im Grunde wird hier angefragt, wohin sich Proxmox installieren soll, dann wird ein Passwort festgelegt (bitte eine gültige E-Mail angeben für Systemmeldungen und "Passwort vergessen" Funktion) und am Ende geben wir dem Bock noch einen Namen und eine IP-Adresse.
Nach der Installation begrüßt uns ein schnödes Terminal, mit dem dezenten Hinweis, ab hier doch bitte das Webinterface zu öffnen für weitere Einstellungen.
Also ab ins Webinterface - natürlich von einem anderen PC aus. Mittels https://[IP-Adresse]:8006 wird diese aufgerufen. Nach der Anmeldung mit dem Benutzer "root" und dem eben festgelegten Passwort gelingt die Anmeldung. Die erste Meldung, "No Subscription" kann ignoriert werden. Proxmox im allgemeinen kann kostenfrei genutzt werden. Mit Subscriptions erkauft man sich quasi Support vom Entwickler, grob gesagt.
Auf jeden Fall berüßt uns die WebGUI meines Servers "Enterprise". Ganz nett sieht man auf einem Blick die Auslastung des Systems.
Ausgerüstet mit DVD/USB-Stick starten wir den Rechner damit. Begrüßt wird man mit einem selbst erklärenden grafischen Installer, der klassisch mit Maus/Tastatur zu bedienen ist. Im Grunde wird hier angefragt, wohin sich Proxmox installieren soll, dann wird ein Passwort festgelegt (bitte eine gültige E-Mail angeben für Systemmeldungen und "Passwort vergessen" Funktion) und am Ende geben wir dem Bock noch einen Namen und eine IP-Adresse.
Nach der Installation begrüßt uns ein schnödes Terminal, mit dem dezenten Hinweis, ab hier doch bitte das Webinterface zu öffnen für weitere Einstellungen.
Also ab ins Webinterface - natürlich von einem anderen PC aus. Mittels https://[IP-Adresse]:8006 wird diese aufgerufen. Nach der Anmeldung mit dem Benutzer "root" und dem eben festgelegten Passwort gelingt die Anmeldung. Die erste Meldung, "No Subscription" kann ignoriert werden. Proxmox im allgemeinen kann kostenfrei genutzt werden. Mit Subscriptions erkauft man sich quasi Support vom Entwickler, grob gesagt.
Auf jeden Fall berüßt uns die WebGUI meines Servers "Enterprise". Ganz nett sieht man auf einem Blick die Auslastung des Systems.
Damit ist die Grundinstallation abgeschlossen. Jetzt gehts an die Einrichtung
Jetzt kommt das Terminal zum Einsatz. Geöffnet werden kann das Terminal direkt aus der WebGUI heraus.
Wer ab hier Berührungsangst hat, braucht sich keine Sorgen zu machen. Es gibt viele Dokumentationen, die mal mehr mal weniger verständlich erklärt sind. Wenn Fragen auftreten, fragt man einfach in den einschlägigen Community-Foren (Hallo CB
)
Proxmox muss gesagt werden, dass Updates vom Paket-Repository "No-Subcription" gezogen werden sollen und nicht von den "Enterprise" Repositories. Wir beziehen uns dazu auf den Wiki-Eintrag Package Repositories. Geöffnet werden die Konfig-Dateien mit Nano.
Kurze Info: In Nano speichert und beendet man eine Konfigdatei mit "Strg + X" und "y"
Rein geht es in die erste Datei
Dort wird folgende Zeile eingefügt:
Dann gehen wir in diese Datei
und kommentieren mit "#" diese Zeile aus.
Danach kann per Terminal das System auf den neuesten Stand gebracht werden. Alternativ geht der Update-Prozess auch über die WebGUI zu starten.
Wer ab hier Berührungsangst hat, braucht sich keine Sorgen zu machen. Es gibt viele Dokumentationen, die mal mehr mal weniger verständlich erklärt sind. Wenn Fragen auftreten, fragt man einfach in den einschlägigen Community-Foren (Hallo CB
)Proxmox muss gesagt werden, dass Updates vom Paket-Repository "No-Subcription" gezogen werden sollen und nicht von den "Enterprise" Repositories. Wir beziehen uns dazu auf den Wiki-Eintrag Package Repositories. Geöffnet werden die Konfig-Dateien mit Nano.
Kurze Info: In Nano speichert und beendet man eine Konfigdatei mit "Strg + X" und "y"
Rein geht es in die erste Datei
nano /etc/apt/sources.listDort wird folgende Zeile eingefügt:
deb http://download.proxmox.com/debian/pve buster pve-no-subscriptionDann gehen wir in diese Datei
nano /etc/apt/sources.list.d/pve-enterprise.listund kommentieren mit "#" diese Zeile aus.
# deb https://enterprise.proxmox.com/debian/pve buster pve-enterpriseDanach kann per Terminal das System auf den neuesten Stand gebracht werden. Alternativ geht der Update-Prozess auch über die WebGUI zu starten.
apt updateapt upgradeGenerell kann Proxmox jetzt für die einfache Virtualisierung genutzt werden, halt eine VM ohne Grafikpower. Aber wir wollen mehr!
Vorweg, was ist das eigentlich? PCI-Passthrough beschreibt das Verfahren PCI(e) Komponenten direkt an eine virtuelle Maschine durchzureichen. Sie wird dadurch ein Teil der VM und auch direkt als Hardware erkannt. Im Standard ist die Funktion im Debian-Unterbau von Proxmox nicht eingerichtet. Das meldet Proxmox auch, wenn wir einer VM ein PCI-Gerät mitgeben wollen.
Also gehen wir der Bitte nach und ziehen dazu den Wiki-Eintrag PCI-Passthrough zu Rate.
Ab ins Terminal und rein in die Konfig-Dateien. Als erstes wird GRUB angepasst.
In der Zeile
fügen wir hinter "quiet" noch einen Parameter zum Aktivieren von IOMMU hinzu.
Das Ergebnis sollte so aussehen:
Danach wird die Konfiguration für den Bootloader aktualisiert.
Ab in die nächste Datei.
Hier wird unter der ganzen Kommentarzeilen (Die Zeilen mit #) folgendes eingefügt:
Damit die Weitergabe der PCI-Geräte funktioniert, muss "IOMMU-Remapping" Unterstütztung vorhanden sein. Geprüft wird das hier mit.
Kommt die Rückmeldung
wird die Funktion unterstützt.
Als nächstes wird die Datei "pve-blacklist.conf" geöffnet. Diese dient dazu, die Grafiktreiber im Host zu blocken, damit er sie nicht laden und sich damit die Grafikkarten krallen kann. Das kann ggf. Probleme der Weitergabe von GPUs an VMs eliminieren.
Rein in die Datei.
folgendes tragen wir ein.
Zuletzt wird initramfs aktualisiert.
Am Ende wird der Host neu gestartet.
Also gehen wir der Bitte nach und ziehen dazu den Wiki-Eintrag PCI-Passthrough zu Rate.
Ab ins Terminal und rein in die Konfig-Dateien. Als erstes wird GRUB angepasst.
nano /etc/default/grubIn der Zeile
GRUB_CMDLINE_LINUX_DEFAULT="quiet"fügen wir hinter "quiet" noch einen Parameter zum Aktivieren von IOMMU hinzu.
Das Ergebnis sollte so aussehen:
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on"Danach wird die Konfiguration für den Bootloader aktualisiert.
update-grubAb in die nächste Datei.
nano /etc/modulesHier wird unter der ganzen Kommentarzeilen (Die Zeilen mit #) folgendes eingefügt:
vfio
vfio_iommu_type1
vfio_pci
vfio_virqfdDamit die Weitergabe der PCI-Geräte funktioniert, muss "IOMMU-Remapping" Unterstütztung vorhanden sein. Geprüft wird das hier mit.
dmesg | grep 'remapping'Kommt die Rückmeldung
"DMAR-IR: Enabled IRQ remapping in x2apic mode" ('x2apic' can be different on old CPUs, but should still work)wird die Funktion unterstützt.
Als nächstes wird die Datei "pve-blacklist.conf" geöffnet. Diese dient dazu, die Grafiktreiber im Host zu blocken, damit er sie nicht laden und sich damit die Grafikkarten krallen kann. Das kann ggf. Probleme der Weitergabe von GPUs an VMs eliminieren.
Rein in die Datei.
nano /etc/modprobe.d/pve-blacklist.conffolgendes tragen wir ein.
blacklist radeon
blacklist amdgpu
blacklist nouveau
blacklist nvidia
blacklist nvidiafbZuletzt wird initramfs aktualisiert.
update-initramfs -u -k allAm Ende wird der Host neu gestartet.
rebootAls nächstes widmen wir uns den Speicherplatz im Host
Damit Proxmox weiß, wieviel Speicher er inne hat, muss in der WebGUI entsprechend gehandelt werden. Am Anfang steht der Speicher des Datenträgers zur Verfügung, wo Proxmox installiert wurde (local, local-lvm). Hier werden auch ISO-Dateien abgelegt. Die kleine SSD reicht aber nicht für die VMs aus. Also richten wir die restlichen Datenträger ein.
Wir gehen auf den Punkt "Disks" Dort werden alle Platten aufgelistet. In meinem Fall sind das 2x 250GB Samsung SSDs und eine 4TB Seagate HDD. Sieht dann so aus.
Den Datenträgern hauchen wir Leben ein mittels "Initialisiere Disk mit GPT"
Als nächstes geht es auf den Menüpunkt "ZFS" und wir erstellen neue ZFS-Volumen über den Button "Erstellen: ZFS"
Das wird mit den restlichen Datenträgern auch gemacht. Die Übersicht sieht dann in meinem Beispiel so aus.
Natürlich können mehrere Datenträger zu RAIDs zusammengefasst werden. Ganz gut im Proxmox Wiki beschrieben
Wir gehen auf den Punkt "Disks" Dort werden alle Platten aufgelistet. In meinem Fall sind das 2x 250GB Samsung SSDs und eine 4TB Seagate HDD. Sieht dann so aus.
im Terminal können die Platten formatiert werden. Wichtig ist, dass sie als GPT initialisiert werden. Ich mache es kurz:
für alle vorhandenen Partititionen wiederholen
bestätigen mit „y“
ACHTUNG: Einer der Datenträger beinhaltet die Partitionen, wo Proxmox installiert ist, in meinem Fall /dev/sdd - diese NICHT anrühren, sonst darf neu installiert werden!
gdisk /dev/sd[X] - [X] steht für das Device. I.d.r sda, sdb, sdc...gpt
dfür alle vorhandenen Partititionen wiederholen
wbestätigen mit „y“
ACHTUNG: Einer der Datenträger beinhaltet die Partitionen, wo Proxmox installiert ist, in meinem Fall /dev/sdd - diese NICHT anrühren, sonst darf neu installiert werden!
Als nächstes geht es auf den Menüpunkt "ZFS" und wir erstellen neue ZFS-Volumen über den Button "Erstellen: ZFS"
Das wird mit den restlichen Datenträgern auch gemacht. Die Übersicht sieht dann in meinem Beispiel so aus.
Natürlich können mehrere Datenträger zu RAIDs zusammengefasst werden. Ganz gut im Proxmox Wiki beschrieben
Damit sind die Vorbereitungen abgeschlossen. Proxmox zieht vernünftig Updates und versteht es PCI-Geräte an virtuelle Maschinen durchzureichen. Ein bisschen Arbeit, die sich aber am Ende lohnt. Dazu weiß der Host nun, wie sein Speicherplatz aussieht.
3. Die virtuelle Maschine
Und schon geht es los, wir erstellen unsere erste virtuelle Maschine. Um GPU-Passthrough auf einfache weise zu testen, setzen wir eine VM mit Windows auf. Vorher aber brauchen wir Installationsmedien.
Eine Möglichkeit ist die Nutzung von DVDs mit dem ggf. vorhandenen DVD-Laufwerk im System. Alternativ kann ein USB-Stick mit der Installation als USB-Laufwerk in die VM eingebunden werden. Eleganter aber ist der Upload der Installationsmedien als ISO-Abbild direkt aufs System.
Der Einstieg erfolgt wieder über das Webinterface. Wir gehen auf den Speicher "local" und klicken dann auf ISO-Images. Über den Button "Hochladen" können die ISO-Dateien hochgeladen werden.
Damit Windows für die VM-Umgebung später alle Funktionen nutzen kann, müssen Treiber nachinstalliert werden. Die virtio-Treiber liegen als ISO bereit und werden ebenfalls mit hochgeladen.
Damit Windows für die VM-Umgebung später alle Funktionen nutzen kann, müssen Treiber nachinstalliert werden. Die virtio-Treiber liegen als ISO bereit und werden ebenfalls mit hochgeladen.
Jetzt können wir eine virtuelle Maschine erstellen.
Nun geht es ans erstellen einer virtuellen Maschine. Diese lässt sich ganz einfach über "Erstelle VM" erstellen
Die Schritte, als Liste und bebildert.
Wir wechseln ins Terminal und rufen die Konfig-Datei der VM auf.
In der Zeile "cpu" wird der Parameter "hidden=1" dazu geschrieben.
Die Schritte, als Liste und bebildert.
- Name und VM-ID vergeben (Proxmox arbeitet nur mit der ID der VM)
- ISO-Datei und zu installierendes System auswählen
- System auf Q35, OVMF (UEFI), Speicherort für VHD einstellen, Cache auf Writethrough (Erweiterte Einstellungen aktivieren)
- Laufwerk erstellen, Datenträger auswählen, Größe festlegen
- CPU-Kerne, Typ auf "host", Extra CPU-Flags (bei meinem System) "spec-ctl" aktivieren für den Spectre-Fix
- RAM festlegen
- Netzwerkkarte für VM festlegen
Wir wechseln ins Terminal und rufen die Konfig-Datei der VM auf.
nano /etc/pve/qemu-server/100.confIn der Zeile "cpu" wird der Parameter "hidden=1" dazu geschrieben.
cpu: host,hidden=1,flags=+pcidSoweit die Vorbereitungen. Jetzt wird es spannend, denn wir starten die VM.
Mit "> Start" wird die VM gestartet. Mit "> Konsole" kann man den "Bildschirm" der VM öffnen. Ist schon eine coole Sache!
Wie man Windows installiert, erspare ich mir hier mal Einzig bei der Auswahl des Datenträgers geraten wir ins Stoplern... denn die VM findet keine. Hier kommt die "virtuo-ISO" zum Einsatz. Dort befindet sich der Treiber für den Datenträger.
Dazu wechseln wir in die WebGUI und wechseln die ISO in dem virtuellen Laufwerk.
Zurück in der VM laden wir den Treiber. Als Ergebnis sollte der Treiber "Red Hat VirtIO SCSI Controller" gefunden werden.
Damit Windows weiter installiert werden kann, wird wieder die Windows-ISO ins Lauwerk gepackt. Ab hier erfolgt das Windows-Setup normal weiter.
Ist Windows fertig installiert, riskieren wir einen Blick in den Geräte-Manager.
Hier werden einige Geräte angekreidet, wo Treiber fehlen.
In meinem Fall sind es nur der Grafiktreiber der VNC-Konsole und der VirtIO Ballon Driver.
Die installieren wir einfach nach. Alle Treiber liegen auf der virtio-ISO, welche wir wieder ins virtuelle Laufwerk der VM legen.
Zum Schluss noch - für Notfälle - RDP aktivieren
Einzig bei der Auswahl des Datenträgers geraten wir ins Stoplern... denn die VM findet keine. Hier kommt die "virtuo-ISO" zum Einsatz. Dort befindet sich der Treiber für den Datenträger.Dazu wechseln wir in die WebGUI und wechseln die ISO in dem virtuellen Laufwerk.
Zurück in der VM laden wir den Treiber. Als Ergebnis sollte der Treiber "Red Hat VirtIO SCSI Controller" gefunden werden.
Damit Windows weiter installiert werden kann, wird wieder die Windows-ISO ins Lauwerk gepackt. Ab hier erfolgt das Windows-Setup normal weiter.
Ist Windows fertig installiert, riskieren wir einen Blick in den Geräte-Manager.
Hier werden einige Geräte angekreidet, wo Treiber fehlen.
In meinem Fall sind es nur der Grafiktreiber der VNC-Konsole und der VirtIO Ballon Driver.
Die installieren wir einfach nach. Alle Treiber liegen auf der virtio-ISO, welche wir wieder ins virtuelle Laufwerk der VM legen.
Zum Schluss noch - für Notfälle - RDP aktivieren
Die Einstellungen der VM für Linux sind mit der Windows-VM identisch. Einzig lässt sich ein Bild auf den Bildschirm nur durch setzen der "Anzeige" auf "keine" entlocken. Sobald eine virtuelle GPU eingestellt ist, wird die primär genommen und ein zweiter Monitor nicht erkannt.
Ansonsten erkennt die Linux-Distribution alles Out of Box.
Ansonsten erkennt die Linux-Distribution alles Out of Box.
Somit ist die VM fertig und kann ausgeschaltet werden. Denn jetzt sind alle Vorbereitungen getroffen, um eine Grafikkarte an die VM durchzureichen.
Schön und gut, man kann die VM jetzt nutzen über den Webbrowser. Aber es fehlt einfach an Grafikbums. Den bringen wir der VM nun bei.
Im Webinterface gehen wir auf die Hardware der VM und fügen ein PCI-Gerät zu.
Wir haken alle Funktionen an und klicken auf Hinzufügen. Vorerst bleibt für die Installation der Grafikkarte der Haken „Primary“ nicht gesetzt. Erst nach der Installation der Grafiktreiber wird der Haken „Primary“ gesetzt.
Als nächstes wird "Anzeige" angepasst mit dem Button "Bearbeiten". Hier stellen wir von "Standardeinstellung" auf "VirtoIO-GPU" um. Damit kann die Webkonsole der VM weiterhin genutzt werden.
Jetzt wird die VM gestartet. Im Windows Gerätemanager sollte die durchgereichte Grafikkarte auftauchen. Optmimal installiert Windows gleich die Treiber mit.
Dann sollten noch Daumen gedrückt werden, dass der "Code43" nicht auftaucht. Bei mir konnte sowohl die AMD- als auch die NVIDIA Grafikkarte ohne Probleme in Betrieb genommen werden.
[ LINUX HIER EINFÜGEN ]
Im Webinterface gehen wir auf die Hardware der VM und fügen ein PCI-Gerät zu.
Wir haken alle Funktionen an und klicken auf Hinzufügen. Vorerst bleibt für die Installation der Grafikkarte der Haken „Primary“ nicht gesetzt. Erst nach der Installation der Grafiktreiber wird der Haken „Primary“ gesetzt.
Als nächstes wird "Anzeige" angepasst mit dem Button "Bearbeiten". Hier stellen wir von "Standardeinstellung" auf "VirtoIO-GPU" um. Damit kann die Webkonsole der VM weiterhin genutzt werden.
Jetzt wird die VM gestartet. Im Windows Gerätemanager sollte die durchgereichte Grafikkarte auftauchen. Optmimal installiert Windows gleich die Treiber mit.
Dann sollten noch Daumen gedrückt werden, dass der "Code43" nicht auftaucht. Bei mir konnte sowohl die AMD- als auch die NVIDIA Grafikkarte ohne Probleme in Betrieb genommen werden.
[ LINUX HIER EINFÜGEN ]
Damit ist die Grafikkarte mit der VM verheiratet. Aber was mache ich damit jetzt?
4. Bildausgabe der VM
Im Grunde lässt sich die VM weiter über den VNC-Zugang im Webbrowser nutzen. Das ist aber nicht das gelbe vom Ei. Mensch, wir haben Grafikwums und wollen diese auch auf den Schirm bekommen. Ein paar Möglichkeiten.
Wo wir bei Schirm sind, so simpel es sich auch anhört, so einfach und genial ist es auch: wir schließen einen Monitor an die Grafikkarte an. In meinem Fall habe ich die verbaute AMD R9 390 an die VM durchgereicht, also wird das Videokabel auch dort angeschlossen.... seht selbst 🙂
Im Prinzip könnte man sich das System so unter den Schreibtisch stellen, Monitor, Maus/Tastatur dran, die Windows VM automatisch mit dem Start des Rechners mit hochfahren lassen und schon haben wir eine lokal nutzbare VM mit Grafikwumms. Eine geniale Lösung, worauf ich mich auch fokussieren möchte.
Damit Maus und Tastatur entsprechend funktionieren, müssen sie der VM hinzugefügt werden. Das geht in der WebGUI.
Im Prinzip könnte man sich das System so unter den Schreibtisch stellen, Monitor, Maus/Tastatur dran, die Windows VM automatisch mit dem Start des Rechners mit hochfahren lassen und schon haben wir eine lokal nutzbare VM mit Grafikwumms. Eine geniale Lösung, worauf ich mich auch fokussieren möchte.
Damit Maus und Tastatur entsprechend funktionieren, müssen sie der VM hinzugefügt werden. Das geht in der WebGUI.
Bei Windows - logisch - kann für die Verbindung zur VM die Funktion Remotedesktop genutzt werden. Sie ist etwas performanter als der Web VNC und für Officedinge sehr gut geeignet. Bei Videowiedergabe gerät die Verbindung aber schon leicht ins stocken.
Von einem anderen Windows-PC wird das Programm "Remotedesktopverbindung" oder kurz "mstsc" aufgerufen und durch die Eingabe des Namens oder der IP-Adresse auf die VM verbunden. Ein Benutzer mit Passwort ist erforderlich.
Von einem anderen Windows-PC wird das Programm "Remotedesktopverbindung" oder kurz "mstsc" aufgerufen und durch die Eingabe des Namens oder der IP-Adresse auf die VM verbunden. Ein Benutzer mit Passwort ist erforderlich.
Mit Moonlight kann man sich sein eigenes In-Home-Streaming aufbauen. Die Software ist komplett Opensource, frei nutzbar, für Windows, Mac sowie Linuxdistributionen und als Client-Apps für Smartphones/Tablets verfügbar. Für das Streaming wird GeForce Experience genutzt, daher ist hier zwingend eine NVIDIA Grafikkarte erforderlich. Dank OpenSource gibt es aber einen Fork, nennt sich Sunshine, der ohne GeForce Experience auskommt und daher für AMD Grafikkarten gedacht ist.
Während für Moonlight ein Setup-Guide auf github bereit steht und auf der Hauptseite die Downloads bereit liegen, verlinke ich mal für Sunshine auf die Seite bei github. Der Link zu den Downloads für Windows, Mac und dem Paket für die Linux-Distributionen steht im oberen Absatz.
Näher habe ich mich noch nicht mit der Software beschäftigt, aber dennoch kurz ausprobiert. Die VM wird gefunden und ich kann mich auch mit ihr von meinem Hauptrechner aus verbinden. Mit etwas Feintuning bekommt man auch ein klares Bild zum Streamen eingestellt. Vorgeschlagen wird einem der Stream des Desktops oder Steam BigPicture bei installiertem Steamclient. Die Bildqualität und Lantenzen hängen natürlich stark von der Bandbreite des LAN / WLAN in den eigenen vier Wänden ab.
Während für Moonlight ein Setup-Guide auf github bereit steht und auf der Hauptseite die Downloads bereit liegen, verlinke ich mal für Sunshine auf die Seite bei github. Der Link zu den Downloads für Windows, Mac und dem Paket für die Linux-Distributionen steht im oberen Absatz.
Näher habe ich mich noch nicht mit der Software beschäftigt, aber dennoch kurz ausprobiert. Die VM wird gefunden und ich kann mich auch mit ihr von meinem Hauptrechner aus verbinden. Mit etwas Feintuning bekommt man auch ein klares Bild zum Streamen eingestellt. Vorgeschlagen wird einem der Stream des Desktops oder Steam BigPicture bei installiertem Steamclient. Die Bildqualität und Lantenzen hängen natürlich stark von der Bandbreite des LAN / WLAN in den eigenen vier Wänden ab.
Steam bietet mit Steam RemotePlay von Haus aus die Möglichkeit im eigenen Netzwerk Spiele auf Smartphone/Tablet/Android Boxen und AppleTV zu streamen. Die Funktion - ehemals Steam Inhome-Streaming - kann einfach im Steam Launcher aktiviert werden. Die Latenz und Übertragunsqualität hängt natürlich von der Bandbreite des LAN / WLAN in den eigenen vier Wänden ab.
- ...
- ...
5. Performance
Zugegeben, ich bin von Ryzen 3700x / RTX 2070 verwöhnt. Daher ist es schwierig als Fazit zu sagen, dass die Performance passt oder nicht, denn Unser Testsystem kommt bei Multithreading gut mit, bleibt bei Singlecore weit hinter dem Ryzen. Daher entscheidet hier das "Popometer". Es sei mir verziehen, dass ich keine aktuellen AAA Titel testen kann, da ich schlicht keine besitze. Daher greife ich auf das zu, was ich nun mal habe und schnell installieren kann.
Beim Thema Benchmark habe ich gar keinen Draht, daher freue ich mich auf Vorschläge von eurer Seite, was ich auf der VM "benchen" kann.
Die Konfig der VM-Win10
16 Core CPU
32GB RAM
R9 390 8GB GPU
1Gbit Netzwerk
Auflösung 1920x1080
Getestet wird
Farming Simulator 19 - Grafik "Sehr Hoch" - Daily Game
CS: Source - Grafik "Sehr hoch" - FPS Test
Die VM performt mit der durchgereichten GPU recht gut. Einen Inputlag mit Maus/Tastatur stelle ich hier NICHT fest. Es ist quasi, als laufe das System auf Blech.
Ich fange an mit dem FPS-Test für Toaster: CS: Source
Zum vergrößern auf Bild klicken
Weiter geht es mit einem Spiel, was bei mir alltäglich gespielt wird: Farming Simulator 19
Zum vergrößern auf Bild klicken
Ich fange an mit dem FPS-Test für Toaster: CS: Source
- Frames: 40 - 200 - 300, V-Sync 60
Das Spiel läuft wie auf Blech, allerdings beobachte ich hier "soft stuttering". D.h. die Frames sacken immer wieder runter, bleiben aber stabil, egal welche Effekte auftreten. Das gehakel kann ich beseitigen, indem der V-Sync aktiviert wird. Dann läuft das Spiel auf 60FPS ohne Murren. Auf Blech kann ich aus Erfahrung sagen, lief das Spiel mit i7 4770 und der R9 durchgehend ohne stuttering im 300FPS Bereich. Ich vermute aber hier nicht die VM als solches, sondern die Anzahl der Threads in der VM und der CPUs im Host. Evtl. streiten sich die beiden Xeons um die Arbeit. - Input: wie Blech
Wie oben beschrieben, ich merke keinen Unterschied zu einem Blechsystem. Die Eingaben werden sofort und ohne Verzögerung umgesetzt. Bei Mausbewegungen sehe ich kein nachziehen oder ähnliches.
Zum vergrößern auf Bild klicken
Weiter geht es mit einem Spiel, was bei mir alltäglich gespielt wird: Farming Simulator 19
- Frames: 40 - 60
Das Spiel ist kein Performancewunder. Auf meinem Ryzen kommen auch nur um die 60 FPS zustande, daher bin ich hier zufrieden. Hier gibt es kein stuttering wie beim FPS-Test unter CS: Source. - Input: wie Blech
auch hier sehe ich hier keinen Unterschied zwischen Installation auf Hardware und der VM.
Zum vergrößern auf Bild klicken
Die direkte Bedienung der VM präferiere ich in meinem Vorhaben weiterhin. Kommen wir zum Thema RDP-Verbindung
Ich habe es mit RDP versucht und gleich wieder abgebrochen. Die Übertragung scheitert mit massiven stuttering und die Maussteuerung ist total verzogen. Den Inputlag kann ich durch die schlechte Übertragung nicht beurteilen.
Dann habe ich die Möglichkeiten des In-Home-Streamings ebenfalls unter die Lupe genommen. Dabei wird sowohl die Auslastungs des Systems als auch die Bildqualität bei entsprechender Übertragungsrate betrachtet.
Los gehts mit Sunshine.
Übertragunsrate: Erst 20Mbit/s (Standard), dann 50Mbit/s
Encoding: Hardware x264
CS: Source
Zum vergrößern auf Bild klicken (Bild zeigt Übertragung mit 20Mbit/s und V-Sync an)
Farming Simulator 19
Zum vergrößern auf Bild klicken (Bild zeigt Übertragung mit 50Mbit/s)
Übertragunsrate: Erst 20Mbit/s (Standard), dann 50Mbit/s
Encoding: Hardware x264
CS: Source
- Frames: bis 300 - V-Sync 60
Trotz Encoding für das Streaming sind die Frames identisch mit der Direktausgabe. - Input: min. Verzögert
Auf dem ersten Blick erkenne ich hier einen minimalen Inputlag, dennoch ist dieser fast mit der Direktausgabe zu vergleichen. - Bildqualität: schlecht (20 Mbit/s), gut (50 Mbit/s)
Mit der Standardeinstellung 20Mbit/s wirft mir der Stream ziemlichen Pixelmatsch um die Ohren. Mit 50Mbit/s habe ich ein scharfes Bild. - Systemlast
Die Last beim Encoding liegt etwas höher, es sind aber noch genügen Ressourcen für das Spiel vorhanden.
Zum vergrößern auf Bild klicken (Bild zeigt Übertragung mit 20Mbit/s und V-Sync an)
Farming Simulator 19
- Frames: 40 - 60
Trotz Encoding für das Streaming sind die Frames identisch mit der Direktausgabe, ich bin hier überrascht. - Input: min. Verzögert
Auf dem ersten Blick sehe ich auch hier einen minimalen Inputlag, dennoch ist dieser fast mit der Direktausgabe zu vergleichen. - Bildqualität: schlecht (20 Mbi/s), gut (50 Mbit/s)
Mit der Standardeinstellung 20Mbit/s bekomme ich ebenfalls im Stream ziemlichen Pixelmatsch zu sehen. Mit 50Mbit/s habe ich ein scharfes Bild. - Systemlast
Hier beobachte ich eine leicht erhöhte Systemlast im Vergleich zur Direktausgabe. Vor allem bei der GPU ist die Last höher.
Zum vergrößern auf Bild klicken (Bild zeigt Übertragung mit 50Mbit/s)
Nun wird über Steams eigene Streamfunktion gespielt.
Übertragunsrate: Erst 20Mbit/s (Standard) mit Dyn. Rate, dann 50Mbit/s fest
Encoding: Hardware GPU
CS: Source
Zum vergrößern auf Bild klicken (Bild zeigt Übertragung mit 50Mbit/s)
Farming Simulator 19
Zum vergrößern auf die Bilder klicken (Bild zeigt Übertragung mit 50Mbit/s)
Übertragunsrate: Erst 20Mbit/s (Standard) mit Dyn. Rate, dann 50Mbit/s fest
Encoding: Hardware GPU
CS: Source
- Frames: bis 300 - V-Sync 60
Trotz Encoding für das Streaming sind die Frames identisch mit der Direktausgabe. - Input: etwas Verzögert
Man merkt im Vergleich schon ein leichtes nachziehen. Spielen möchte ich damit auf dauer nicht. Wobei hier nicht der Input von 1ms, sondern die Bildausgabe von ca. 45ms schuld sein könnte. - Bildqualität: sehr schlecht (Dyn. Rate), schlecht (20 Mbit/s fest), gut (50 Mbit/s)
Mit der Standardeinstellung 20Mbit/s wirft mir der Stream ein schlechtes Bild vors Auge. Schlimmer ist es mit der dyn. Rate, die Steam im Standard eingestellt hat. Mit 50Mbit/s fest eingestellt habe ich ein scharfes Bild. - Systemlast
Die Last beim Encoding liegt etwas höher, es sind aber noch genügen Ressourcen für das Spiel vorhanden. Die Frameraten sind recht stabil. Leider lässt sich hier der Taskmanager nicht mit ablichten.
Zum vergrößern auf Bild klicken (Bild zeigt Übertragung mit 50Mbit/s)
Farming Simulator 19
- Frames: 40 - 60
Trotz Encoding für das Streaming sind die Frames identisch mit der Direktausgabe. - Input: etwas Verzögert
Man merkt im Vergleich schon eine leichte Verzögerung, man kann es aber spielen. Die Bildausgabe ist mit rund 32ms sogar schneller beim Client als bei CS: Source. - Bildqualität: sehr schlecht (Dyn. Rate), schlecht (20 Mbit/s fest), gut (50 Mbit/s)
Mit der Standardeinstellung 20Mbit/s wirft mir der Stream auch hier ein schlechtes Bild aus. Schlimmer ist es mit der dyn. Rate, die Steam im Standard eingestellt hat, ebenso. Mit 50Mbit/s fest eingestellt habe ich ein scharfes Bild. - Systemlast
Die Last beim Encoding liegt etwas höher, es sind aber noch genügen Ressourcen für das Spiel vorhanden. Die Frameraten sind auch hier stabil. Leider lässt sich hier der Taskmanager nicht mit ablichten.
Zum vergrößern auf die Bilder klicken (Bild zeigt Übertragung mit 50Mbit/s)
Wie zu erwarten, ist die Leistung und Bildqualität bei direkter Ausgabe auf Bildschirm am besten, danach folgt Moonlight / Sunshine, danach kommt Steam Remote Play. Die allgemeine Leistung beim Spielen kann ich nicht so einfach mit meinem Ryzen System vergleichen, dennoch schlägt sich die VM wacker.
Wenn Du es bis hierhin gelesen hast und dich das Projekt interessiert, freue ich mich auf eine rege Diskussion und Austausch von Know-How sowie Feedback zum Aufbau und dem Verständnis des Leserartikels.
Anhänge
-
proxmox_meldung_iommu_off.png -
proxmox_disk_overview.png -
proxmox_create_vm_2.png -
proxmox_create_vm_3.png -
proxmox_create_vm_3.png -
proxmox_webgui_vm_add_mouse-keyboard.png -
proxmox_webgui_vm_add_usb.png -
1620595930079.png -
vm_performance_source_gputest.jpg -
vm_performance_source_vsync .jpg -
vm_performance_fs19.png -
streaming_remoteplay_source.png -
streaming_remoteplay_source.png
Zuletzt bearbeitet:
(Update Punkt 5., Update Punkt 3.2.2, Typo)
) dann sollte der Proxmox sie gar nicht nutzen und der Passtrough der GPU sollte klappen. Die GPU sollte primär sein.
