GPU-Passthrough und NVIDIA vGPU auf Proxmox: So läuft LLM-Hosting nahe Bare-Metal

Warum GPU-Virtualisierung für LLM-Hosting überhaupt relevant ist

Die Ausgangslage ist in fast jedem Mittelstandsprojekt dieselbe: Ein Unternehmen will nicht nur ein Sprachmodell betreiben, sondern mehrere – ein kompaktes 8B-Modell für schnelle Standardanfragen, ein 70B-Modell für komplexe Aufgaben mit hohem Anspruch an Reasoning, dazu ein separates Embedding-Modell für die RAG-Pipeline. Für jeden dieser drei Anwendungsfälle eine eigene physische GPU zu kaufen, ist bei den aktuellen Hardwarepreisen kein realistischer Weg mehr. Der DRAM- und HBM-Preisschock des Jahres 2026 hat die Beschaffungskosten für GPU-Server spürbar nach oben getrieben – GPU-Konsolidierung auf einem einzigen Server ist damit wirtschaftlich relevanter geworden als noch vor zwei Jahren, nicht nur eine Frage der Rackfläche.

Für diese Konsolidierung gibt es unter Proxmox VE grundsätzlich zwei belastbare technische Wege. Der erste ist VFIO-Passthrough: Eine physische GPU wird exklusiv einer einzigen virtuellen Maschine zugewiesen, mit direktem PCIe-Zugriff und ohne Geräteemulation. Der zweite ist NVIDIA vGPU: Eine physische Karte wird in mehrere virtuelle GPU-Profile mit jeweils festem VRAM-Anteil aufgeteilt, sodass mehrere VMs gleichzeitig und unabhängig voneinander auf derselben Karte arbeiten.

Beide Wege sind ausdrücklich von Docker- oder Kubernetes-GPU-Sharing zu unterscheiden, wie es NVIDIA-Runtime-Zeitscheiben oder MPS auf Container-Ebene bieten. Dort teilen sich mehrere Prozesse denselben Treiberkontext ohne echte Hypervisor-Isolation – ein Absturz oder ein Speicherleck in einem Container kann den gesamten GPU-Kontext destabilisieren. Passthrough und vGPU arbeiten dagegen unterhalb der VM-Grenze: Jede virtuelle Maschine hat ihren eigenen, isolierten Blick auf die Hardware oder ihr Profil, mit entsprechend höherer Betriebssicherheit für produktive LLM-Dienste.

Für Proxmox als Hypervisor-Basis spricht dabei nicht nur der Lizenzpreis gegenüber VMware oder Nutanix, sondern auch die Tatsache, dass beide GPU-Virtualisierungswege inzwischen aus einer einzigen, offen dokumentierten Verwaltungsoberfläche heraus konfiguriert werden können. Wer heute einen GPU-Server für LLM-Hosting plant, muss die Entscheidung zwischen Passthrough und vGPU außerdem nicht einmalig und dauerhaft treffen: Beide Verfahren lassen sich, wie weiter unten gezeigt, im selben Cluster auf unterschiedlichen Karten parallel betreiben und je nach Workload nachträglich anpassen.

VFIO-GPU-Passthrough: Wie nah kommt man an Bare-Metal-Performance?

Die für viele überraschendste Zahl in diesem gesamten Themenfeld ist der tatsächliche Performance-Verlust von VFIO-Passthrough. Aktuelle Benchmarks aus 2026 zu CUDA- und LLM-Inferenz-Workloads zeigen einen Overhead von rund 0,4 bis 3 % gegenüber einer Bare-Metal-Installation. Für sustained-Workloads – also Dauerlast, wie sie ein produktiver LLM-Dienst erzeugt – ist ein Praxiswert von 1 bis 3 % realistisch. Bei reinen Inferenzlasten ohne nennenswerten Host-Guest-Datenverkehr liegt der Wert häufig sogar unter 2 %.

Die technische Erklärung dafür ist einfacher, als die Zahl vermuten lässt: Bei VFIO-Passthrough emuliert der Hypervisor kein Gerät. Die VM erhält direkten PCIe-Zugriff auf die physische Karte, der CUDA-Treiber im Gast spricht praktisch unverändert mit der Hardware. Die IOMMU (Intel VT-d bzw. AMD-Vi) ist ausschließlich für die Isolation des Adressraums zuständig, nicht für eine laufende Übersetzung von Speicherzugriffen während der Berechnung. Es gibt keine Interrupt-Storm-Problematik, wie sie bei emulierten Geräten unter Dauerlast auftreten kann, weil MSI-X-Interrupts direkt an die VM durchgereicht werden.

