Leserartikel Proxmox VE: Alleskönner mit virtuellen Gaming-Ambitionen?

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.
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.

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 :D
proxmox_system.jpg



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 :D



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.
proxmox_setup_start.png
proxmox_setup_pw_nic.png


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.
proxmox_fertig.png


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.
proxmox-webgui.png

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.
proxmox_shell.png


proxmox_webshell.png


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 :daumen:)

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.list

Dort wird folgende Zeile eingefügt:
deb http://download.proxmox.com/debian/pve buster pve-no-subscription

Dann gehen wir in diese Datei
nano /etc/apt/sources.list.d/pve-enterprise.list

und kommentieren mit "#" diese Zeile aus.
# deb https://enterprise.proxmox.com/debian/pve buster pve-enterprise

Danach kann per Terminal das System auf den neuesten Stand gebracht werden. Alternativ geht der Update-Prozess auch über die WebGUI zu starten.

apt update

apt upgrade

Generell 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.
proxmox_meldung_iommu_off.png


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/grub

In 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-grub

Ab in die nächste Datei.
nano /etc/modules

Hier wird unter der ganzen Kommentarzeilen (Die Zeilen mit #) folgendes eingefügt:
vfio vfio_iommu_type1 vfio_pci vfio_virqfd

Damit 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.conf

folgendes tragen wir ein.
blacklist radeon blacklist amdgpu blacklist nouveau blacklist nvidia blacklist nvidiafb

Zuletzt wird initramfs aktualisiert.
update-initramfs -u -k all

Am Ende wird der Host neu gestartet.
reboot

Als 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.
1620589060292.png


im Terminal können die Platten formatiert werden. Wichtig ist, dass sie als GPT initialisiert werden. Ich mache es kurz:

gdisk /dev/sd[X] - [X] steht für das Device. I.d.r sda, sdb, sdc...
gpt d
für alle vorhandenen Partititionen wiederholen
w
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!
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"
proxmox_disk_zfs_create.png


Das wird mit den restlichen Datenträgern auch gemacht. Die Übersicht sieht dann in meinem Beispiel so aus.
proxmox_disk_zfs_overview.png


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.
1620591368322.png


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 :D
proxmox_neue_vm.png


Die Schritte, als Liste und bebildert.
proxmox_create_vm_1.png

proxmox_create_vm_2,5.png

proxmox_create_vm_3,5.png

proxmox_create_vm_3.png

proxmox_create_vm_4.png

  1. Name und VM-ID vergeben (Proxmox arbeitet nur mit der ID der VM)
  2. ISO-Datei und zu installierendes System auswählen
  3. System auf Q35, OVMF (UEFI), Speicherort für VHD einstellen, Cache auf Writethrough (Erweiterte Einstellungen aktivieren)
  4. Laufwerk erstellen, Datenträger auswählen, Größe festlegen
  5. CPU-Kerne, Typ auf "host", Extra CPU-Flags (bei meinem System) "spec-ctl" aktivieren für den Spectre-Fix
  6. RAM festlegen
  7. Netzwerkkarte für VM festlegen
Wurde die VM erstellt, wird sie in der linken Spalte angezeigt.

Wir wechseln ins Terminal und rufen die Konfig-Datei der VM auf.
nano /etc/pve/qemu-server/100.conf

In der Zeile "cpu" wird der Parameter "hidden=1" dazu geschrieben.
cpu: host,hidden=1,flags=+pcid

Soweit die Vorbereitungen. Jetzt wird es spannend, denn wir starten die VM.
proxmox_vm_done.png

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 :D 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.
proxmox_vm_win_disk.png


Dazu wechseln wir in die WebGUI und wechseln die ISO in dem virtuellen Laufwerk.

proxmox_vm_win_virtuoiso.png

proxmox_vm_win_change_iso.png


Zurück in der VM laden wir den Treiber. Als Ergebnis sollte der Treiber "Red Hat VirtIO SCSI Controller" gefunden werden.
proxmox_vm_win_load_diskdrv.png

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.
proxmox_vm_win_device_manager.png

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.

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.
proxmox_webgui_vm_pci-device.png

proxmox_webgui_vm_pci-device_set.png

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.
proxmox_webgui_vm_display_virtio-gpu.png


Jetzt wird die VM gestartet. Im Windows Gerätemanager sollte die durchgereichte Grafikkarte auftauchen. Optmimal installiert Windows gleich die Treiber mit.
proxmox_vm_devicemgnt_gpu.png

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 🙂
proxmox_vm_gpu-ausgabe.jpeg

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.
proxmox_webgui_vm_add_usb.png
proxmox_webgui_vm_add_mouse-keyboard.png

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.

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.
proxmox_vm_moonlight.png

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.

  1. ...
  2. ...



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
  • 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.
vm_performance_source.png

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.
vm_performance_fs19.png

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
  • 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.
streaming_moonlight3.png

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.
streaming_moonlight.png

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
  • 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.
streaming_remoteplay_source.png

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.
streaming_remoteplay_fs19.png

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_meldung_iommu_off.png
    6,2 KB · Aufrufe: 688
  • proxmox_disk_overview.png
    proxmox_disk_overview.png
    19,8 KB · Aufrufe: 494
  • proxmox_create_vm_2.png
    proxmox_create_vm_2.png
    11,1 KB · Aufrufe: 458
  • proxmox_create_vm_3.png
    proxmox_create_vm_3.png
    37,5 KB · Aufrufe: 468
  • proxmox_create_vm_3.png
    proxmox_create_vm_3.png
    37 KB · Aufrufe: 779
  • proxmox_webgui_vm_add_mouse-keyboard.png
    proxmox_webgui_vm_add_mouse-keyboard.png
    10,8 KB · Aufrufe: 431
  • proxmox_webgui_vm_add_usb.png
    proxmox_webgui_vm_add_usb.png
    6,8 KB · Aufrufe: 435
  • 1620595930079.png
    1620595930079.png
    4,8 KB · Aufrufe: 445
  • vm_performance_source_gputest.jpg
    vm_performance_source_gputest.jpg
    638,9 KB · Aufrufe: 476
  • vm_performance_source_vsync .jpg
    vm_performance_source_vsync .jpg
    718,9 KB · Aufrufe: 556
  • vm_performance_fs19.png
    vm_performance_fs19.png
    4 MB · Aufrufe: 501
  • streaming_remoteplay_source.png
    streaming_remoteplay_source.png
    4,2 MB · Aufrufe: 500
  • streaming_remoteplay_source.png
    streaming_remoteplay_source.png
    4,2 MB · Aufrufe: 573
Zuletzt bearbeitet: (Update Punkt 5., Update Punkt 3.2.2, Typo)
  • Gefällt mir
Reaktionen: Drahminedum, rude66, grünerbert und 57 andere
shorty123 schrieb:
@xCtrl
Danke für die tolle Anleitung, leider habe ich Probleme damit die Grafikkarte GTX 780 zum laufen zu bringen, PCI-Passthrough war kein Problem aber es kommt der Fehler Code 43, hat jmd noch einen Idee. Es wurde alles wie in der Anleitung konfiguriert und mehrfach geprüft aber leider kommt es immer wieder dazu.

Moin,

läuft deine VM als UEFI mit Q35 Chipset? Sie muss in der Kombination laufen, damit das Ganze funktioniert.

Nehme zum Test den Haken bei Primary GPU raus, damit sollte die VirtGPU als primary laufen. Prüfe dann im Gerätemanager, ob sie korrekt erkannt wird. Ich meine mich schwach zu erinnern, dass ich am Anfang, bevor dieses HowTo geschrieben wurde, in dem Bereich rumprobieren musste.

Was nutzt Du als Hardware? Ist Proxmox als BIOS oder UEFI auf dem Host installiert? Wenn letzteres, ggf. den Beitrag #18 von @DerNiemand berücksichtigen.
 
xCtrl schrieb:
Moin,

läuft deine VM als UEFI mit Q35 Chipset? Sie muss in der Kombination laufen, damit das Ganze funktioniert.

Nehme zum Test den Haken bei Primary GPU raus, damit sollte die VirtGPU als primary laufen. Prüfe dann im Gerätemanager, ob sie korrekt erkannt wird. Ich meine mich schwach zu erinnern, dass ich am Anfang, bevor dieses HowTo geschrieben wurde, in dem Bereich rumprobieren musste.

Was nutzt Du als Hardware? Ist Proxmox als BIOS oder UEFI auf dem Host installiert? Wenn letzteres, ggf. den Beitrag #18 von @DerNiemand berücksichtigen.
Servus, ja läuft auf UEFI mit Q35. Das habe ich schon getestet hat auch nichts gebracht. Sie wird zwar angezeigt aber der o.g. Fehler tritt auf sobald er die NVIDIA Systemsteuerung installieren möchte. Hardware I7 6600,Asus H110M-R und GTX 780 16 GB RAM. Gute Frage ob BIOS oder UEFI. Ja das habe ich gelesen aber was muss da gesetzt werden. Anleitung?
 
Wenn der Proxmox im UEFI Mode auf dem Host installiert ist, muss ich im Moment leider passen. Mein System läuft im BIOS Mode.

Hast Du dem Host in der Datei "pve-blacklist.conf" verboten die Treiber für die GPU zu laden - wie im HowTo beschrieben unter Punkt 2.3 ?
 
xCtrl schrieb:
Wenn der Proxmox im UEFI Mode auf dem Host installiert ist, muss ich im Moment leider passen. Mein System läuft im BIOS Mode.

Hast Du dem Host in der Datei "pve-blacklist.conf" verboten die Treiber für die GPU zu laden - wie im HowTo beschrieben unter Punkt 2.3 ?
Habe alles nochmals geprüft und neu installiert, der Fehler lag daran dass Windows nicht den Treiber installieren durfte (scheinbar ein Alter-Treiber wo das Durchgeben nicht funzt) Bei Installation eines neueren Treibers hat es nach ein paar Mal neu starten geklappt.
 
  • Gefällt mir
Reaktionen: xCtrl
Nachdem ich ein paar Tage mit Unraid gespielt habe (auf meinem Speicherwürfel und Hauptsystem) und eine VM mit GPU-Pasthrough eingerichtet habe, muss ich folgendes festhalten:

  • UnRaid muss auf dem Hostsystem in CSM (BIOS, nicht UEFI) gebootet werden, nicht in UEFI, wenn GPU-Passthrough genutzt werden möchte
  • die VM muss als OVMF (UEFI Boot) erstellt werden, damit die GPU erkannt und ein Bild auf den angeschlossenen Monitor ausgibt
  • der VM muss beim GPU-Passthrough das GPU-BIOS mitgegeben werden, welches vorher editiert wurde
  • VFIO Gruppen können in UnRaid über die WebGUI konfiguriert werden

  • UnRaid bringt viele Dinge mit, da es nicht primär als HyperVisor konzipiert ist, sondern als fast Eierlegende Wollmilchsau...
  • UnRaid kann rein auf einem Stick installiert werden, da sich das System beim Start ins RAM lädt, im Gegensatz zu einer Proxmox Installation wird hier keine extra SSD/HDD benötigt
  • Proxmox kann als "No-Subcription" kostenfrei genutzt werden, Unraid kostet einmalig einen kleinen Obolus

Mit den kurz gesammelten Erfahrungen kann ich UnRaid und Proxmox gegenüber stellen und schauen, welche Hürden wo auftauchen und wo man entsprechend Hand anlegen muss.

Ich muss meine PVE Kiste genauer unter die Lupe nehmen, da ich sie mit meinem Hauptsystem (Ryzen) schon bei der Bootmethode nicht genau vergleichen kann. Das PVE auf meinem Testserver kann nur BIOS-Boot IHMO.

Ich glaube, ich habe wieder etwas Futter gefunden für diesen Thread + ggf. kommt ja ein kleines UnRaid Tut um die Ecke :)
 
  • Gefällt mir
