GPUs in VMware vSphere: Passthrough per DirectPath I/O oder NVIDIA vGPU, was jeder Modus braucht und was er erlaubt

Drei Wege, eine GPU in eine VM zu bringen

DirectPath I/O reicht eine ganze physische GPU an eine einzige VM durch. Dynamic DirectPath I/O, das es ab ESXi 7.0 gibt, ist dasselbe Passthrough mit einer lockereren Bindung: Die VM gibt zulässige Kombinationen aus Hersteller und Gerät oder ein Hardware-Label an, und ESXi wählt ein Gerät „auf Grundlage dessen, was zum Zeitpunkt des Einschaltens der VM verfügbar ist“. Bei NVIDIA vGPU weist der vGPU Manager im Hypervisor jeder VM ein Profil mit einer festen Menge GPU-Speicher zu, per Time-Slicing auf den Engines der Karte oder gestützt auf eine MIG-Instanz. Eine Karte macht entweder das eine oder das andere: Sie kann vGPUs hosten oder durchgereicht werden, „kann aber nicht beides gleichzeitig“, und auf ESXi braucht der Wechsel von Passthrough zu vGPU einen Neustart des Hosts.

Broadcom KB 312208; NVIDIAs Benutzerhandbuch zu vGPU 20 und Release Notes für vSphere; Support-Matrix von NVIDIA AI Enterprise 8.2 (Treiber für Passthrough: vGPU-Gasttreiber oder Rechenzentrumstreiber), September 2026.

Was jeder Modus erlaubt

Passthrough gibt dem Gast die volle Karte und kostet die VM ihre Mobilität. Broadcom listet Suspend und Resume, Fault Tolerance, Hochverfügbarkeit, Snapshots und Hot-Add virtueller Geräte für VMs mit DirectPath I/O als nicht verfügbar und DRS nur in eingeschränkter Form: Die VM kann Mitglied eines Clusters sein, aber nicht migrieren. Snapshots gelingen, sobald die VM ausgeschaltet ist, was für Backup-Produkte wichtig ist, die über Snapshots arbeiten, und die VM braucht eine Speicherreservierung für ihren gesamten konfigurierten Arbeitsspeicher. Dynamic DirectPath I/O ändert die Platzierung, nicht die Mobilität: DRS in vSphere 7 kann Assignable Hardware nutzen, „um Ihre VM auf einem geeigneten Host-Server zu platzieren“, schrieb VMware 2020.

Broadcoms Seite zu DirectPath I/O in vSphere 9.0, KB 312208, KB 428701, Grafikdokumentation zu vSphere 8.0; VMware-Blog, April 2020; Release Notes und bekannte Probleme von NVIDIA vGPU 20 für vSphere.

Auch das Monitoring unterscheidet sich: NVIDIA stellt fest, dass DCGM „in vGPU-Umgebungen nicht unterstützt wird“.

Unterstützte Karten und Versionen, Stand September 2026

NVIDIAs aktuelles vGPU-Release, 20.2 vom August 2026, basiert auf dem Production Branch R595, der bis März 2027 unterstützt wird. Der Long-Term-Zweig vGPU 19 auf R580 wird laut NVIDIAs Release-Tabelle für vGPU bis Juli 2028 unterstützt, während NVIDIAs Tabelle der Rechenzentrumstreiber Juni 2028 als End of Life des Treiberzweigs R580 nennt. Release 20.2 kombiniert den vGPU Manager 595.91.04 mit den Gasttreibern in Version 595.91.07 (Linux) und Version 596.86 (Windows) und unterstützt VCF 9.1, VCF 9.0 mit seinen Maintenance-Releases sowie ESXi 8.0 Update 3 P06 (veröffentlicht als 8.0 Update 3g, Build 24859861) oder ein späteres Update von 8.0. NVIDIA AI Enterprise 8.2 nutzt dieselben Treiber, führt ESXi 8.0 sowie 9.0 und neuer und unterstützt seine GPUs „mit Servern, die in den NVIDIA-Certified Systems gelistet sind“.