Workload-Typ	Typischer Overhead	Grund
Reine LLM-Inferenz (Batch, Prefill/Decode)	0,4–2 %	Rechenlast bleibt vollständig auf der GPU, kaum Host-Interaktion
Sustained CUDA-Dauerlast (Training, Fine-Tuning)	1–3 %	Praxiswert für anhaltende Volllast, gilt als solide Planungsgröße
Streaming/Preprocessing mit viel Host-Guest-Verkehr	variabel, teils höher	Häufige Datenübergaben zwischen Host und Gast schlagen stärker durch

Für die reine LLM-Inferenz – dem mit Abstand häufigsten Anwendungsfall im Mittelstand – ist Passthrough damit praktisch gleichwertig mit Bare-Metal. Der Konfigurationsaufwand, der nötig ist, um dorthin zu kommen, wird in der Praxis regelmäßig unterschätzt: Eine unsaubere IOMMU-Konfiguration mit unnötigen Interrupt-Remapping-Umwegen kann den Overhead deutlich über die genannte Spanne treiben, ohne dass dies auf den ersten Blick als Konfigurationsfehler erkennbar wäre.

Technische Voraussetzungen: IOMMU, BIOS und Bootloader korrekt konfigurieren

Bevor überhaupt eine VM mit durchgereichter GPU startet, müssen drei Ebenen korrekt zusammenspielen: BIOS/UEFI, Kernel-Bootparameter und die IOMMU-Gruppierung der Hardware selbst.

BIOS/UEFI-Einstellungen

• IOMMU aktivieren. Bei Intel-Systemen als „VT-d", bei AMD-Systemen als „AMD-Vi" oder „SVM IOMMU" bezeichnet. Ohne diese Einstellung schlägt jeder Passthrough-Versuch fehl, unabhängig von der Kernel-Konfiguration.
• Above-4G-Decoding aktivieren. Notwendig, damit große PCIe-BARs (wie sie moderne Datacenter-GPUs mit viel VRAM mitbringen) korrekt in den Adressraum eingeblendet werden.
• Secure Boot deaktivieren (sofern nicht explizit für signierte VFIO-Module konfiguriert). In den meisten Proxmox-Setups vereinfacht das Deaktivieren den Modul-Load erheblich.

Bootloader-Parameter

Zusätzlich zur BIOS-Einstellung muss der Kernel selbst angewiesen werden, IOMMU zu nutzen. Unter Proxmox VE (auf Basis von /etc/kernel/cmdline bei systemd-boot oder GRUB) gehören folgende Parameter gesetzt:

• intel_iommu=on auf Intel-Plattformen bzw. amd_iommu=on auf AMD-Plattformen
• iommu=pt (Passthrough-Modus für Geräte, die nicht durchgereicht werden, reduziert unnötigen Übersetzungsaufwand)

Ein häufig übersehener Punkt: Ab Kernel 6.8 ist IOMMU bei AMD-Systemen und teilweise auch bei Intel-Systemen bereits standardmäßig aktiv. Das ändert nichts daran, dass die explizite Konfiguration empfohlen bleibt – sie stellt sicher, dass sich das Verhalten nicht mit künftigen Kernel- oder Distributions-Updates stillschweigend ändert, und macht die Konfiguration für andere Administratoren nachvollziehbar.

IOMMU-Gruppen prüfen

Die mit Abstand häufigste Ursache für gescheiterte Passthrough-Versuche ist eine GPU, die sich in derselben IOMMU-Gruppe wie andere Geräte befindet – etwa ein USB-Controller oder ein zweiter PCIe-Slot, der über denselben Root-Port läuft. Eine GPU lässt sich nur dann sauber durchreichen, wenn ihre gesamte IOMMU-Gruppe ausschließlich Geräte enthält, die ebenfalls der Ziel-VM zugewiesen werden können. Die Gruppierung lässt sich über ein einfaches Shell-Skript auslesen, das die Verzeichnisse unter /sys/kernel/iommu_groups/ durchläuft und pro Gruppe die zugehörigen PCI-Geräte per lspci auflistet. Wer beim Server-Kauf die Wahl hat, sollte auf ein Mainboard mit sauberer PCIe-Topologie achten – das erspart im Zweifel tagelange Fehlersuche.