Reaktionen: Triple5soul, chillking und shorty123
xCtrl schrieb:
Nachdem ich ein paar Tage mit Unraid gespielt habe (auf meinem Speicherwürfel und Hauptsystem) und eine VM mit GPU-Pasthrough eingerichtet habe, muss ich folgendes festhalten:

  • UnRaid muss auf dem Hostsystem in CSM (BIOS, nicht UEFI) gebootet werden, nicht in UEFI, wenn GPU-Passthrough genutzt werden möchte
  • die VM muss als OVMF (UEFI Boot) erstellt werden, damit die GPU erkannt und ein Bild auf den angeschlossenen Monitor ausgibt
  • der VM muss beim GPU-Passthrough das GPU-BIOS mitgegeben werden, welches vorher editiert wurde
  • VFIO Gruppen können in UnRaid über die WebGUI konfiguriert werden

  • UnRaid bringt viele Dinge mit, da es nicht primär als HyperVisor konzipiert ist, sondern als fast Eierlegende Wollmilchsau...
  • UnRaid kann rein auf einem Stick installiert werden, da sich das System beim Start ins RAM lädt, im Gegensatz zu einer Proxmox Installation wird hier keine extra SSD/HDD benötigt
  • Proxmox kann als "No-Subcription" kostenfrei genutzt werden, Unraid kostet einmalig einen kleinen Obolus

