NVIDIA vGPU in OpenStack: Nova-mdev-Typen, Placement, GPU-Flavors, MIG und Passthrough

Wie Nova einer Instanz eine NVIDIA-vGPU gibt

OpenStack Nova bindet NVIDIA-vGPUs über seinen libvirt/KVM-Treiber an Instanzen an. Auf dem Compute-Host läuft NVIDIAs vGPU Manager, nova-compute meldet die freigegebenen vGPU-Typen als Inventar der Ressourcenklasse VGPU an den Placement-Dienst, und ein Flavor mit der Extra-Spec resources:VGPU=1 lässt den Scheduler einen Host mit freier vGPU wählen. Für die Karten, die wir liefern, unterstützt NVIDIAs Dokumentation zu vGPU 20 die RTX PRO 6000 Blackwell Server Edition, die RTX PRO 4500 Blackwell Server Edition, die L40S und die L4 auf Hosts mit Red Hat Enterprise Linux mit KVM und Ubuntu; die H200 NVL erreicht Instanzen als ganze Karte per PCI-Passthrough.

Novas eigener Leitfaden, gelesen am 25. Oktober 2026 in der aktuellen Fassung (Entwicklungsreihe nova 34.1, nach dem Release 2026.2 Hibiscus mit nova 34.0.0 vom 30. September 2026), hält fest, dass die Funktion nur vom libvirt/KVM-Treiber unterstützt wird und von der libvirt-Version, den physischen Geräten und dem vGPU-Treiber des Herstellers auf dem Host abhängt. Dieser Artikel geht diese drei Ebenen für eine Universität, ein Forschungszentrum oder eine Cloud der öffentlichen Hand durch, die GPU-Flavors anbieten will.

NVIDIA vGPU R595, Validated Platforms für Red Hat Enterprise Linux with KVM und Ubuntu, aktualisiert am 29. September 2026; OpenStack Nova „Attaching virtual GPU devices to guests“ und „Attaching physical PCI devices to guests“, zuletzt aktualisiert am 3. August 2026; alle gelesen am 25. Oktober 2026.

Die Sicht je Plattform für alle Hypervisoren steht in unserer Matrix NVIDIA vGPU: unterstützte Hypervisoren je GPU. Die Wahl des Host-Betriebssystems behandelt Linux für GPU-Server: Ubuntu, RHEL oder Rocky; diese Seite ist die Cloud-Ebene darüber.

Host-Unterstützung: RHEL, Ubuntu und Red Hat OpenStack Platform

NVIDIAs Seite zu R595 für Red Hat Enterprise Linux mit KVM nennt die Host-Releases 10.2, 10.1, 10.0, 9.8, 9.6, 9.4 und 8.10 (9.7 nur in den Releases 20.0 und 20.1) und schreibt, dass nicht gelistete Releases nicht unterstützt sind. Die Ubuntu-Seite nennt 26.04 LTS (seit 20.1), 24.04, 22.04 und 20.04 LTS. Red Hat OpenStack Platform steht auf NVIDIAs eigener Seite zu Linux mit KVM, wo NVIDIA festhält: „For NVIDIA vGPU software support, contact your Linux with KVM hypervisor vendor.“ Für eine Cloud auf Red-Hat-Basis läuft der Support für den vGPU-Stack also über Red Hat; auch NVIDIA AI Enterprise 8.2 verweist für Red Hat OpenStack Platform und Red Hat OpenStack Services on OpenShift auf die Dokumentation von Red Hat. Eine Cloud aus Upstream-OpenStack auf eigenen RHEL- oder Ubuntu-Hosts wird gegen die Listen der Host-Betriebssysteme geprüft. Das ist unsere Lesart der Listen: NVIDIA nennt Host-Betriebssysteme, nicht Upstream-OpenStack.