GPU-Passthrough in Proxmox einrichten: Praxis-Anleitung Schritt für Schritt

Ist die IOMMU-Grundlage geschaffen, folgt die eigentliche Einrichtung in Proxmox VE:

1. VFIO-Treiber laden. Die Kernelmodule vfio, vfio_iommu_type1 und vfio_pci werden über /etc/modules beim Boot geladen.
2. GPU vom Host-Treiber fernhalten. Die PCI-Vendor-/Device-IDs der Ziel-GPU (per lspci -nn ermittelt) werden über vfio-pci.ids= als Kernel-Parameter oder per Modul-Konfigurationsdatei an vfio-pci gebunden, damit der native NVIDIA- oder Nouveau-Treiber des Hosts die Karte nicht zuerst greift.
3. VM mit q35 und OVMF anlegen. Für GPU-Passthrough sollte die VM den Maschinentyp q35 (statt des älteren i440fx) und OVMF/UEFI-BIOS statt SeaBIOS verwenden – das entspricht dem PCIe-Verhalten moderner Hardware deutlich besser und vermeidet diverse Kompatibilitätsprobleme.
4. PCI-Gerät zuweisen. Im Proxmox-Webinterface wird die GPU als „PCI Device" hinzugefügt, mit aktivierten Optionen „All Functions" (damit Grafik- und Audio-Funktion der Karte gemeinsam durchgereicht werden), „PCI-Express" und „ROM-Bar".

Ein Stolperstein, der in Foren regelmäßig für Verwirrung sorgt: NVIDIA-Consumer-Treiber (GeForce) erkennen aktiv, ob sie in einer virtualisierten Umgebung laufen, und verweigern mit dem berüchtigten Code 43 den Dienst. Der gängige Workaround besteht darin, in der VM-Konfiguration die Hypervisor-Kennung zu verschleiern (Vendor-ID-Spoofing über zusätzliche args:-Zeilen in der VM-Konfigurationsdatei), sodass der Treiber im Gast keine Virtualisierung erkennt. Bei NVIDIA-Datacenter- und Pro-Karten tritt dieses Problem in der Regel nicht auf, da deren Treiber Virtualisierung offiziell unterstützen.

Wer keine vollständige VM, sondern einen leichtgewichtigen LXC-Container betreiben möchte – etwa für einen einzelnen vLLM-Server – kommt mit einem einfacheren Weg aus: cgroup-basiertem Device-Passthrough. Dabei wird kein vollständiges IOMMU-Passthrough benötigt, weil der Container ohnehin den Host-Kernel nutzt; es reicht, die entsprechenden Gerätedateien (/dev/nvidia*) über die Container-Konfiguration freizugeben. Das ist schneller eingerichtet, bietet aber weniger Isolation als eine vollständige VM – für einen dedizierten, vertrauenswürdigen LLM-Dienst in der Praxis meist ein akzeptabler Kompromiss.

vGPU vs. Passthrough: Wann lohnt sich welcher Ansatz für mehrere LLM-VMs?

Beide Verfahren lösen unterschiedliche Probleme, und die Entscheidung sollte anhand des tatsächlichen Nutzungsmusters getroffen werden, nicht anhand dessen, was gerade als moderner gilt.

Kriterium	VFIO-Passthrough	NVIDIA vGPU
Performance	maximal, 1–3 % Overhead	gut, zzgl. leichtem Scheduling-Overhead je Profil
GPU-Nutzung pro Karte	1 GPU = exklusiv 1 VM	1 GPU = mehrere VMs mit festem VRAM-Anteil
Live-Migration	nicht möglich	möglich (abhängig von Treiber-/Lizenzversion)
Lizenzkosten	keine	vGPU-Entitlement pro Karte/Nutzer erforderlich
Ideal für	1 Workload mit Maximalanspruch an Durchsatz	2–4 parallele LLM-Workloads auf einer Karte