Mit den kurz gesammelten Erfahrungen kann ich UnRaid und Proxmox gegenüber stellen und schauen, welche Hürden wo auftauchen und wo man entsprechend Hand anlegen muss.

Ich muss meine PVE Kiste genauer unter die Lupe nehmen, da ich sie mit meinem Hauptsystem (Ryzen) schon bei der Bootmethode nicht genau vergleichen kann. Das PVE auf meinem Testserver kann nur BIOS-Boot IHMO.

Ich glaube, ich habe wieder etwas Futter gefunden für diesen Thread + ggf. kommt ja ein kleines UnRaid Tut um die Ecke :)
Sehr cool, da bin ich ja gespannt.
 
  • Gefällt mir
Reaktionen: xCtrl
Interessanter Thread, Danke und cooles Setup! Etwas Ähnliches möchte ich auch testen in den nächsten Monaten :-)

Es gibt ja noch Spice, welches auch unter Windows läuft, damit sollte remote Gaming (besser) möglich sein, angeblich. Lasse mich da aber gerne etwas besseren belehren ;-)

Hier wäre auch noch ein älteres Video zu GPU Passthrough und remote Gaming, dort funktioniert es anscheinend relativ flüssig mit RDP oder TeamViewer.


Das mit dem Passthrough sollte mit den neuen Nvidia Treibern einfacher funktionieren, da diese Funktion nicht mehr unterdrückt wird, seit 05.21, so viel ich gehört habe war das zuvor ein regelrechter Kampf, das überhaupt ans laufen zu bekommen, wenn nicht die passende Hardware vorhanden war.

