Intel-GPUs mit Proxmox VE: Treiber, Nutzungsmuster, Stolpersteine

Wenn eine Intel-GPU im Proxmox-Host steckt, sind die ersten Fragen meistens dieselben. Welcher Treiber wird geladen? Geht das in einen LXC oder muss es eine VM sein? Wie viele VMs kann sich die Karte teilen? Und an welcher Stelle sitzt der Fallstrick, den man im Forum sieht und selber lieber vermeiden würde? Dieser Artikel beantwortet diese Fragen für ein Spektrum von Karten von der Mini-PC-iGPU bis zur Arc Pro B60 in einer Form, mit der ein Admin die Architektur für den eigenen Workload entscheiden kann, bevor er die Karte einsteckt.

Hardware und Treiber: was Sie tatsächlich vor sich haben

Proxmox VE 9 nutzt zwei verschiedene Linux-Kernel-Treiber für Intel-Grafik. Welcher davon greift, hängt von der GPU-Generation ab.

i915. Der etablierte Treiber für integrierte Intel-Grafik der Generationen 7 bis 12, also alles von Skylake über Tiger Lake bis Alder Lake. Er deckt auch die meisten iGPUs in NUCs, Mini-PCs und älteren Xeon-E-Plattformen ab. SR-IOV auf älteren iGPUs läuft hier nur über DKMS-Module aus Intels GitHub, in den Mainline-Kernel wandert das schrittweise.

xe. Der neue Treiber für die Battlemage-Generation, also Arc Pro B50, B60 und kommende Karten derselben Familie. Auch neuere iGPUs ab Lunar Lake und Arrow Lake werden zunehmend von xe statt i915 bedient. xe ist seit Kernel 6.11 produktionsreif, für SR-IOV auf der B-Serie braucht es 6.17 oder neuer. Proxmox VE 9.1 mit dem 6.17er Kernel ist die erste sinnvolle Ausgangsbasis.

Die Treiberwahl ist nicht konfigurierbar im klassischen Sinne. Der Kernel entscheidet anhand der PCI-ID, welcher Treiber das Gerät übernimmt. Wer auf einem Server mit Arc Pro B50 das lspci -nnk aufruft und unter "Kernel driver in use" nichts sieht, hat in neun von zehn Fällen den xe-Treiber im Kernel-Cmdline blacklisted oder vfio-pci mit Vendor-IDs hartcodiert. Beides muss raus, bevor SR-IOV funktioniert.

Drei Nutzungsmuster

In der Praxis tauchen drei sinnvolle Architekturmuster auf, jedes mit eigenem Use Case.

Muster 1: LXC mit Device Passthrough. Die GPU bleibt im Host, einzelne LXC-Container bekommen Zugriff auf /dev/dri/card0 und /dev/dri/renderD128. Mehrere Container können sich denselben Render-Node teilen, ohne dass die Hardware partitioniert werden muss. Klassische Einsatzszenarien: Plex- oder Jellyfin-Transcoding mit Intel Quick Sync, Frigate für Objektdetection, ein Ollama-Container mit XPU-Backend, oder ein Kasm-Workspace-Agent. In Proxmox 8.2 und 9.x gibt es im GUI den Punkt "Device Passthrough" unter Resources, der die manuelle Pflege von lxc.cgroup2.devices.allow und lxc.mount.entry in /etc/pve/lxc/<id>.conf ersetzt. Wichtig ist die korrekte UID/GID-Zuordnung, am sinnvollsten die GID der render-Gruppe im Container. Wer intel-gpu-tools im Container installiert und intel_gpu_top startet, sieht die tatsächliche Auslastung pro Engine.

Muster 2: VM mit vollständigem PCI-Passthrough. Die gesamte Karte wandert in genau eine VM. Sinnvoll für Workloads, die eine Karte exklusiv brauchen: eine einzelne KI-Inferenz-VM mit vLLM auf einer Arc Pro B60, eine Windows-VM mit CAD-Anwendung, ein Test-Setup für Treiber-Validierung. Hier wird der xe-Treiber im Host für diese PCI-Adresse durch vfio-pci ersetzt, die Karte taucht im Gast als physische GPU auf. Im Gast wird der reguläre Intel-Treiber installiert, unter Linux ist das xe, unter Windows der Arc-Pro-Workstation-Treiber.

