NVIDIA vGPU in OpenStack: Nova mdev types, Placement, GPU flavors, MIG and passthrough

How Nova gives an instance an NVIDIA vGPU

OpenStack Nova attaches NVIDIA vGPUs to instances through its libvirt/KVM driver. The compute host runs NVIDIA's vGPU Manager, nova-compute reports the vGPU types you enable as inventory of the resource class VGPU in the Placement service, and a flavor with the extra spec resources:VGPU=1 makes the scheduler pick a host with a free vGPU. For the cards we supply, NVIDIA's vGPU 20 documentation supports the RTX PRO 6000 Blackwell Server Edition, the RTX PRO 4500 Blackwell Server Edition, the L40S and the L4 on Red Hat Enterprise Linux with KVM and Ubuntu hosts; the H200 NVL reaches instances as a whole card by PCI passthrough.

Nova's own guide, read on 25 October 2026 in its current version (nova 34.1 development series, after the 2026.2 Hibiscus release with nova 34.0.0 of 30 September 2026), states that the feature is supported only by the libvirt/KVM driver and depends on the libvirt version, the physical devices and the vendor's vGPU driver on the host. This article walks through those three layers for a university, research centre or public-sector cloud that wants to offer GPU flavors.

NVIDIA vGPU R595 validated platforms for Red Hat Enterprise Linux with KVM and Ubuntu, updated 29 September 2026; OpenStack Nova "Attaching virtual GPU devices to guests" and "Attaching physical PCI devices to guests", last updated 3 August 2026; all read 25 October 2026.

The platform-by-platform view for all hypervisors is in our NVIDIA vGPU hypervisor support by GPU matrix. The host operating system choice is covered in Linux for GPU servers: Ubuntu, RHEL or Rocky; this page is the cloud layer on top.

Host support: RHEL, Ubuntu and Red Hat OpenStack Platform

NVIDIA's R595 page for Red Hat Enterprise Linux with KVM lists the host releases 10.2, 10.1, 10.0, 9.8, 9.6, 9.4 and 8.10 (9.7 only in releases 20.0 and 20.1) and says that releases not listed are not supported. The Ubuntu page lists 26.04 LTS (since 20.1), 24.04, 22.04 and 20.04 LTS. Red Hat OpenStack Platform appears on NVIDIA's separate Linux with KVM page, where NVIDIA states: "For NVIDIA vGPU software support, contact your Linux with KVM hypervisor vendor." For a Red Hat-based cloud, support for the vGPU stack therefore runs through Red Hat; NVIDIA AI Enterprise 8.2 likewise refers Red Hat OpenStack Platform and Red Hat OpenStack Services on OpenShift to Red Hat's documentation. A cloud built from upstream OpenStack on its own RHEL or Ubuntu hosts is checked against the host OS lists. That last point is our reading of the lists: NVIDIA names host operating systems, not upstream OpenStack.

The firmware settings are those NVIDIA's vGPU user guide gives for any KVM host with an Ampere or later GPU: VT-d or IOMMU, SR-IOV and Alternative Routing ID Interpretation (ARI). All four vGPU cards in the table are Ada or Blackwell, so all three settings apply. The RTX PRO 6000 Server Edition and the L40S ship in display-off mode, and NVIDIA's RHEL KVM page says such GPUs must be used in that mode for vGPU.

On SR-IOV GPUs, vGPUs live on virtual functions. Nova's guide shows NVIDIA's script /usr/lib/nvidia/sriov-manage -e with the PCI address of the GPU to create them and suggests a systemd unit so that this runs at every boot, because the functions do not survive a restart.

Configuring nova-compute: mdev types and Placement

The available vGPU types appear in sysfs, and Nova's guide lists them from the mdev_supported_types directory of each GPU under /sys/class/mdev_bus/; each type has a name such as nvidia-35 that maps to one NVIDIA profile. In nova.conf the types to offer go into the [devices] section, with one section per type for its details:

OpenStack Nova, "Attaching virtual GPU devices to guests", last updated 3 August 2026, read 25 October 2026. mdev_class was added in 24.0.0 (Xena); several types per host need Ussuri or later; max_instances is required for SR-IOV GPUs from 2024.1 Caracal.

Three rules from Nova's guide decide whether this works. First, Nova "cannot determine how many vGPUs a type supports" on Ampere and newer SR-IOV GPUs, so from 2024.1 you set max_instances in each type's section to the number of vGPUs that type can create, which NVIDIA's profile tables give; for the RTX PRO 6000 Server Edition they are in our RTX PRO 6000 Server Edition vGPU profiles guide, for the 4500 in RTX PRO 4500 Server Edition vGPU profiles and for the L40S in L40S vGPU profiles. Second, a PCI address may appear under only one type, or nova-compute refuses to start. Third, changing a type on a host that already runs instances can produce NoValidHost errors, and the guide recommends rolling out new types on fresh compute nodes.