Wäre schön, wenn der Thread nicht in Vergessenheit geraten würde, update pls^^

Chears!
 
  • Gefällt mir
Reaktionen: Triple5soul, shorty123 und xCtrl
Moin,

ich konnte mittlerweile ebenfalls ein funktionierendes System aufbauen bzw. vom der alten Hardware upgraden. Dabei habe ich eine GTX 1050 ti erfolgreich auf einen Linux Guest durchgereicht, ich konnte eine relativ gute bzw. akzeptable Performance mittels NoMachine (Remote Anwendung) erreichen.

Allerdings habe ich keinen Monitor direkt angeschlossen, sondern einen Dummy verwendet, sonst konnten keine sinnvollen Auflösungen gefahren werden. Laut meiner Recherche kann das auch im Bios konfiguriert werden, aber dazu hatte ich dann nicht mehr genügend Zeit um mich damit weiter auseinander zu setzten.

Auf Linux kann man Parsec nur als Client verwenden, Spice läuft irgendwie nicht ohne als Grafikschnittstelle im Hypervisor aktiviert worden zu sein, also standalone und X2GO war eine Katastrophe, total instabil oder auch von meiner Seite her falsch konfiguriert.

Jedenfalls kann ich Proxmox definitiv weiterempfehlen, ich bin begeistert, vermutlich werden Gaming Tests auch noch folgen.