Muster 3: VM mit SR-IOV. Die Karte wird über Virtual Functions in mehrere logische GPUs zerlegt, jede VF wandert in eine eigene VM. Das ist das vGPU-Äquivalent ohne Lizenzbindung. Klassisch für VDI mit getrennten Mandanten oder gemischte Workloads, etwa mehrere Linux-Kasm-Knoten plus eine Windows-CAD-VM auf derselben Karte. Aktuell stabil auf der B50 mit zwei bis sechs VFs, je nach Firmware-Stand. Auf der B60 funktioniert SR-IOV grundsätzlich, ist aber treiberseitig noch in der Reifephase.

Host-Vorbereitung: was im BIOS und in der Kernel-Cmdline stehen muss

Diese Einstellungen sind im UEFI Pflicht, sonst läuft entweder gar nichts oder es bricht später unmotiviert ab:

• VT-d (Intel) oder AMD-Vi aktiviert
• SR-IOV aktiviert (nicht jedes Board hat den Punkt, ältere Mehlow-basierte Xeon-E-Plattformen unterstützen es überhaupt nicht)
• Above 4G Decoding aktiviert
• Resizable BAR aktiviert
• CSM deaktiviert, UEFI-Boot zwingend

In der Kernel-Cmdline gehören mindestens intel_iommu=on iommu=pt. Auf AMD-Systemen analog amd_iommu=on iommu=pt. Wenn die IOMMU-Gruppen nicht sauber separieren, hilft pcie_acs_override=downstream,multifunction. Was definitiv nicht in die Cmdline gehört, ist modprobe.blacklist=xe oder modprobe.blacklist=i915. Genau das ist der Fehler, der in Foren oft als "xe-Treiber bindet nicht" auftaucht: der Treiber wurde aktiv geblockt.

Für SR-IOV gilt zusätzlich: der PF (Physical Function) bleibt am xe-Treiber. Nur die VFs werden bei Bedarf an vfio-pci gebunden, und das macht Proxmox beim Start der VM automatisch. Wer global mit vfio-pci ids=8086:e212 arbeitet, schießt sich den PF kaputt und dreht eine halbe Nacht im Kreis.

Der Firmware-Stolperstein

Die Arc Pro B50 hat einen Fall, der in der ersten Generation viele Stunden gekostet hat. Die Firmware-Version aus Q3 2025 erlaubt typischerweise sechs VFs pro Karte. Das Q4-2025-Update reduziert die maximale VF-Zahl auf zwei. Was als Stabilitäts-Update beworben wird, ist für SR-IOV-Szenarien eine Regression.

Praktisch heißt das: vor jedem Firmware-Update auf einer produktiven Karte prüfen, welche VF-Anzahl die neue Version freigibt. Intel dokumentiert das nicht prominent in den Release Notes, die Information steht in den Foren von Level1Techs und im Proxmox-Forum. Wer auf eine bestimmte VF-Anzahl angewiesen ist, hält das Firmware-Update kontrolliert und plant einen Fallback. Auf der B60 ist die Firmware-Lage weniger volatil, weil die Karte ohnehin noch in der Stabilisierungsphase ist.

SR-IOV in der Praxis: was der Befehl eigentlich macht

Nach erfolgreichem Host-Setup ist der eigentliche SR-IOV-Befehl überschaubar. Über die sysfs-Pfade:

echo 0 > /sys/bus/pci/devices/0000:03:00.0/sriov_numvfs
echo 6 > /sys/bus/pci/devices/0000:03:00.0/sriov_numvfs

Zuerst auf null, dann auf die Zielanzahl. Ohne das vorherige Nullen kommt es zu Fehlern, wenn die Anzahl im laufenden Betrieb geändert werden soll. Persistenz erreicht man über /etc/sysfs.conf mit dem Paket sysfsutils.