Each physical GPU then appears in Placement as a child resource provider under the compute node, which openstack resource provider list and its inventory list subcommand show. When a cloud offers more than one vGPU size, the guide's tools are custom resource classes through mdev_class, or custom traits on the child providers that a flavor marks as required, plus host aggregates to steer flavors to the right hosts. Enabled types are not visible to API users, so the flavor name is what tells a project which profile it gets.

Ubuntu Noble and RHEL 10: virtual functions instead of mdev

Newer hosts can take a different path. Nova's guide warns that if no mdev devices appear after installing the NVIDIA driver but virtual functions exist under a path like /sys/bus/pci/devices/0000:25:00.4/nvidia, "this indicates that the kernel variant driver is in use", which "most likely occurs on Ubuntu Noble or RHEL 10". Since release 31.0.0 (2025.1 Epoxy), Nova points such hosts to its PCI passthrough documentation.

That documentation models the vGPUs as virtual functions in Placement. Its example for an NVIDIA card gives each VF a device_spec entry with vendor ID 10de, the PCI address of the function, a custom resource class and "managed": "no", and an alias with "device_type": "type-VF" that matches the resource class. The guide warns that with managed set to no, Nova assumes the operator has bound the devices beforehand, and that a wrong value can crash the compute node. Separate resource classes are needed for VFs configured with different vGPU sizes. This route needs PCI tracking in Placement ([pci] report_in_placement, from nova 26.0.0 Zed, which cannot be switched off again on a host once enabled) and scheduling in Placement ([filter_scheduler] pci_in_placement, from 27.0.0). How each VF receives its vGPU type is set on the host per NVIDIA's documentation for that host OS; Nova's pages do not describe that step.

For a new cloud on RHEL 10 or Ubuntu 24.04, check which of the two models the host shows before you write nova.conf. Which one applies follows from the host OS and driver, not from a choice in OpenStack.

We supply the RTX PRO 6000 and 4500 Server Editions, the L40S and the L4 as cards or built into servers; send us your OpenStack release, host OS and planned flavor sizes, and we reply with a card and licence configuration per compute node.

OpenStack GPU flavors: one vGPU, several vGPUs and sizes

The basic flavor is one line from Nova's guide: openstack flavor set vgpu_1 with --property "resources:VGPU=1". An instance created with it lands on a host with a free vGPU, and the resource provider allocation show command with the server UUID shows where it went.

Several vGPUs per instance were long excluded; Nova's guide still records that "as of the Queens release" hypervisors accepted only one, and a bug report it cites notes that "the nvidia driver doesn't support more than one vGPU per instance" on the same GPU. Since 33.0.0 the guide shows a flavor with numbered resource requests, resources1:VGPU=1 and resources2:VGPU=1, so that the vGPUs come from separate physical GPUs; SR-IOV GPUs need no further properties for this. A typical small catalogue for a research cloud has one flavor per profile size, each tied to a resource class or trait, and one passthrough flavor per whole-card type.

MIG-backed vGPU on the RTX PRO Server Editions

MIG splits the RTX PRO 6000 Server Edition into up to four GPU instances of 24 GB and the RTX PRO 4500 Server Edition into two of 16 GB. NVIDIA's RHEL KVM and Ubuntu pages list both cards for 1:1 MIG-backed vGPU, where one vGPU fills an instance, and for time-sliced MIG-backed vGPU, where several vGPUs share an instance, under vWS, vPC and vApps. MIG adds isolation: each instance has its own compute and memory bandwidth, as our guide to MIG and vGPU VMs per card explains, and NVIDIA's vPC sizing guide gives up to 48 office desktops with a 2 GB profile per RTX PRO 6000 Server Edition with MIG and time-slicing combined, against 32 with time-sliced profiles alone.

Nova's vGPU guide does not mention MIG. What NVIDIA's user guide fixes is the order on the host: configuring the GPU for MIG-backed vGPUs comes before preparing the virtual functions, and both before creating vGPUs. For a Nova host this means the MIG instances must exist before nova-compute counts the types, and they must be recreated after every reboot, because MIG mode and instances do not persist; our MIG step-by-step guide covers the commands and the tools that recreate the layout at start-up. NVIDIA's nvidia-smi -q shows whether a card offers it: "MIG Time-Slicing" set to "Supported" and "MIG Time-Slicing Mode" set to "Enabled". Test a MIG layout on one compute node before you publish flavors on it.