Die Firmware-Einstellungen sind die, die NVIDIAs vGPU-Benutzerhandbuch für jeden KVM-Host mit einer GPU ab Ampere nennt: VT-d oder IOMMU, SR-IOV und Alternative Routing ID Interpretation (ARI). Alle vier vGPU-Karten der Tabelle sind Ada oder Blackwell, alle drei Einstellungen gelten also. RTX PRO 6000 Server Edition und L40S werden im Display-off-Modus ausgeliefert, und NVIDIAs Seite zu RHEL KVM schreibt vor, solche GPUs für vGPU in diesem Modus zu betreiben.

Auf GPUs mit SR-IOV liegen vGPUs auf virtuellen Funktionen. Novas Leitfaden zeigt NVIDIAs Skript /usr/lib/nvidia/sriov-manage -e mit der PCI-Adresse der GPU, um sie anzulegen, und empfiehlt eine systemd-Unit, damit das bei jedem Start läuft, denn die Funktionen überstehen keinen Neustart.

nova-compute konfigurieren: mdev-Typen und Placement

Die verfügbaren vGPU-Typen erscheinen in sysfs; Novas Leitfaden listet sie aus dem Verzeichnis mdev_supported_types jeder GPU unter /sys/class/mdev_bus/, und jeder Typ hat einen Namen wie nvidia-35, der einem NVIDIA-Profil entspricht. In der nova.conf kommen die angebotenen Typen in den Abschnitt [devices], die Details je Typ in einen eigenen Abschnitt:

OpenStack Nova, „Attaching virtual GPU devices to guests“, zuletzt aktualisiert am 3. August 2026, gelesen am 25. Oktober 2026. mdev_class kam mit 24.0.0 (Xena); mehrere Typen je Host brauchen Ussuri oder neuer; max_instances ist für SR-IOV-GPUs ab 2024.1 Caracal Pflicht.

Drei Regeln aus Novas Leitfaden entscheiden, ob es funktioniert. Erstens kann Nova bei SR-IOV-GPUs ab Ampere nicht ermitteln, wie viele vGPUs ein Typ erlaubt („cannot determine how many vGPUs a type supports“); ab 2024.1 setzen Sie deshalb max_instances im Abschnitt jedes Typs auf die Zahl der vGPUs, die dieser Typ anlegen kann, wie sie NVIDIAs Profiltabellen angeben. Für die RTX PRO 6000 Server Edition stehen sie in unserem Leitfaden zu den vGPU-Profilen der RTX PRO 6000 Server Edition, für die 4500 in den vGPU-Profilen der RTX PRO 4500 Server Edition und für die L40S in den vGPU-Profilen der L40S. Zweitens darf eine PCI-Adresse nur unter einem Typ stehen, sonst startet nova-compute nicht. Drittens kann ein Typwechsel auf einem Host mit laufenden Instanzen NoValidHost-Fehler auslösen; der Leitfaden empfiehlt, neue Typen auf frischen Compute-Knoten einzuführen.

Jede physische GPU erscheint dann in Placement als untergeordneter Resource Provider des Compute-Knotens, was openstack resource provider list und dessen Unterbefehl inventory list zeigen. Bietet eine Cloud mehrere vGPU-Größen an, nennt der Leitfaden eigene Ressourcenklassen über mdev_class oder eigene Traits an den untergeordneten Providern, die ein Flavor als erforderlich markiert, dazu Host-Aggregate, die Flavors auf die richtigen Hosts lenken. Die freigegebenen Typen sind für API-Nutzer nicht sichtbar; welches Profil ein Projekt bekommt, steht also im Namen des Flavors.

Ubuntu Noble und RHEL 10: virtuelle Funktionen statt mdev

Neuere Hosts können einen anderen Weg nehmen. Novas Leitfaden warnt: Erscheinen nach der Installation des NVIDIA-Treibers keine mdev-Geräte, aber virtuelle Funktionen unter einem Pfad wie /sys/bus/pci/devices/0000:25:00.4/nvidia, dann ist der Kernel-Variant-Treiber aktiv („this indicates that the kernel variant driver is in use“); das kommt laut Leitfaden am ehesten unter Ubuntu Noble oder RHEL 10 vor („most likely occurs on Ubuntu Noble or RHEL 10“). Seit Release 31.0.0 (2025.1 Epoxy) verweist Nova solche Hosts auf seine Dokumentation zum PCI-Passthrough.