Die Grafikkarte in der virtuellen Umgebung kann auch zum Beispiel für Hashcat verwendet werden, hatte damit auch ein paar kleinere Tests durchgeführt.

Mit welchen Anwendungen arbeitet ihr sonst so auf euren Gast System, die eine Grafikkarte benötigen könnten, CAD, Mining, Videoschnitt? Würde mich mal interessieren, was sonst so für interessante Projekte und Anwendungsbeispiele dabei herkamen.

Chears!
 
  • Gefällt mir
Reaktionen: xCtrl
Ich schließe mich ebenfalls dem Thema an :)

Gibt es noch jemanden im Thread welcher sich mit möglicher Hardware-Auswahl beschäftigt? In meinem Anwendungsfall würde ich gerne im Idle eine handvoll Dockercontainer laufen lassen, um mein bestehendes NAS vom Anwendungsfall auch gleich mit zu ersetzen. Dabei ist der Strom-Verbrauch natürlich mehr als wichtig.
 
HerrTeekanne schrieb:
Ich schließe mich ebenfalls dem Thema an :)

Gibt es noch jemanden im Thread welcher sich mit möglicher Hardware-Auswahl beschäftigt? In meinem Anwendungsfall würde ich gerne im Idle eine handvoll Dockercontainer laufen lassen, um mein bestehendes NAS vom Anwendungsfall auch gleich mit zu ersetzen. Dabei ist der Strom-Verbrauch natürlich mehr als wichtig.
Kommt darauf an, würde ich sagen. Ich habe mir eine gebrauchte HP-Z440 Workstation gekauft, mit einem 16 Kern Xeon. Für einen Hypervisor sind Kerne und RAM nicht ganz unwichtig, aber lieber mehr RAM als Kerne. Von der Performance her bin ich eigentlich mehr als zufrieden. Hier habe ich mir das individuell zusammen gestellt, über einen Konfigurator: https://www.workstation4u.de/

Ein NAS wäre separat besser, ansonsten kannst du dir auch mal Unraid anschauen, falls du es eh noch nicht in Erwägung gezogen hast, dort soll eine Container-Orchestrierung mit implementiert sein, was ich so gelesen habe.
 
Ich komme auch mal dazu, auch wenn ich für das Projekt seit ewig keine Zeit mehr habe... Mein System siehst Du ja im Eingangspost, 2x Xeon 2650, 128GB RAM, für GPU Passthrough Test die R9 390. Im Idle liegen um die 100 Watt an. Ohne Grafik? Keine Ahnung ehrlich gesagt. Auf jeden Fall ist ein Ryzen oder vergleichbarer i5/i7 viel sparsamer und bietet auch schon eine nicht zu unterschätzende Anzahl C/T und Unterstützung für RAM.
 
  • Gefällt mir
Reaktionen: Clapinoson und HerrTeekanne
Clapinoson schrieb:
Kommt darauf an, würde ich sagen. Ich habe mir eine gebrauchte HP-Z440 Workstation gekauft, mit einem 16 Kern Xeon. Für einen Hypervisor sind Kerne und RAM nicht ganz unwichtig, aber lieber mehr RAM als Kerne. Von der Performance her bin ich eigentlich mehr als zufrieden. Hier habe ich mir das individuell zusammen gestellt, über einen Konfigurator: https://www.workstation4u.de/

Ein NAS wäre separat besser, ansonsten kannst du dir auch mal Unraid anschauen, falls du es eh noch nicht in Erwägung gezogen hast, dort soll eine Container-Orchestrierung mit implementiert sein, was ich so gelesen habe.
Unraid steht auch zur Auswahl. Aktuell wäre meine Tendenz eher in Richtung der Zweckentfremdung bestehender "Standard" Hardware gegangen. Das geplante Konstrukt soll meinen bestehenden Desktop auch perspektivisch ersetzen. Wichtig wäre mir aber dass der idle Verbrauch nicht durch die Decke schießt.
 
  • Gefällt mir