Für kleine und mittlere Unternehmen mit zwei bis vier parallel laufenden LLM-Workloads auf einer einzigen Karte ist vGPU in den meisten Fällen wirtschaftlicher als der Kauf mehrerer physischer GPUs – vorausgesetzt, die Lizenzkosten werden gegen die eingesparte Hardware gegengerechnet und nicht isoliert betrachtet. Wer dagegen einen einzelnen, durchsatzkritischen Workload betreibt – etwa ein 70B-Modell mit hohem gleichzeitigem Anfragevolumen – fährt mit exklusivem Passthrough in der Regel besser, weil jeder Prozentpunkt Durchsatz dort unmittelbar in Nutzererfahrung übersetzt wird.

NVIDIA vGPU auf Proxmox VE: offizieller Support, Lizenzierung und Versionswahl

Lange war NVIDIA vGPU auf Proxmox VE eine von der Community getragene, aber nicht offiziell unterstützte Konfiguration. Das hat sich geändert: Seit NVIDIA vGPU Software 18 ist Proxmox VE offiziell von NVIDIA unterstützte Hypervisor-Plattform – bestätigt sowohl durch die entsprechende Proxmox-Pressemitteilung als auch durch NVIDIA selbst und im Proxmox-Wiki dokumentiert. Voraussetzung für den vollen Support-Umfang ist eine aktive vGPU-Entitlement-Lizenz sowie ein gültiges Proxmox-Abonnement (Basic, Standard oder Premium), sobald Sie Supportfälle über offizielle Kanäle einreichen möchten.

Beim Versionsstand ist Wachsamkeit gefragt: vGPU 18 ist seit März 2026 End of Life und sollte in keiner produktiven Neuinstallation mehr zum Einsatz kommen. Aktuell aktiv sind zwei Zweige:

• vGPU 20 – der Produktivbranch (Production Branch) mit Support bis März 2027. Empfehlenswert für Umgebungen, die von den jeweils neuesten Feature-Ergänzungen profitieren wollen und kürzere Update-Zyklen akzeptieren.
• vGPU 19 (LTS) – der Long-Term-Support-Zweig mit Support bis Juli 2028. Für produktive Umgebungen mit langen Wartungsfenstern und dem Wunsch nach möglichst seltenen Major-Upgrades ist dieser Zweig in der Praxis die robustere Wahl.

Ab der Ampere-Generation ist SR-IOV (Single Root I/O Virtualization) für vGPU zwingend erforderlich – ohne SR-IOV lässt sich eine Karte dieser oder neuerer Generationen nicht in mehrere Profile aufteilen. Proxmox liefert dafür die Pakete pve-nvidia-vgpu-helper und pve-nvidia-sriov mit aus, die die Einrichtung der virtuellen Funktionen und die Zuordnung zu den einzelnen VMs deutlich vereinfachen. Unterstützt werden ausschließlich NVIDIA-Datacenter- bzw. Pro-Karten – etwa die RTX A5000 oder die neuere RTX PRO 6000 Blackwell. Reine GeForce-Consumer-Karten bleiben von der offiziellen vGPU-Unterstützung ausdrücklich ausgenommen, auch wenn sich für Einzel-VM-Passthrough durchaus Community-Wege finden lassen.

Bei der Lizenzierung selbst lohnt der Blick auf das Nutzungsmodell, bevor die Kartenwahl feststeht: NVIDIA vGPU wird üblicherweise pro physischer GPU oder pro gleichzeitigem Nutzer lizenziert, nicht pro VM. Für LLM-Hosting mit wenigen, dauerhaft laufenden Diensten – wie im Praxisbeispiel weiter unten mit vier parallelen VMs auf einer Karte – ist die Lizenzierung pro GPU in aller Regel die günstigere und planbarere Variante, weil die Kosten unabhängig davon anfallen, wie viele Endnutzer die einzelnen Dienste tatsächlich gleichzeitig ansprechen.

Eine GPU auf mehrere LLM-VMs aufteilen: Praxisbeispiel und Sizing

