Stellen Sie sich vor: Sie betreiben einen leistungsstarken Proxmox-Server, auf dem eine Windows-VM als Ihr primäres Arbeitstier läuft. Diese Windows-VM ist jedoch nicht nur eine gewöhnliche virtuelle Maschine – sie dient gleichzeitig als **Hyper-V-Host**, auf dem Sie weitere spezialisierte virtuelle Maschinen ausführen. Und nun kommt der Clou: Sie möchten eine einzige, physische **GPU** nicht nur an die Windows-VM durchreichen, sondern diese GPU auch noch auf die **Hyper-V-Gast-VMs** aufteilen. Klingt kompliziert? Ist es auch! Aber keine Sorge, in diesem umfassenden Leitfaden entschlüsseln wir Schritt für Schritt, wie Sie diese äußerst anspruchsvolle Konfiguration meistern können. Wir knacken gemeinsam diese technische Nuss!
Warum dieser Aufwand? Die Anwendungsfälle für GPU Splitting in einer nested Hyper-V Umgebung
Bevor wir tief in die Materie eintauchen, fragen Sie sich vielleicht, warum man sich überhaupt die Mühe machen sollte, eine so komplexe Umgebung einzurichten. Die Antwort liegt in den enormen Vorteilen, die sich daraus ergeben:
* **Effiziente Ressourcennutzung**: Anstatt für jede VM eine eigene teure GPU zu kaufen, können Sie eine High-End-Grafikkarte auf mehrere Benutzer oder Workloads aufteilen. Dies spart Kosten und Energie.
* **Virtueller Desktop (VDI)**: Unternehmen, die VDI-Lösungen anbieten, können so grafikintensive Anwendungen (CAD, Videobearbeitung) für mehrere Benutzer gleichzeitig bereitstellen, ohne dass jeder Nutzer eine physische Workstation benötigt.
* **Gaming und Streaming**: Ermöglichen Sie mehreren Familienmitgliedern oder Freunden, grafikintensive Spiele in ihren eigenen VMs zu spielen oder Streams zu produzieren, während sie dieselbe leistungsstarke Hardware nutzen.
* **AI/ML Workloads**: Forscher und Entwickler können ihre Deep-Learning-Modelle auf geteilten GPU-Ressourcen trainieren und testen, was die Skalierbarkeit und Flexibilität erhöht.
* **Testumgebungen**: Erstellen Sie isolierte Umgebungen für Softwareentwicklung oder -tests, die jeweils dedizierte GPU-Leistung benötigen, ohne dafür physische Hardware bereitstellen zu müssen.
Die Konfiguration, die wir hier besprechen, ist ideal, wenn Ihre Haupt-Windows-VM selbst eine Rolle als Hyper-V-Host spielen soll und Sie dort die Granularität des GPU-Sharings benötigen.
Die Kernherausforderung: Nested Virtualization und GPU Passthrough
Das Problem, eine **GPU** für **Hyper-V-VMs** bereitzustellen, die *innerhalb* einer **Proxmox-VM** laufen, ist eine doppelte Herausforderung. Es erfordert das Zusammenspiel von:
1. **PCI Passthrough auf Proxmox-Ebene**: Die physische GPU muss vom **Proxmox-Host** an die **Windows-VM** durchgereicht werden. Hierbei spricht man von „Direct Device Assignment” oder „GPU Passthrough”.
2. **GPU-Virtualisierung auf Hyper-V-Ebene**: Sobald die Windows-VM die GPU besitzt, muss sie diese wiederum für ihre eigenen **Hyper-V-Gast-VMs** virtualisieren oder aufteilen. Hier kommen Technologien wie **NVIDIA vGPU**, **AMD MxGPU** oder **SR-IOV** ins Spiel.
Diese „doppelte Indirektion” – zuerst Proxmox, dann Hyper-V – macht die Sache so kompliziert. Lassen Sie uns die einzelnen Schritte im Detail beleuchten.
Grundlagen und Voraussetzungen: Was Sie benötigen
Bevor Sie überhaupt anfangen, stellen Sie sicher, dass Ihre Hardware die folgenden Voraussetzungen erfüllt:
* **Proxmox-Host**: Ein leistungsstarker Server mit Proxmox VE 7.x oder neuer.
* **CPU mit IOMMU-Unterstützung**: Sowohl Intel VT-d als auch AMD-Vi (AMD-IOMMU) sind absolut unerlässlich. Überprüfen Sie dies im BIOS/UEFI und in Ihrem Proxmox-System.
* **Kompatible GPU**:
* **NVIDIA**: Für echtes **GPU Splitting** innerhalb von Hyper-V sind NVIDIA Quadro-, Tesla- oder A-Serien-Karten mit **NVIDIA vGPU**-Unterstützung (und entsprechende Lizenzen!) die erste Wahl. Consumer-Karten wie GeForce unterstützen vGPU nicht nativ auf dieser Ebene.
* **AMD**: AMD Radeon Pro (z.B. WX-Serie) oder Instinct-Karten mit **MxGPU**-Unterstützung.
* **Intel iGPUs**: Bestimmte Intel Integrated GPUs (iGPUs) können mit **GVT-g** eine Form des GPU-Sharings bieten, auch wenn das Passthrough einer iGPU an eine Windows-VM und die weitere Aufteilung komplex ist.
* **Genügend RAM**: Jede VM, die auf die GPU zugreift, benötigt ausreichend RAM.
* **Speicherplatz**: Schneller Speicher (SSD/NVMe) für Proxmox und alle VMs ist dringend empfohlen.
* **Windows VM**: Eine Windows Server Edition (z.B. 2019/2022) mit installierter **Hyper-V-Rolle** oder eine Windows 10/11 Pro Edition mit aktivierter Hyper-V-Funktion.
Schritt 1: Proxmox Host Konfiguration für GPU Passthrough
Der erste Schritt ist, Ihre physische **GPU** von Proxmox für die **Windows-VM** verfügbar zu machen.
1.1 IOMMU im BIOS/UEFI aktivieren
Starten Sie Ihren Server neu und gehen Sie ins BIOS/UEFI. Suchen Sie nach Optionen wie „Intel VT-d”, „AMD-Vi”, „IOMMU” oder „Virtualization Technology” und aktivieren Sie diese. Speichern und neu starten.
1.2 Proxmox Kernel-Parameter anpassen
Melden Sie sich per SSH am Proxmox-Host an und bearbeiten Sie die GRUB-Konfiguration:
* Für Intel:
„`bash
nano /etc/default/grub
„`
Fügen Sie zu `GRUB_CMDLINE_LINUX_DEFAULT` Folgendes hinzu: `intel_iommu=on iommu=pt`
Beispiel: `GRUB_CMDLINE_LINUX_DEFAULT=”quiet intel_iommu=on iommu=pt”`
* Für AMD:
„`bash
nano /etc/default/grub
„`
Fügen Sie zu `GRUB_CMDLINE_LINUX_DEFAULT` Folgendes hinzu: `amd_iommu=on iommu=pt`
Beispiel: `GRUB_CMDLINE_LINUX_DEFAULT=”quiet amd_iommu=on iommu=pt”`
Speichern Sie die Datei (`Ctrl+O`, `Enter`, `Ctrl+X`) und aktualisieren Sie GRUB:
„`bash
update-grub
„`
1.3 Notwendige Module laden
Bearbeiten Sie die Datei `/etc/modules`:
„`bash
nano /etc/modules
„`
Fügen Sie folgende Zeilen hinzu:
„`
vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd
„`
Speichern und schließen Sie die Datei.
1.4 GPU-Treiber auf Proxmox Blacklisten
Um zu verhindern, dass Proxmox die **GPU** selbst nutzt, müssen deren Treiber deaktiviert werden. Finden Sie die Vendor- und Device-ID Ihrer GPU:
„`bash
lspci -nn | grep -i vga
„`
Sie sehen eine Ausgabe wie `01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP104 [GeForce GTX 1070] [10de:1b81] (rev a1)`. Die IDs sind `10de:1b81`.
Erstellen Sie eine Blacklist-Datei:
„`bash
echo „blacklist nouveau” >> /etc/modprobe.d/blacklist.conf
echo „blacklist radeon” >> /etc/modprobe.d/blacklist.conf
echo „blacklist amdgpu” >> /etc/modprobe.d/blacklist.conf
echo „blacklist nvidia” >> /etc/modprobe.d/blacklist.conf
„`
Erstellen Sie eine Konfigurationsdatei für `vfio`:
„`bash
echo „options vfio-pci ids=10de:1b81 disable_vga=1” > /etc/modprobe.d/vfio-pci.conf
„`
Ersetzen Sie `10de:1b81` durch die IDs Ihrer GPU. `disable_vga=1` ist wichtig, wenn es die primäre GPU ist.
Aktualisieren Sie das Initramfs:
„`bash
update-initramfs -u -k all
„`
Starten Sie den Proxmox-Host neu:
„`bash
reboot
„`
Nach dem Neustart überprüfen Sie, ob die GPU vom `vfio-pci`-Treiber beansprucht wird:
„`bash
lspci -nnk | grep -i vga -A 3
„`
Unter `Kernel driver in use` sollte `vfio-pci` stehen.
1.5 GPU an die Windows-VM durchreichen (PCI Passthrough)
Navigieren Sie in der Proxmox Web-Oberfläche zu Ihrer **Windows-VM**.
1. **Hardware** -> **Add** -> **PCI Device**.
2. Wählen Sie Ihre **GPU** aus der Liste aus.
3. Aktivieren Sie **”All Functions”** und **”Primary GPU”** (falls dies die einzige GPU ist).
4. Wählen Sie **”RomBar”** aus (dies hilft bei einigen GPUs).
5. Stellen Sie sicher, dass das **QEMU-Gastagent-Paket** in der VM installiert ist.
Schritt 2: Windows-VM (Hyper-V Host) Konfiguration und GPU Splitting
Dieser Schritt ist das Herzstück des „Nussknackens”. Wir müssen die Windows-VM dazu bringen, die durchgereichte GPU zu nutzen und diese dann für ihre eigenen Hyper-V-Gäste aufzuteilen.
2.1 Nested Virtualization für die Windows-VM aktivieren
Damit Ihre Windows-VM selbst als **Hyper-V-Host** agieren kann, müssen Sie **Nested Virtualization** auf dem Proxmox-Host für diese spezifische VM aktivieren. Dies geschieht per SSH auf dem Proxmox-Host:
„`bash
qm set
„`
Ersetzen Sie `
2.2 GPU-Treiber in der Windows-VM installieren
Starten Sie die **Windows-VM**. Sobald Windows hochgefahren ist, installieren Sie die offiziellen Treiber für Ihre durchgereichte **GPU**. Stellen Sie sicher, dass Sie die neuesten stabilen Treiber von der Hersteller-Website verwenden. Nach der Installation sollte die GPU im Geräte-Manager von Windows sichtbar und fehlerfrei sein.
2.3 Die eigentliche GPU-Aufteilung innerhalb von Hyper-V
Jetzt kommt der schwierigste Teil: Die **GPU-Aufteilung** für die **Hyper-V-Gäste**. Da Sie die *gesamte physische* GPU per Passthrough an die Windows-VM (Ihren Hyper-V-Host) übergeben haben, muss dieser Hyper-V-Host nun die Aufteilung übernehmen. Hier sind die gängigsten Optionen:
Option A: NVIDIA vGPU (die bevorzugte Lösung für echtes Splitting)
Wenn Sie eine **NVIDIA Quadro**, **Tesla** oder **A-Serie GPU** verwenden, ist **NVIDIA vGPU** die leistungsstärkste und flexibelste Methode. Sie ermöglicht es, die GPU in mehrere virtuelle GPUs (vGPUs) zu unterteilen, die dann jeweils dediziert einer Hyper-V-Gast-VM zugewiesen werden.
**Voraussetzungen für NVIDIA vGPU auf Hyper-V:**
* Kompatible NVIDIA GPU (Quadro, Tesla, A-Serie).
* **NVIDIA vGPU Software**: Spezielle Treiber für den Hyper-V-Host und die Gast-VMs. Diese sind lizenzpflichtig.
* **NVIDIA Lizenzserver**: Erforderlich, um die vGPU-Lizenzen zu verwalten und bereitzustellen.
**Schritte (Kurzfassung):**
1. **NVIDIA vGPU Manager auf dem Windows-VM (Hyper-V-Host) installieren**: Dies sind spezielle Treiber, die die Virtualisierungsfunktionalität der GPU auf Hyper-V ermöglichen.
2. **vGPU-Profile erstellen**: Mit den NVIDIA-Tools definieren Sie, wie viele vGPUs Sie erstellen möchten und wie viele Ressourcen (RAM, Rechenkerne) jede vGPU erhalten soll (z.B. Quadro vGPU C-Series).
3. **vGPU den Hyper-V-Gast-VMs zuweisen**: Verwenden Sie PowerShell auf dem Hyper-V-Host:
„`powershell
# Beispiel: Eine VM namens ‘MyHyperVGuest’ eine vGPU zuweisen
Add-VMGpuPartitionAdapter -VMName „MyHyperVGuest” -PartitionProfile „Quadro-C-2Q”
„`
Wählen Sie das passende Profil für Ihre Bedürfnisse.
4. **NVIDIA vGPU Guest Driver in den Hyper-V-Gast-VMs installieren**: Jede Gast-VM benötigt den passenden NVIDIA vGPU-Treiber, damit sie die virtuelle GPU erkennt und nutzen kann.
5. **NVIDIA Lizenzserver konfigurieren**: Die Gast-VMs müssen Zugriff auf den Lizenzserver haben, um ihre vGPU-Lizenzen zu beziehen.
**Wichtig**: Consumer-Karten wie GeForce RTX unterstützen vGPU auf dieser Ebene *nicht*. Versuche, diese zum Laufen zu bringen, erfordern in der Regel nicht unterstützte „Hack”-Treiber, die instabil sind und gegen die EULAs von NVIDIA verstoßen.
Option B: AMD MxGPU
Ähnlich wie NVIDIA vGPU bietet AMD mit **MxGPU** eine vergleichbare Technologie für ihre Radeon Pro und Instinct GPUs. Der Prozess ist konzeptionell ähnlich: Installation spezieller Host-Treiber, Zuweisung von GPU-Profilen an Gast-VMs und Installation von Gast-Treibern. Auch hier sind spezielle Hardware und Lizenzen erforderlich.
Option C: SR-IOV (Single Root I/O Virtualization) oder DDA (Discrete Device Assignment)
* **SR-IOV**: Einige Server-GPUs und Intel iGPUs unterstützen **SR-IOV**. Dies ist eine Hardware-Virtualisierungstechnologie, die die physische GPU in mehrere „virtuelle Funktionen” (VFs) aufteilt. Jede VF kann dann direkt einer VM zugewiesen werden. Wenn Ihre GPU SR-IOV unterstützt und der Treiber im Windows-VM (Hyper-V-Host) dies auch erlaubt, wäre dies eine elegante Lösung. Leider ist die Unterstützung für SR-IOV bei diskreten Consumer-GPUs selten.
* **DDA (Discrete Device Assignment)**: Dies ist im Grunde ein **PCI Passthrough** innerhalb von Hyper-V. Sie können eine gesamte GPU von Ihrem Hyper-V-Host an eine *einzelne* Hyper-V-Gast-VM durchreichen. Dies ist **kein Splitting**, sondern eine dedizierte Zuweisung. Wenn Sie also die GPU an *eine* Hyper-V-VM übergeben wollen, ist DDA eine Option, aber eben nicht für mehrere gleichzeitig.
Option D: Intel GVT-g (für integrierte GPUs)
Wenn Sie eine Intel CPU mit integrierter GPU (iGPU) verwenden, die **GVT-g** unterstützt, könnten Sie theoretisch die iGPU per Passthrough an die Windows-VM übergeben und dann GVT-g-Funktionen innerhalb der Hyper-V-Umgebung nutzen. Dies ist jedoch noch experimenteller und weniger dokumentiert für diesen spezifischen Anwendungsfall.
Troubleshooting: Häufige Probleme und Lösungen
* **IOMMU-Gruppenfehler**: Wenn die GPU nicht allein in einer IOMMU-Gruppe ist, können andere Geräte in derselben Gruppe Probleme verursachen. Versuchen Sie, die Geräte im BIOS zu verschieben oder ACS Override zu verwenden (auf eigene Gefahr).
* **Fehlende `vfio-pci`-Bindung**: Überprüfen Sie erneut, ob der `vfio-pci`-Treiber die GPU beansprucht. Ein `reboot` nach allen Kernel-Parametern ist oft entscheidend.
* **Fehlercode 43 in Windows**: Dies ist ein häufiges Problem bei NVIDIA Consumer-Karten im Passthrough-Betrieb. Es deutet darauf hin, dass der Treiber erkennt, dass er in einer virtuellen Umgebung läuft. Für vGPU ist dies normal und wird durch die speziellen vGPU-Treiber und Lizenzen gelöst. Für Consumer-Karten gibt es keine offizielle Lösung außer Workarounds, die nicht unterstützt werden.
* **Netzwerkprobleme in Hyper-V-Gästen**: Stellen Sie sicher, dass die Netzwerkadapter der Hyper-V-Gäste richtig konfiguriert sind und die **Windows-VM** als Router/Bridge fungiert.
* **Leistungsprobleme**: Überprüfen Sie, ob die vGPU-Profile ausreichend Ressourcen zuweisen und ob der Lizenzserver korrekt funktioniert.
Performance und Überlegungen
* **Overhead**: Jede Schicht der Virtualisierung (Proxmox, dann Hyper-V) und jede Virtualisierungstechnologie (PCI Passthrough, vGPU) führt zu einem gewissen Leistungs-Overhead. Die Performance wird nie 100 % der nativen Hardware erreichen.
* **Lizenzkosten**: Insbesondere NVIDIA vGPU ist mit erheblichen Lizenzkosten verbunden, die sowohl die vGPU-Software als auch den Lizenzserver umfassen.
* **Komplexität**: Diese Konfiguration ist nicht für Anfänger geeignet. Sie erfordert tiefgehende Kenntnisse von Proxmox, Hyper-V, GPU-Virtualisierung und Treiber-Management.
Fazit: Ist die Nuss geknackt?
Ja, die Nuss lässt sich knacken! Allerdings ist der Weg dorthin steinig und erfordert präzises Vorgehen sowie die richtige Hardware. Das **GPU Splitting** für **Hyper-V-VMs** innerhalb einer **Proxmox-VM** ist eine absolute Königsklasse der Virtualisierung.
Für die meisten Anwendungsfälle, insbesondere im professionellen Umfeld, ist **NVIDIA vGPU** die robusteste und am besten unterstützte Lösung, trotz ihrer Komplexität und Lizenzkosten. Für Bastler und Heimanwender mit Consumer-Karten ist dieser Ansatz leider in der Regel nicht praktikabel oder nur mit nicht unterstützten Hacks realisierbar.
Indem Sie diesen detaillierten Schritten folgen, haben Sie das nötige Wissen an der Hand, um diese fortschrittliche Konfiguration zu implementieren und die volle Leistung Ihrer **GPU** für eine Vielzahl von virtuellen Workloads zu erschließen. Viel Erfolg beim Experimentieren und Optimieren – Ihre virtuellen Umgebungen werden es Ihnen danken!