Diese Dokumentation bildet die vGPUs als virtuelle Funktionen in Placement ab. Ihr Beispiel für eine NVIDIA-Karte gibt jeder VF einen Eintrag device_spec mit der Hersteller-ID 10de, der PCI-Adresse der Funktion, einer eigenen Ressourcenklasse und "managed": "no", dazu einen Alias mit "device_type": "type-VF", der zur Ressourcenklasse passt. Der Leitfaden warnt, dass Nova bei managed gleich no davon ausgeht, dass der Betreiber die Geräte vorher gebunden hat, und dass ein falscher Wert den Compute-Knoten zum Absturz bringen kann. Für VFs mit unterschiedlichen vGPU-Größen braucht es getrennte Ressourcenklassen. Dieser Weg setzt PCI-Tracking in Placement voraus ([pci] report_in_placement, ab nova 26.0.0 Zed, auf einem Host nach dem Einschalten nicht mehr abschaltbar) und das Scheduling in Placement ([filter_scheduler] pci_in_placement, ab 27.0.0). Wie jede VF ihren vGPU-Typ bekommt, wird auf dem Host nach NVIDIAs Dokumentation für das jeweilige Host-Betriebssystem eingestellt; Novas Seiten beschreiben diesen Schritt nicht.

Prüfen Sie bei einer neuen Cloud auf RHEL 10 oder Ubuntu 24.04, welches der beiden Modelle der Host zeigt, bevor Sie die nova.conf schreiben. Welches gilt, folgt aus Host-Betriebssystem und Treiber, nicht aus einer Einstellung in OpenStack.

Wir liefern die RTX PRO 6000 und RTX PRO 4500 Server Edition, die L40S und die L4 als Karten oder in KI-Servern nach Maß; schicken Sie uns OpenStack-Release, Host-Betriebssystem und die geplanten Flavor-Größen, und unser Team antwortet mit einer Karten- und Lizenzkonfiguration je Compute-Knoten.

OpenStack-GPU-Flavors: eine vGPU, mehrere vGPUs und Größen

Der einfache Flavor ist eine Zeile aus Novas Leitfaden: openstack flavor set vgpu_1 mit --property "resources:VGPU=1". Eine damit erstellte Instanz landet auf einem Host mit freier vGPU, und der Befehl resource provider allocation show mit der UUID des Servers zeigt, wo.

Mehrere vGPUs je Instanz waren lange ausgeschlossen; Novas Leitfaden hält noch fest, dass Hypervisoren „as of the Queens release“ nur eine akzeptierten, und ein dort zitierter Bug-Bericht vermerkt, dass „the nvidia driver doesn’t support more than one vGPU per instance“ auf derselben GPU. Seit 33.0.0 zeigt der Leitfaden einen Flavor mit nummerierten Ressourcenanforderungen, resources1:VGPU=1 und resources2:VGPU=1, damit die vGPUs von getrennten physischen GPUs kommen; SR-IOV-GPUs brauchen dafür keine weiteren Eigenschaften. Ein typischer kleiner Katalog einer Forschungscloud hat einen Flavor je Profilgröße, jeweils an eine Ressourcenklasse oder einen Trait gebunden, und einen Passthrough-Flavor je Typ ganzer Karten.

MIG-basierte vGPU auf den RTX PRO Server Editions

MIG teilt die RTX PRO 6000 Server Edition in bis zu vier GPU-Instanzen mit 24 GB und die RTX PRO 4500 Server Edition in zwei mit 16 GB. NVIDIAs Seiten zu RHEL KVM und Ubuntu führen beide Karten für MIG-basierte vGPU 1:1, bei der eine vGPU eine Instanz füllt, und für MIG-basierte vGPU mit Time-Slicing, bei der sich mehrere vGPUs eine Instanz teilen, jeweils unter vWS, vPC und vApps. MIG bringt Isolation: Jede Instanz hat eigene Rechenleistung und Speicherbandbreite, wie unser Leitfaden zu MIG und vGPU: VMs je Karte erklärt, und NVIDIAs vPC-Sizing-Guide nennt bis zu 48 Büro-Desktops mit einem 2-GB-Profil je RTX PRO 6000 Server Edition mit MIG und Time-Slicing zusammen, gegenüber 32 mit reinem Time-Slicing.