Licences and compute profiles in the guest

The guest driver in each instance takes a licence from NVIDIA's License System, through the cloud service or a Delegated License Service appliance on your own network, as our article on the NVIDIA vGPU licence server explains. The licence follows the profile series: Q-series profiles need RTX vWS, B-series vPC or vWS, A-series vApps, set out in our guide to vGPU licensing with vWS, vPC and vApps. The guest image needs a guest driver compatible with the host's vGPU Manager; NVIDIA's RHEL KVM limitations name a driver from a mismatched release as a cause of failed vGPU initialisation (Code 43 in Windows guests).

Compute profiles are a separate question. NVIDIA's RHEL KVM limitations state that "NVIDIA vGPU for Compute" is not available in its vGPU product there and point to NVIDIA AI Enterprise, licensed per GPU. AI Enterprise 8.2 lists Red Hat Enterprise Linux with KVM and Ubuntu as single-node only and refers OpenStack deployments to Red Hat, so a multi-node compute cloud should have its AI Enterprise support position confirmed with Red Hat and NVIDIA before C-series flavors go live. The alternative for compute users is whole cards by passthrough, below. Our AI Enterprise licensing guide has the per-GPU terms.

Live migration, resize and other operations

Nova supports live migration of instances with vGPUs since 2024.1 Caracal (29.0.0), if both compute services run at least libvirt 8.6.0, QEMU 8.1.0 and Linux kernel 5.18.0. Its guide adds four conditions: one common vGPU type on source and target, or custom traits or resource classes so that Placement picks a matching host; live_migration_permit_post_copy set to False on vGPU compute nodes, because VFIO migration does not work with post-copy; higher downtime settings for NVIDIA devices (its example: 500000, 3 and 3 for the three downtime options); and host aggregates to separate vGPU hosts from those that use post-copy. NVIDIA's own conditions come on top: the same GPU model on the target and a vGPU Manager from the same branch that is the same or newer, never older, as our MIG and vGPU guide summarises. NVIDIA's known-issues list for vGPU 20 also carries an entry titled "Linux VM hangs after vGPU migration to a host running a newer vGPU manager version", so read it before a rolling host upgrade.

The older gaps are closed in current releases. Suspend of vGPU instances works since Yoga (25.0.0); resize and cold migration allocate the new flavor's vGPUs since Ussuri (21.0.0); rescue keeps the vGPUs since Rocky (18.0.0). NVIDIA's RHEL KVM limitations add that vGPU hot plugging is not supported: all vGPUs must be attached before the VM starts, which matches how Nova assigns them at boot.

OpenStack GPU passthrough: H200 NVL and other whole cards

The H200 NVL is on none of NVIDIA's vGPU validated-platform pages and is on the GPU list of NVIDIA AI Enterprise 8.2, which runs in VMs either in vGPU mode or in passthrough mode with the data-centre driver in the guest. In OpenStack the passthrough route is Nova's PCI passthrough. A [pci] device_spec with the card's vendor ID (10de) and product ID marks the devices on the compute node, a [pci] alias names them, and a flavor requests them with pci_passthrough:alias set to the alias and a count, such as two cards. The alias "must also be configured on controller nodes", and numa_policy in the alias controls whether the card must sit on the instance's NUMA node.

Two rules matter for H200 NVL servers with NVLink bridges. NVIDIA's RHEL KVM limitations state that all GPUs joined by NVLink must be passed to the same VM, or the NVLink state is corrupted (XID 74) until the GPUs are reset, so the passthrough flavor for a bridged pair or quad requests the whole set. And post-copy live migration stays off on these hosts too, because Nova's PCI guide notes that QEMU rejects migrations that combine VFIO devices with post-copy. The same flavor type fits the RTX PRO 6000 Workstation and Max-Q editions, which are not on any vGPU list; their reset problems on multi-GPU hosts are covered in our article on the RTX PRO 6000 Max-Q in virtual machines. If you are planning such flavors, describe the instance types and how many of each, and we propose cards and nodes per type.

What we supply

We supply the RTX PRO 6000 Server Edition, the RTX PRO 4500 Server Edition, the L40S, the L4 and the H200 NVL as cards with manufacturer warranty, and build them into AI servers to order, assembled and tested before delivery, with the operating system, drivers and CUDA installed on request. vGPU and NVIDIA AI Enterprise licences go on the same quote as the hardware, as our licensing page describes; quantities and lead time are confirmed in writing with the quote, on one EU contract and invoice.

FAQ