Die entstehenden VFs erscheinen als zusätzliche PCI-Funktionen unter derselben Geräteadresse mit Endung .1, .2 und so weiter. In der Proxmox-GUI werden sie unter "Datacenter" zu "Resource Mappings" als PCI-Devices angelegt und in der VM-Konfiguration referenziert. lspci -nnk zeigt beim PF weiterhin xe, bei den VFs erst dann vfio-pci, wenn eine VM mit der entsprechenden Zuweisung startet.

Was nicht funktioniert: Live-Migration, Snapshots, HA

Drei Punkte verdienen klare Aussagen, weil sie regelmäßig zu spät auf den Tisch kommen.

Live-Migration. Funktioniert nicht für VMs mit PCI-Passthrough oder VF-Zuweisung. Eine VM mit GPU lässt sich nicht im laufenden Betrieb auf einen anderen Knoten verschieben. Wer das braucht, plant geplante Wartungsfenster mit Shutdown ein oder verlagert den entsprechenden Service auf eine VM ohne GPU-Bindung.

Snapshots. Mit PCI-Passthrough oft eingeschränkt. Speicher-Snapshots funktionieren, RAM-Snapshots sind problematisch. In der Praxis sichert man VMs mit GPU besser über Backups mit kurzem Downtime statt über Snapshot-basierte Verfahren.

HA. Möglich, aber nur mit homogener GPU-Konfiguration über die HA-fähigen Knoten. Wenn ein Knoten eine B50 hat und der andere eine B60, lässt sich die VM zwar zwischen den Knoten verschieben, aber die VF-Konfiguration muss übereinstimmen, sonst startet die VM auf dem Zielknoten nicht.

Monitoring

intel_gpu_top aus dem Paket intel-gpu-tools zeigt die Auslastung pro Render- und Video-Engine in Echtzeit. Funktioniert auf dem Host genauso wie in einem LXC mit Passthrough. Für aggregiertes Monitoring per Prometheus gibt es Exporter, die intern auf denselben sysfs-Pfaden basieren. Wer parallel CPU- und Memory-Telemetrie aus Proxmox zieht, hat damit ein vollständiges Bild der Lastverteilung.

Schnelle Entscheidungshilfe

Mehrere Linux-Container, gemeinsame GPU. LXC mit Device Passthrough. Einfachste Variante, keine Partitionierung nötig.

Eine VM, eine ganze Karte. Vollständiger PCI-Passthrough. Geringster Konfigurationsaufwand für maximale Leistung.

Mehrere VMs, eine Karte, harte Trennung. SR-IOV mit B50, aktuell stabil. B60, wenn Treiberreife in 2026 ankommt.

Plex-Transcoding im Homelab oder kleinen Setup. LXC mit Quick Sync auf iGPU. Klassischer Fall, in 30 Minuten produktiv.

VDI mit getrennten Mandanten. SR-IOV auf B50 oder B60, je nach VRAM-Bedarf, in Kombination mit Kasm oder Horizon.

Lokale LLM-Inferenz. LXC mit Ollama oder vLLM-XPU bei einem einzelnen Modell. VM mit voller Karte bei Multi-Modell-Betrieb oder mehreren parallelen Workloads.

Einordnung

Intel-GPUs auf Proxmox VE sind kein Bastel-Setup mehr, aber auch keine Click-Through-Installation. Die Treiberkette ist klar dokumentiert, die Werkzeuge im Kernel und in der Proxmox-GUI sind vorhanden, die Reifephase auf der B-Serie schreitet voran. Wer die fünf BIOS-Punkte ernst nimmt, die Kernel-Cmdline sauber hält und das Firmware-Thema kontrolliert angeht, kommt zu einem produktiv tragfähigen Setup. Wer einen der drei Use Cases (Container-Sharing, exklusives Passthrough, SR-IOV) klar einem Workload zuordnet, spart sich die meisten Stolpersteine, die in den Forenthreads dominieren.