Novas vGPU-Leitfaden erwähnt MIG nicht. NVIDIAs Benutzerhandbuch legt die Reihenfolge auf dem Host fest: Erst wird die GPU für MIG-basierte vGPUs konfiguriert, dann werden die virtuellen Funktionen vorbereitet, danach die vGPUs angelegt. Für einen Nova-Host heißt das, die MIG-Instanzen müssen bestehen, bevor nova-compute die Typen zählt, und sie müssen nach jedem Neustart neu angelegt werden, weil MIG-Modus und Instanzen nicht erhalten bleiben; unsere MIG-Anleitung Schritt für Schritt behandelt die Befehle und die Werkzeuge, die das Layout beim Start wiederherstellen. NVIDIAs nvidia-smi -q zeigt, ob eine Karte es anbietet: „MIG Time-Slicing“ steht auf „Supported“ und „MIG Time-Slicing Mode“ auf „Enabled“. Testen Sie ein MIG-Layout auf einem Compute-Knoten, bevor Sie Flavors darauf veröffentlichen.

Lizenzen und Compute-Profile im Gast

Der Gasttreiber jeder Instanz bezieht eine Lizenz aus NVIDIAs License System, über den Clouddienst oder eine Appliance des Delegated License Service im eigenen Netz, wie unser Artikel zum NVIDIA-vGPU-Lizenzserver erklärt. Die Lizenz folgt der Profilserie: Q-Serie braucht RTX vWS, B-Serie vPC oder vWS, A-Serie vApps, wie unser Leitfaden zur vGPU-Lizenzierung mit vWS, vPC und vApps ausführt. Das Gast-Image braucht einen Gasttreiber, der zum vGPU Manager des Hosts passt; NVIDIAs Einschränkungen für RHEL KVM nennen einen Treiber aus einem unpassenden Release als Ursache für eine fehlgeschlagene vGPU-Initialisierung (Code 43 in Windows-Gästen).

Compute-Profile sind eine eigene Frage. NVIDIAs Einschränkungen für RHEL KVM halten fest, dass „NVIDIA vGPU for Compute“ dort im vGPU-Produkt nicht verfügbar ist, und verweisen auf NVIDIA AI Enterprise, lizenziert je GPU. AI Enterprise 8.2 führt Red Hat Enterprise Linux mit KVM und Ubuntu mit dem Vermerk „single-node only“ und verweist OpenStack-Umgebungen an Red Hat; bei einer Compute-Cloud mit mehreren Knoten sollten Sie die Supportlage für AI Enterprise also mit Red Hat und NVIDIA klären, bevor Flavors der C-Serie live gehen. Die Alternative für Compute-Nutzer sind ganze Karten per Passthrough, siehe unten. Die Bedingungen je GPU stehen in unserem Leitfaden zur AI-Enterprise-Lizenzierung.

Live-Migration, Resize und weitere Vorgänge

Nova unterstützt die Live-Migration von Instanzen mit vGPU seit 2024.1 Caracal (29.0.0), wenn beide Compute-Dienste mindestens libvirt 8.6.0, QEMU 8.1.0 und Linux-Kernel 5.18.0 haben. Der Leitfaden nennt vier weitere Bedingungen: ein gemeinsamer vGPU-Typ auf Quelle und Ziel oder eigene Traits oder Ressourcenklassen, damit Placement einen passenden Host wählt; live_migration_permit_post_copy auf False auf vGPU-Knoten, weil VFIO-Migration nicht mit Post-Copy funktioniert; höhere Downtime-Werte für NVIDIA-Geräte (im Beispiel 500000, 3 und 3 für die drei Downtime-Optionen); und Host-Aggregate, die vGPU-Hosts von Hosts mit Post-Copy trennen. NVIDIAs eigene Bedingungen kommen dazu: dasselbe GPU-Modell am Ziel und ein vGPU Manager aus demselben Zweig in gleicher oder neuerer Version, nie älter, wie unser Leitfaden zu MIG und vGPU zusammenfasst. In NVIDIAs Liste bekannter Probleme zu vGPU 20 steht außerdem ein Eintrag „Linux VM hangs after vGPU migration to a host running a newer vGPU manager version“; lesen Sie ihn vor einem rollierenden Host-Upgrade.