Für das Sizing einer solchen Aufteilung gilt eine einfache, aber verlässliche Faustregel: Der VRAM-Bedarf pro Profil ergibt sich aus der quantisierten Modellgröße zuzüglich einer Reserve für den KV-Cache, die von der Größe des Context-Windows und der Zahl der erwarteten parallelen Anfragen abhängt. Ein 13B-Modell in INT4-Quantisierung belegt für die reinen Gewichte rund 7 bis 8 GB; für einen produktiven Betrieb mit mehreren gleichzeitigen Nutzern und einem Context-Window von 8.000 bis 16.000 Tokens sollte zusätzlich mit 4 bis 8 GB KV-Cache-Reserve kalkuliert werden – ein 24-GB-Profil bietet damit ausreichend Puffer, ohne Ressourcen zu verschwenden.

Der Trade-off ist dabei nicht verhandelbar: Je feiner eine Karte aufgeteilt wird, desto geringer fällt die Rechenleistung pro einzelner VM aus. Vier Profile bedeuten grob ein Viertel des Durchsatzes je Profil gegenüber der vollen Karte – wie im Balkendiagramm oben sichtbar, summiert sich der Gesamtdurchsatz aber nicht verlustfrei, sondern bewegt sich aggregiert bei rund 90 bis 95 % dessen, was Bare-Metal auf derselben Karte liefern würde. Für Anwendungsfälle mit moderatem Anfrageaufkommen pro Modell ist das ein sehr guter Kompromiss; für einen durchsatzkritischen Einzeldienst ist exklusives Passthrough weiterhin die bessere Wahl.

Troubleshooting: Häufige Fehler bei Passthrough und vGPU-Setup

In der Praxis wiederholen sich bei Passthrough- und vGPU-Projekten immer dieselben Fehlerbilder:

• IOMMU-Gruppe lässt sich nicht isolieren. Wenn die GPU hartnäckig mit anderen Geräten in derselben Gruppe verbleibt, gilt der ACS-Override-Patch als letzter Ausweg. Er zwingt den Kernel, Geräte künstlich in getrennte Gruppen aufzuteilen – das funktioniert technisch, hebelt aber einen Teil der eigentlichen Sicherheitsisolation der IOMMU aus und sollte nur nach sorgfältiger Abwägung und mit dokumentiertem Sicherheitsvorbehalt eingesetzt werden.
• Code-43-Fehler bei NVIDIA-Consumer-Karten in VMs. Siehe oben: Vendor-ID-Spoofing in der VM-Konfiguration ist der gängige Workaround, bei Datacenter-Karten meist gar nicht erst nötig.
• vGPU-Lizenzserver nicht erreichbar. Ohne funktionierende Verbindung zum Lizenzserver starten vGPU-Profile im Grace-Period-Modus oder verweigern nach Ablauf dieser Frist den Dienst. Netzwerksegmentierung und Firewall-Regeln für den Lizenzserver gehören daher früh in die Planung.
• VRAM-Fragmentierung bei mehreren gleichzeitig laufenden LLM-Instanzen. Wird ein Modell in einer VM neu geladen, während benachbarte Profile bereits aktiv sind, kann es zu spürbaren Ladeverzögerungen kommen – ein sauberer Neustart der betroffenen VM behebt das in der Regel zuverlässig.

Als erste Anlaufstelle für jede dieser Fehlerklassen hat sich in der Praxis derselbe Zweiklang bewährt: dmesg auf dem Proxmox-Host für alles rund um IOMMU-Bindung, VFIO-Modul-Load und PCI-Fehler, sowie journalctl -u pve-nvidia-sriov für alles, was die SR-IOV-Einrichtung und die vGPU-Profilzuweisung betrifft. Die meisten Probleme lassen sich mit diesen beiden Befehlen innerhalb weniger Minuten eingrenzen, bevor es überhaupt nötig wird, tiefer in Treiber-Logs einzusteigen.

Fazit: Welcher Weg passt zu welchem LLM-Hosting-Szenario

Die Entscheidung zwischen VFIO-Passthrough und NVIDIA vGPU ist keine Glaubensfrage, sondern eine Frage des Nutzungsmusters. Für einen einzelnen, durchsatzkritischen LLM-Workload liefert Passthrough mit 1 bis 3 % Overhead praktisch Bare-Metal-Performance, ohne Lizenzkosten und mit vergleichsweise geringem Konfigurationsaufwand, sobald IOMMU sauber eingerichtet ist. Für Multi-Tenant- oder Multi-Modell-Szenarien mit zwei bis vier parallelen LLM-Diensten auf einer Karte ist NVIDIA vGPU seit der offiziellen Proxmox-Unterstützung ab Software-Version 18 der wirtschaftlich und betrieblich sauberere Weg – mit der klaren Empfehlung, aktuell auf vGPU 20 oder für längere Wartungsfenster auf vGPU 19 LTS zu setzen, da vGPU 18 bereits ausgelaufen ist.