NVIDIAs Support-Matrix zu vGPU 20 für vSphere (22. September 2026) und Liste der unterstützten GPUs; Release Notes zu vGPU 19 für vSphere; Support-Matrix von NVIDIA AI Enterprise 8.2 und vGPU-Typen der H200; Product Brief der H200 NVL.

Die H200 NVL ist nicht Teil von NVIDIAs vGPU-Produkt: Seit Release 16.0 überlässt dieses Produkt GPUs, die nur Profile der C-Serie haben, NVIDIA AI Enterprise. Unter den Karten der RTX PRO Blackwell haben wir in der GPU-Liste von NVIDIA AI Enterprise 8.2 nur die Server Editions gefunden.

Hosts und VMs vorbereiten

NVIDIAs vGPU-Leitfaden verlangt für GPUs ab der Ampere-Generation VT-d oder IOMMU, SR-IOV und Alternative Routing ID Interpretation (ARI) im BIOS; NVIDIA AI Enterprise empfiehlt Memory-Mapped I/O oberhalb von 4 GB, sofern das BIOS die Option anbietet. Passthrough braucht die IOMMU und laut Broadcoms KB 312208 ACS in den PCIe-Root-Ports und in den Downstream-Ports der Switches oberhalb des Geräts.

Der vGPU Manager ist ein ESXi-Treiber, den Broadcoms validiertes Design für private KI in das Cluster-Image von vSphere Lifecycle Manager aufnimmt; nvidia-smi auf dem Host zeigt danach die GPUs an. Unter Configure, Hardware, Graphics muss der Gerätetyp jeder GPU dann auf Shared Direct stehen, gefolgt von einem Neustart des Hosts. Bleibt er auf Shared (VMwares vSGA), starten vGPU-VMs nicht und melden einen Fehler wegen unzureichender Grafikressourcen: „Die Software NVIDIA vGPU unterstützt VMware vSGA nicht“. Die L40S und die RTX PRO 6000 Server Edition müssen vGPU im Display-off-Modus betreiben, ihrer Werkseinstellung, sofern diese nicht geändert wurde.

Für Passthrough wählen Sie unter Configure, Hardware, PCI Devices die physische GPU aus, nicht ihre virtuellen Funktionen, aktivieren Passthrough, starten neu und fügen die GPU der VM als PCI-Gerät hinzu, mit vollständig reserviertem Arbeitsspeicher. Broadcoms Verfahren für den Wechsel von vGPU-Hosts zu Passthrough schaltet MIG ab (nvidia-smi -i 0 -mig 0 für GPU 0), entfernt den vGPU-Hosttreiber mit esxcli software vib remove -n und dem Namen des Treibers und startet neu.

Für das Passthrough von „GPUs mit großen BAR-Speichereinstellungen“ verlangt NVIDIA ein 64-Bit-Gastsystem und 64-Bit-MMIO für die VM, dazu EFI-Boot, sobald der gesamte BAR1-Speicher 256 MB übersteigt; Broadcoms Parameter sind pciPassthru.use64bitMMIO, auf TRUE gesetzt, und pciPassthru.64bitMMIOSizeGB, „eine Zweierpotenz in GB“, dessen Wert NVIDIA als BAR1-Gesamtwert jeder GPU laut nvidia-smi -q mal der Zahl der GPUs in der VM ansetzt (4 × 128 GiB ergeben 512). Eine vGPU-VM mit 32 GB Arbeitsspeicher oder mehr braucht dieselben Einstellungen, wenn ihre GPU 64 GB MMIO oder mehr benötigt, wobei das Fenster auf den Wert der GPU angehoben wird: 512 GB für H200-Karten und 64 GB für die L4 in der Tabelle von NVIDIA AI Enterprise, die für die L40S oder die RTX PRO 6000 Server Edition keinen Wert angibt. Und per Brücke verbundene H200-NVL-Karten gehören gemeinsam in eine VM: Beim Passthrough „müssen alle über NVLink miteinander verbundenen GPUs derselben VM zugewiesen werden“, sonst tritt beim Booten der VM XID 74 auf.

