Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
VMORE CLOUDTech Today for a Smarter Tomorrow
LINUXVIRTUALIZATIONNVIDIA
virtio-nvgpu Brings Shared NVIDIA GPU Access to Linux KVM Guests
An experimental virtio-nvgpu project gives Linux KVM guests driver-level access to an NVIDIA GPU, opening a path to shared GPU workloads without traditional PCI passthrough.
Key Takeaways
- virtio-nvgpu is an experimental virtio device and guest driver for near-native NVIDIA GPU access in KVM virtual machines.
- The design forwards NVIDIA kernel-driver ioctls rather than translating every Vulkan or OpenGL API call.
- Nestri reports four guests sharing one GeForce RTX 3060 in its current testing.
- Reported results show roughly 98–100% of bare-metal GPU performance for workloads with frames of about 2 ms or more.
- The project is not yet a replacement for VFIO passthrough or production-grade NVIDIA vGPU isolation.
In this articleWhat is virtio-nvgpu?How the NVIDIA GPU sharing model worksPerformance and multi-guest testingSecurity and isolation considerationsHow it compares with VFIO and virtio-gpuCurrent project status
What Is virtio-nvgpu?
virtio-nvgpu is an experimental open-source project from Nestri Labs that aims to provide near-native NVIDIA GPU access inside Linux KVM guests. Instead of passing the entire PCI GPU into one VM, the project keeps the NVIDIA device attached to the host and exposes a custom virtio device to guests.
The important architectural choice is where virtualization happens. The guest runs NVIDIA’s user-space libraries, while a custom guest kernel driver forwards requests to the host NVIDIA driver. The project therefore works at the NVIDIA kernel-driver ABI level rather than serializing every high-level graphics API operation.
How virtio-nvgpu Shares an NVIDIA GPU
Inside the guest, applications can use NVIDIA’s user-space stack for workloads such as Vulkan rendering and NVENC encoding. Requests involving the NVIDIA device files are sent through a virtio control queue to the host-side device implementation. Shared memory is used for mapped GPU regions, while the host NVIDIA driver remains responsible for the actual hardware.
This architecture is particularly interesting for headless game-streaming and GPU workloads where rendering, compositing and video encoding can remain on the GPU inside the guest. The intended pipeline is a guest application, a guest-side compositor, GPU-side processing and NVENC, with the compressed video stream leaving the VM.
The project is designed around a driver-level proxy model: the guest gets access to NVIDIA’s driver interface while the physical GPU remains under the host’s NVIDIA driver.
Performance: What the Early Tests Show
Nestri’s published benchmark data was collected on a GeForce RTX 3060 using NVIDIA driver 595.99.02. The project reports that GPU-bound frames taking roughly 2 ms or longer remained within about 2% of the corresponding bare-metal workload in its test setup. Very short workloads showed larger relative overhead because a fixed wake-up cost becomes significant when the frame itself is tiny.
| Test characteristic | Reported result |
|---|---|
| GPU | GeForce RTX 3060 |
| NVIDIA driver | 595.99.02 |
| GPU-bound frames ≥ 2 ms | Approximately 98–100% of bare metal |
| Very light frames ≤ 0.5 ms | Greater relative overhead |
| Multi-guest test | Four guests on one RTX 3060 |
| NVENC | Four simultaneous guest encodes demonstrated |
The repository also reports a four-guest test in which each VM rendered at roughly 25–26 frames per second under the same workload, with the aggregate result close to the single-guest measurement. Four guests is a demonstrated test point, not a stated architectural maximum.
Vulkan, Wayland, NVENC and CUDA
The current project reports several working capabilities, including NVIDIA GPU enumeration through nvidia-smi, Vulkan rendering, Wayland presentation, NVENC through Vulkan Video, and host-memory-backed imported buffers. CUDA support is present at the interface level but remains substantially less validated than the demonstrated rendering path.
- Vulkan: off-screen rendering has been demonstrated.
- Wayland: a guest compositor can present rendered content.
- NVENC: guest-side hardware encoding has been demonstrated.
- CUDA: device enumeration works, but broader CUDA workloads remain experimental.
Security and Isolation: An Important Limitation
Sharing a physical NVIDIA GPU between isolated tenants is not simply a performance problem. The project documentation explicitly notes that virtio-nvgpu does not currently provide the same hardware isolation boundary as VFIO passthrough.
The host NVIDIA driver remains part of the trusted computing base, and the current backend holds host device descriptors inside the VMM process. The project’s planned per-guest isolation helper is documented as a design but is not yet the component handling the device descriptors. Several NVIDIA resource-management and UVM/modeset interfaces also remain outside the project’s mature filtering model.
Production warning: The current project should be treated as experimental. The project’s own documentation says VFIO passthrough with an IOMMU provides a stronger isolation boundary and remains the appropriate approach for mutually untrusted tenants. NVIDIA vGPU is another established virtualization path where supported hardware, hypervisors and licensing requirements are available.
virtio-nvgpu vs. VFIO and virtio-gpu
Traditional VFIO GPU passthrough gives a VM direct ownership of the PCI device. That can provide strong isolation and native driver access, but the whole GPU is normally dedicated to one guest. A host cannot simultaneously use that same physical GPU as a shared resource in the way targeted by virtio-nvgpu.
By contrast, virtio-gpu with API translation can allow multiple VMs to use a GPU, but graphics operations cross a virtualization boundary through the virtual graphics stack. virtio-nvgpu takes a different route by allowing the NVIDIA user-mode driver to build GPU command buffers in the guest and forwarding lower-level driver operations instead.
| Approach | GPU sharing | Guest NVIDIA stack | Isolation profile | Primary trade-off |
|---|---|---|---|---|
| VFIO passthrough | Usually one VM per GPU | Full driver stack | Strong with IOMMU | GPU is dedicated to the VM |
| virtio-gpu / Venus | Yes | Virtualized graphics path | Depends on implementation | API translation and transport overhead |
| virtio-nvgpu | Yes, experimental | NVIDIA user-space stack | Not equivalent to VFIO isolation | Experimental driver-ABI proxy model |
Current Project Status
As of September 26, 2026, virtio-nvgpu should be considered an active experimental project rather than a production virtualization platform. The repository documents tested driver profiles beginning with the 535.129.03 ABI profile, with additional profiles for 580.178.04 and 595.71.05. Testing has been performed on an RTX 3060 with driver 595.99.02 and an RTX A2000 with driver 615.71.09, but the project explicitly notes that these are limited test points.
Several areas remain unfinished or deliberately out of scope, including a mature multi-tenant security envelope, broader game testing, full unified virtual memory, scanout, MIG and SR-IOV. Driver ABI compatibility is also an important operational constraint because NVIDIA kernel-driver interfaces can change between releases.
Why This Matters for Linux Virtualization
The significance of virtio-nvgpu is not that it has already replaced established GPU virtualization technologies. Its importance is that it demonstrates another possible architecture for sharing NVIDIA hardware between KVM guests while preserving a substantial part of the native NVIDIA software stack inside each VM.
For cloud gaming, GPU-backed development environments, remote graphics and research workloads, that model could eventually reduce the need to dedicate one physical GPU to every VM. The security model and long-term driver compatibility, however, will determine whether the approach can move beyond experimental deployments.
VMoreCloud Technical Assessment
From a virtualization engineering perspective, the most interesting aspect is the boundary placement. virtio-nvgpu avoids putting every Vulkan call onto the virtio transport and instead places the virtualization boundary around NVIDIA’s kernel-driver interface. That is a materially different design from API-level remoting and explains why the project’s early measurements can approach bare-metal performance for sufficiently GPU-bound frames.
That performance result should not be interpreted as a production readiness claim. The benchmark is a limited project measurement on specific hardware and driver versions, and the repository itself documents significant security and compatibility work that remains. Teams evaluating it should reproduce workloads on their own hardware and treat tenant isolation as a separate requirement from performance.
↗
Primary Sources & Further Reading
Nestri Labs — virtio-nvgpu GitHub repositoryProject benchmark methodology and raw results
NVIDIA — Linux with KVM support for vGPU
Nestri Labs — virtio-nvgpu GitHub repositoryProject benchmark methodology and raw results
NVIDIA — Linux with KVM support for vGPU