Beide Wege lassen sich im selben Proxmox-Cluster kombinieren: eine Karte exklusiv per Passthrough für den durchsatzkritischen Hauptdienst, eine zweite Karte per vGPU für mehrere kleinere Modelle und Testumgebungen. Welche Hardware-Sizing- und Lizenzentscheidung im Einzelfall wirtschaftlich sinnvoll ist, hängt stark vom Anfrageaufkommen, der Modellauswahl und den vorhandenen GPU-Generationen ab – hierzu beraten wir im Rahmen unserer On-Premise-KI-Projekte individuell.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primärquellen geprüft.

1. WZ-IT: GPU-Passthrough/vGPU Übersicht zu vGPU-18-Support und EOL-Daten für vGPU 18/19/20
2. Medium: vLLM-LXC auf Proxmox 9 Praxisbericht zu vLLM in einem LXC-Container mit NVIDIA-GPU-Passthrough
3. VMinstall: KI-Modelle auf Proxmox VE GPU-Passthrough-Setup für VM und LXC mit Ollama und vLLM
4. XDA: Proxmox GPU-Passthrough Vereinfachtes Passthrough-Setup via PECU-Tool inkl. IOMMU-Hinweis; hier als Erleichterung der Einrichtung eingeordnet, nicht als Performance-Beleg
5. Proxmox Wiki: NVIDIA vGPU on Proxmox VE Primärquelle für offiziellen vGPU-Support und SR-IOV-Voraussetzungen
6. Proxmox Pressemitteilung: offizieller NVIDIA-vGPU-Support Bestätigung, dass Proxmox VE seit vGPU Software 18 offiziell unterstützte Plattform ist

Häufig gestellte Fragen zu GPU-Passthrough und vGPU auf Proxmox

Wie groß ist der Performance-Verlust bei VFIO-GPU-Passthrough gegenüber Bare-Metal wirklich?

Aktuelle Benchmarks für CUDA-Workloads und LLM-Inferenz zeigen 0,4-3 % Overhead gegenüber Bare-Metal, bei reinen Inferenz-Lasten oft im unteren Bereich dieser Spanne. Für sustained-AI-Workloads ist ein Praxiswert von 1-3 % realistisch – Voraussetzung ist eine saubere IOMMU-Konfiguration ohne unnötige Interrupt-Remapping-Umwege.

Brauche ich für mehrere LLM-VMs zwingend NVIDIA vGPU-Lizenzen, oder reicht Passthrough?

Reines VFIO-Passthrough bindet eine GPU exklusiv an eine VM – für mehrere parallele LLM-VMs auf einer einzigen Karte braucht es entweder mehrere physische GPUs oder NVIDIA vGPU-Software mit SR-IOV (ab Ampere Pflicht) und einer gültigen Lizenz. Wer nur zeitversetzt zwischen VMs wechselt, kommt mit Passthrough und manuellem GPU-Rebind aus.

Seit wann unterstützt Proxmox VE NVIDIA vGPU offiziell, und welche vGPU-Version sollte ich einsetzen?

Seit NVIDIA vGPU Software 18 ist Proxmox VE offiziell unterstützte vGPU-Plattform. Da vGPU 18 bereits EOL ist (März 2026), sollten Neuinstallationen auf vGPU 20 (Produktivbranch, Support bis 03/2027) oder für längere Update-Zyklen auf vGPU 19 (LTS, Support bis 07/2028) setzen.

Was ist die häufigste Ursache, wenn GPU-Passthrough auf Proxmox nicht funktioniert?

In der Praxis liegt es meistens an fehlender oder falsch aktivierter IOMMU-Unterstützung: Intel VT-d bzw. AMD-Vi muss sowohl im BIOS/UEFI als auch über den Bootloader-Parameter (intel_iommu=on bzw. amd_iommu=on, dazu iommu=pt) aktiv sein. Zweithäufigste Ursache sind GPUs, die in derselben IOMMU-Gruppe wie andere Geräte hängen und sich nicht sauber isolieren lassen.