Reaktionen: Clapinoson
xCtrl schrieb:
Ich komme auch mal dazu, auch wenn ich für das Projekt seit ewig keine Zeit mehr habe... Mein System siehst Du ja im Eingangspost, 2x Xeon 2650, 128GB RAM, für GPU Passthrough Test die R9 390. Im Idle liegen um die 100 Watt an. Ohne Grafik? Keine Ahnung ehrlich gesagt. Auf jeden Fall ist ein Ryzen oder vergleichbarer i5/i7 viel sparsamer und bietet auch schon eine nicht zu unterschätzende Anzahl C/T und Unterstützung für RAM.
Danke nochmals für die echt gute Aufbereitung. Ich werde planmäßig meine Ergebnisse auch hier mitteilen.

Vermutlich werde ich auch erstmal mit einem Testballon starten und meinen aktuellen Rechner mit Proxmox laufen lassen.
 
  • Gefällt mir
Reaktionen: xCtrl
Clapinoson schrieb:
kannst du dir auch mal Unraid anschauen
Nachtrag: unRaid macht spaß, ich habe mir auf der Basis letztes Jahr ein Nas+ zusammengestellt.

Cube: AsRock J4205-ITX | 16GB DDR3 1600 | 3x Seagate Ironwolf 4TB | PicoPSU 160 + 60 Watt NT | unRaid

Reicht für Daten horten + ein paar Docker + Windows 10 VM durchaus aus, ein Leistungswunder ist er nicht, zwischen 60 und 100MB/s sind ausreichend im Netz. Eine Cache-SSD habe ich am Anfang drin gehabt, aber keine wirkliche Verbesserung gehabt.

unRaid ist aber nicht nur für NAS, sondern auch als nette Virtualisierungsplattform zu gebrauchen. Hardware ist da kein Limit gesetzt. Truenas geht auch langsam in die Richtung, seit Linux Basis bei Truenas Scale.
 
  • Gefällt mir
Reaktionen: Clapinoson
xCtrl schrieb:
unRaid ist aber nicht nur für NAS, sondern auch als nette Virtualisierungsplattform zu gebrauchen. Hardware ist da kein Limit gesetzt. Truenas geht auch langsam in die Richtung, seit Linux Basis bei Truenas Scale.

Werde ich mir auch mal anschauen, wo ich aktuell ein Problem habe bei Proxmox und GPU Passthrough ist mit Cuda. Ich bringe einfach eine Cuda Anwendung nicht zum laufen auch testweise habe ich CudaMiner getestet und funktioniert auch nicht, bei einer Baremetal Installation auf einem Linux System läuft das aber. Jetzt wollte ich mal fragen, ob du das evtl. mal in deiner virtuellen Proxmox Umgebung testen könntest?

xCtrl schrieb:
Nachtrag: unRaid macht spaß, ich habe mir auf der Basis letztes Jahr ein Nas+ zusammengestellt.

Cube: AsRock J4205-ITX | 16GB DDR3 1600 | 3x Seagate Ironwolf 4TB | PicoPSU 160 + 60 Watt NT | unRaid

Reicht für Daten horten + ein paar Docker + Windows 10 VM durchaus aus, ein Leistungswunder ist er nicht, zwischen 60 und 100MB/s sind ausreichend im Netz. Eine Cache-SSD habe ich am Anfang drin gehabt, aber keine wirkliche Verbesserung gehabt.

Danke für den Tipp, bei NAS fahre ich aktuell mit TrueNAS ziemlich gut, ist auch sehr performant. Das Unraid würde ich mir direkt mal für meinen Rechner holen, das einzige, was mich daran etwas stört, ist, dass es anscheinend nur mit USB-Stick und nicht auf einer SSD lauffähig ist. Ist das immer noch so oder haben die das mittlerweile geändert?
 