Die älteren Lücken sind in aktuellen Releases geschlossen. Suspend von vGPU-Instanzen funktioniert seit Yoga (25.0.0); Resize und Cold Migration vergeben die vGPUs des neuen Flavors seit Ussuri (21.0.0); Rescue behält die vGPUs seit Rocky (18.0.0). NVIDIAs Einschränkungen für RHEL KVM ergänzen, dass vGPU-Hotplug nicht unterstützt ist: Alle vGPUs müssen vor dem Start der VM angehängt sein, was zur Zuweisung beim Booten durch Nova passt.

OpenStack GPU-Passthrough: H200 NVL und andere ganze Karten

Die H200 NVL steht auf keiner der Seiten zu validierten vGPU-Plattformen und auf der GPU-Liste von NVIDIA AI Enterprise 8.2, das in VMs entweder im vGPU-Modus oder im Passthrough-Modus mit dem Rechenzentrumstreiber im Gast läuft. In OpenStack ist der Passthrough-Weg Novas PCI-Passthrough. Ein [pci] device_spec mit Hersteller-ID (10de) und Produkt-ID der Karte markiert die Geräte auf dem Compute-Knoten, ein [pci] alias benennt sie, und ein Flavor fordert sie mit pci_passthrough:alias an, gesetzt auf den Alias und eine Anzahl, etwa zwei Karten. Der Alias „must also be configured on controller nodes“, und numa_policy im Alias steuert, ob die Karte am NUMA-Knoten der Instanz sitzen muss.

Zwei Regeln zählen bei H200-NVL-Servern mit NVLink-Brücken. NVIDIAs Einschränkungen für RHEL KVM schreiben vor, alle über NVLink verbundenen GPUs an dieselbe VM durchzureichen, sonst ist der NVLink-Zustand beschädigt (XID 74), bis die GPUs zurückgesetzt werden; der Passthrough-Flavor für ein verbundenes Paar oder Quartett fordert also den ganzen Satz an. Und Post-Copy-Live-Migration bleibt auch auf diesen Hosts aus, weil QEMU laut Novas PCI-Leitfaden Migrationen ablehnt, die VFIO-Geräte mit Post-Copy verbinden. Derselbe Flavor-Typ passt für die Workstation- und Max-Q-Edition der RTX PRO 6000, die auf keiner vGPU-Liste stehen; ihre Reset-Probleme auf Hosts mit mehreren GPUs behandelt unser Artikel zur RTX PRO 6000 Max-Q in virtuellen Maschinen. Wenn Sie solche Flavors planen, beschreiben Sie uns die Instanztypen und wie viele Sie je Typ brauchen, und wir schlagen Karten und Knoten je Typ vor.

Was wir liefern

Wir liefern die RTX PRO 6000 Server Edition, die RTX PRO 4500 Server Edition, die L40S, die L4 und die H200 NVL als Karten mit Herstellergarantie und bauen sie in KI-Server nach Maß ein, vor der Lieferung montiert und getestet, auf Wunsch mit Betriebssystem, Treibern und CUDA. vGPU- und NVIDIA-AI-Enterprise-Lizenzen kommen auf dasselbe Angebot wie die Hardware, wie unsere Lizenzseite beschreibt; Mengen und Lieferzeit werden mit dem Angebot schriftlich bestätigt, mit einem EU-Vertrag und einer Rechnung.

FAQ