MIG-gestützte vGPU auf ESXi

MIG wird je GPU auf dem Host aktiviert, bei installiertem vGPU Manager und ohne dass etwas anderes die GPU nutzt: nvidia-smi -i 0 -mig 1 für GPU 0. ESXi braucht dafür nur bei Ampere-GPUs einen Neustart des Hosts, und vSphere „legt die GPU-Instanzen automatisch an“; vom Standard abweichende Compute-Instanzen innerhalb einer MIG-gestützten vGPU werden auf vSphere nicht unterstützt. Auf vSphere werden MIG-gestützte Grafik-vGPUs, die jeweils eine GPU-Instanz ausfüllen, seit vGPU 19.0 unterstützt. Time-sliced vGPUs innerhalb einer GPU-Instanz brauchen dagegen VCF 9.1 (nicht VCF 9.0 oder ESXi 8) mit vGPU 20.0 oder vGPU 19.4 und neuer, und mehrere MIG-gestützte vGPUs je VM brauchen VCF 9.1 mit vGPU 20.2 oder vGPU 19.6 und neuer, auch in NVIDIA AI Enterprise. Auf der RTX PRO 6000 Server Edition ergibt Time-Slicing innerhalb von MIG bis zu vier MIG-Scheiben mit jeweils einer bis drei Compute-vGPUs zu 8 GB. MIG-gestützte vGPUs lassen sich nicht live zwischen unterschiedlichen MIG-Profilen migrieren, und auf H200-Karten sind Windows-Gäste auf Time-sliced vGPUs beschränkt. Die Profilzahlen je Karte stehen in unserem Leitfaden zu MIG und vGPU.

vMotion und DRS mit vGPU

vMotion für vGPU-VMs wird in vCenter unter Configure, Settings, Advanced Settings aktiviert: vgpu.hotmigrate.enabled auf true gesetzt und, falls nicht vorhanden, hinzugefügt. Das Ziel braucht laut NVIDIA eine GPU desselben Typs, dieselbe ECC-Einstellung und dieselbe GPU-Topologie, einschließlich der NVLink-Breiten; Unified Memory, CUDA-Debugger und Profiler deaktivieren die Migration, und zwischen Boards der H200, H800 und H100 ist keine Migration möglich. Die Richtung zählt: Das Fortsetzen auf einem Host mit einem älteren vGPU-Hauptzweig schlägt fehl, und eine VM unter vGPU 20.1, die auf einen Host mit 20.0 verschoben wird, schaltet sich ab; aktualisieren Sie also zuerst die Hosts und verschieben Sie VMs nur auf dasselbe oder ein neueres Release.

Während eines Teils der Migration ist die VM nicht erreichbar, und Broadcom merkt an, dass diese Stun-Zeit „je nach Menge des GPU-Speichers, den die VM gerade belegt, variieren kann“. Ab vSphere 8.0 Update 2 lässt sich je VM ein Limit für die Stun-Zeit setzen, vCenter schätzt die Stun-Zeit (in 8.0 Update 2 für Profile der C-Serie und der Q-Serie, mit einem vMotion-Netzwerk auf jedem Host), und DRS migriert eine vGPU-VM automatisch, wenn ihre geschätzte Stun-Zeit unter ihrem eigenen Limit liegt, die Cluster-Optionen PassthroughDrsAutomation und LBMaxVmotionPerHost auf 1 gesetzt sind und VmDevicesStunTimeTolerated, standardmäßig 100 Sekunden, die größte geschätzte Stun-Zeit im Cluster übersteigt.

Lizenzen