xCtrl schrieb:
Truenas geht auch langsam in die Richtung, seit Linux Basis bei Truenas Scale.
Wobei FreeBSD (also die Basis von TrueNAS Core/Enterprise) ja auch mit bhyve einen modernen Hypervisor mitbringt der auch recht gut funktioniert. Keine Ahnung, ob der über TrueNAS zugänglich ist. Aber prinzipiell wäre die Möglichkeit da.
 
  • Gefällt mir
Reaktionen: xCtrl
Clapinoson schrieb:
Jetzt wollte ich mal fragen, ob du das evtl. mal in deiner virtuellen Proxmox Umgebung testen könntest?
Mir fehlt im Moment die Zeit dazu überhaupt die Kiste wieder in Betrieb zu nehmen, tut mir leid, eine GTX750 zum Test hätte ich aber da. Die hatte ich auch im System drin zum Testen vom Passthrough von NVIDIA-Karten - was tatsächlich ohne Code 43 lief.

Clapinoson schrieb:
Danke für den Tipp, bei NAS fahre ich aktuell mit TrueNAS ziemlich gut, ist auch sehr performant.
Was Truenas von Haus aus anders macht als unRaid ist die Nutzung von ZFS Pools und entsprechend vorhandenen RAM als Cache. Kann man in unRaid nachrüsten über die Community Apps, habe ich aber nicht gemacht.

Clapinoson schrieb:
was mich daran etwas stört, ist, dass es anscheinend nur mit USB-Stick und nicht auf einer SSD lauffähig ist. Ist das immer noch so oder haben die das mittlerweile geändert?
Ja, in der Tat läuft unRaid vom USB-Stick. Ich sehe es eher als Vorteil an. Das System lädt sich beim Start in den RAM und verweilt dort. Die Lizenz wird an die UUID des Sticks gebunden und kann ein paar mal im Jahr auf einen anderen Stick umgezogen werden, z.B. bei einem Defekt. Auf dem Stick selbst ist sonst nix los, außer wenige hundert MB fürs System und Configs.

Eher ärgerlich fand ich, dass proxmox oder truenas einen eigenen Datenträger benötigen. Okay, wegen Logs z.B., aber unRaid habe ich unter anderem auch genommen, damit ich alle 4 Schächte von meinem Gehäuse nutzen kann - und weil das kleine Mainboard nur 4x Sata hat.
INTER-TECH IPC SC-4004.png

Truenas und proxmox werden nur auf SSDs/HDDs installiert, weil hier auch die Logs geschrieben werden, das kann man einem USB-Stick nicht antun.

andy_m4 schrieb:
Wobei FreeBSD (also die Basis von TrueNAS Core/Enterprise) ja auch mit bhyve einen modernen Hypervisor mitbringt der auch recht gut funktioniert
Habe ich gelesen. Genau, Truenas Core nutzt Bhyve als Hypervisor. Ich habe selbst Truenas nur installiert und gestöbert. Eine VM habe ich weder bei Scale noch bei Core eingerichtet. Bei letzteren kenne ich Bhyve nicht, bei Scale wird - wie bei proxmox und unRaid dank Linuxunterbau KVM genutzt.
 
  • Gefällt mir
Reaktionen: Clapinoson
xCtrl schrieb:
Mir fehlt im Moment die Zeit dazu überhaupt die Kiste wieder in Betrieb zu nehmen, tut mir leid, eine GTX750 zum Test hätte ich aber da. Die hatte ich auch im System drin zum Testen vom Passthrough von NVIDIA-Karten - was tatsächlich ohne Code 43 lief.

Kein Problem.

xCtrl schrieb:
Ja, in der Tat läuft unRaid vom USB-Stick. Ich sehe es eher als Vorteil an. Das System lädt sich beim Start in den RAM und verweilt dort. Die Lizenz wird an die UUID des Sticks gebunden und kann ein paar mal im Jahr auf einen anderen Stick umgezogen werden, z.B. bei einem Defekt. Auf dem Stick selbst ist sonst nix los, außer wenige hundert MB fürs System und Configs.

Ich werde es mir demnächst anschauen, bin gespannt wie es sich als Desktop System anfühlt, für meine Server Applikationen behalte ich erstmal Proxmox.
 
Zuletzt bearbeitet:
Zurück
Oben