NVIDIAs vGPU-Produkt für vSphere hat keine Compute-Profile: „vGPU-Typen der C-Serie sind nicht verfügbar. Stattdessen wird NVIDIA vGPU for Compute mit NVIDIA AI Enterprise unterstützt.“ Diese Lizenz gilt je GPU und deckt bis zu 16 vGPUs auf dieser GPU ab oder eine vGPU, die die ganze Karte nutzt. Jede VM bezieht beim Booten eine Lizenz vom NVIDIA License System, in NVIDIAs Cloud oder im eigenen Netz; ohne Lizenz läuft sie 20 Minuten mit voller Leistungsfähigkeit, dann fällt ihre Rechenleistung auf Leerlaufniveau. Grafikprofile brauchen RTX vWS (Q-Serie), vPC (B-Serie) oder vApps (A-Serie), gezählt pro gleichzeitigem Nutzer; RTX vWS und vApps decken auch GPU-Passthrough ab. Eine Compute-VM im Passthrough mit dem Rechenzentrumstreiber braucht keinen Lizenzserver, denn das License System „ist nur erforderlich“, wenn Treiber von vGPU for Compute laufen, doch die Software von NVIDIA AI Enterprise in ihr braucht weiterhin ihre Lizenz je GPU. Zählregeln und enthaltene Abonnements, etwa die fünf Jahre der H200 NVL, stehen in unserem Leitfaden zur Lizenzierung; welche vSphere-Edition vGPU enthält, behandelt unser Leitfaden zur VMware-Verlängerung.

Den GPU-Cluster planen

Passthrough eignet sich für VMs, die ganze Karten brauchen: ein Modell, das über mehrere GPUs verteilt ist, per Brücke verbundene H200-NVL-Karten, lange Fine-Tuning-Läufe. vGPU eignet sich für viele kleinere VMs, die sich Karten teilen und verschiebbar bleiben sollen: virtuelle Workstations, Entwicklungsmaschinen, kleine Inferenzdienste.

Die Regeln oben sprechen für einen eigenen Cluster für GPU-Hosts. Eine vGPU-VM wechselt nur auf einen Host mit demselben GPU-Typ; die DRS-Einstellungen für vGPU sind Cluster-Optionen, LBMaxVmotionPerHost auf 1 gilt also für jede VM im Cluster; und bei imagebasiertem Lifecycle-Management ist der vGPU Manager Teil des Cluster-Images. Broadcoms HA Admission Control wird anhand von CPU und Arbeitsspeicher berechnet, und wir haben darin nichts zu GPUs gefunden; halten Sie also genug freie GPUs jedes Typs vor, um einen Host in Wartung oder einen ausgefallenen Host aufzufangen. Passthrough-VMs, die weder vMotion noch Suspend beherrschen, müssen heruntergefahren werden, bevor ihr Host in den Wartungsmodus geht. Wie viele Karten ein Host aufnimmt, hängt von Lanes, Strom und Luftstrom ab, wie unser Leitfaden zur Serverdimensionierung darlegt.

Bei GPU-Hosts geht es um Editionen, Versionen und Wartungsfenster zugleich, also um das Feld, das unser Engineering-Partner Vixen.UNO mit der VMware-Optimierung abdeckt: ein Audit der Umgebung und ihrer Lizenzen, Editionen passend zu den realen Workloads innerhalb der Lizenzlogik von Broadcom sowie Updates von vSphere und VCF in vereinbarten Wartungsfenstern mit Rollback-Plan.

Was wir liefern

Von den Karten, die NVIDIA auf vSphere unterstützt, liefert Eurokommerz die RTX PRO 6000 Server Edition, die L40S, die L4 und die H200 NVL mit Herstellergarantie, EU-Vertrag und EU-Rechnung, als Karten oder in KI-Servern, die auf Bestellung gebaut werden. Lizenzen für NVIDIA AI Enterprise und vGPU kommen auf dasselbe Angebot und dieselbe Rechnung wie die Hardware, wie unsere Lizenzseite erklärt. Unter demselben Vertrag erbringt unser Engineering-Partner Vixen.UNO die VMware-Optimierung: das Umgebungs- und Lizenz-Audit, Editionen passend zu den realen Workloads, die Modernisierung von vSphere und VCF in vereinbarten Wartungsfenstern mit Rollback-Plan und Support unter einem vereinbarten SLA.

FAQ