Deploying graphics and compute acceleration within modern hypervisors forces IT leaders to resolve a fundamental architectural trade-off: full GPU passthrough versus virtual GPU (vGPU) slicing. While passing an entire physical PCIe accelerator directly to an individual guest operating system delivers straightforward bare-metal performance, it locks out dynamic resource pooling and hardware consolidation. Conversely, official GPU accelerators managed via NVIDIA vGPU software unlock granular time-sliced sharing, advanced resource scheduling, and multi-tenant live migration. However, this flexibility introduces strict hypervisor dependencies and recurring licensing obligations. Selecting the appropriate model requires navigating driver compatibility across platforms like VMware vSphere 9.0 and KVM, auditing concurrent workload profiles, and evaluating strict budget commitments.
View the data behind this chart
| Hypervisor | Live Migrate | MIG-Backed | |
|---|---|---|---|
| VMware vSphere 9.0 | Supported | Supported | Supported |
| RHEL with KVM 10.0 | Supported | Supported | Supported |
| Ubuntu KVM 24.04 | Supported | Supported | Supported |
| Citrix XenServer 8.4 | Not Supported | Not Supported | Narrower Set |
| Windows Server 2025 | Not Supported | Not Supported | Narrower Set |
| Azure Local 12.2504 | Not Supported | Not Supported | Narrower Set |
GPU Virtualisation Fundamentals: Defining the Core Mechanisms
In modern enterprise data centres, hardware-accelerated computing is essential across visual design workstations, remote desktop infrastructure, and containerised artificial intelligence. The foundational challenge for system administrators lies in mapping physical PCIe accelerator hardware to guest virtual machines without creating unmanageable resource bottlenecks.
Direct GPU passthrough is commonly implemented through device assignment mechanisms such as VMware DirectPath I/O or the Linux VFIO stack, in which the hypervisor detaches a physical accelerator from the host kernel and binds it directly to the PCI address space of a single guest VM. The guest operating system gains exclusive access to the GPU silicon, execution units, and video memory using standard bare‑metal drivers, with minimal additional abstraction from the hypervisor.
NVIDIA vGPU technology fundamentally alters this relationship by introducing a mediator layer between the hardware and the hypervisors. Through host software management components obtained via NVIDIA’s enterprise licensing and software portals, the physical graphics card is abstracted into several distinct virtual GPU instances. These virtual slices are scheduled across multiple concurrent VMs, allowing disparate guests to share compute and memory resources dynamically. | Attribute | GPU Passthrough | NVIDIA vGPU | | :--- | :--- | :--- | | **Licensing Cost** | Zero incremental NVIDIA vGPU software licence fee | Recurring annual per-concurrent-user licence (vPC/vWS) | | **VM Density** | Strict 1:1 hardware-to-VM assignment | Multi-tenant slicing (up to dozens of VMs per physical GPU) | | **Live Migration** | Generally unsupported or heavily restricted | Fully supported on certified hypervisors (e.g. vSphere, KVM) | | **Hardware Isolation** | Full physical isolation at PCIe boundary | Software time-sliced or hardware-partitioned (MIG-backed) | | **Typical Use Case** | Dedicated AI training, heavy batch rendering, dedicated research nodes | Enterprise VDI, multi-seat CAD/engineering, shared analytics |
GPU Passthrough: Zero Licensing Overhead vs Hardware Locking
GPU passthrough remains a staple deployment pattern for organisations with heavy, dedicated workloads that fully saturate an accelerator. Because the guest VM interacts directly with the PCIe device, full passthrough bypasses the proprietary NVIDIA vGPU software scheduler entirely. This eliminates the requirement for NVIDIA vGPU enterprise licences on the GPU itself, enabling teams to deploy production workloads without NVIDIA’s incremental vGPU licensing costs.
Furthermore, passthrough environments simplify the software driver chain. NVIDIA’s vGPU user documentation states that its software stack supports NGC containers on guest VMs configured with either an NVIDIA vGPU or a pass‑through GPU on supported platforms, allowing containerised workloads to access the GPU in a similar way to dedicated workstations. High-throughput batch inference or single-user visual rendering tasks often exploit direct passthrough to minimise software overhead.
However, this isolation brings substantial infrastructure penalties. When a physical GPU is bound to a single virtual machine via passthrough, that hardware is completely locked. Unused compute cycles or idle frame buffers cannot be harvested by neighbouring workloads. Moreover, traditional virtualisation features—such as live migration, dynamic load balancing, and memory snapshots—are routinely disabled or heavily restricted under standard passthrough configurations.
NVIDIA vGPU: Shared Compute and Flexible Virtualisation
NVIDIA vGPU addresses common underutilisation in shared environments that rely on passthrough by slicing physical graphics hardware across several virtual desktops and compute environments. By deploying the NVIDIA vGPU Manager on the hypervisor host and paired guest drivers inside each VM, administrators can configure precise time-sliced profiles tailored to specific user demands.
According to NVIDIA’s IT‑management documentation, vGPU is supported with major enterprise hypervisors to deliver accelerated compute and visually rich user experiences while simplifying management and increasing operational flexibility, with support and features documented per hypervisor version. By splitting a single GPU into multiple virtual allocations, infrastructure teams can raise rack density and consolidate users onto fewer physical servers when workloads are suitable for sharing.
Importantly, modern vGPU frameworks integrate deeply with data centre virtualisation fabrics. As of current NVIDIA vGPU Software Documentation (v20.0–20.2 releases) and associated knowledge‑base matrices, the platform supports advanced capabilities such as Multi‑VGPU configurations, vGPU schedulers, heterogeneous vGPU provisioning, suspend‑resume, Unified Virtual Memory (UVM), Deep Learning Super Sampling (DLSS), device groups, and live migration, with specific feature availability depending on the hypervisor and release version.
MIG Hardware Partitioning and MIG-Backed vGPU Modes
To understand modern GPU sharing, engineers must differentiate software-based time-slicing from hardware-level Multi-Instance GPU (MIG) architecture. While standard vGPU profiles traditionally multiplex workloads over time using software scheduling engines, MIG partitions physical silicon into isolated instances down to the memory crossbars, cache hierarchies, and compute engines. Teams evaluating modern compute architectures can use MIG documentation to understand how GPU partitioning provides hardware‑level isolation of caches, memory controllers and compute engines.
NVIDIA documents support for both MIG‑backed 1:1 vGPU and MIG‑backed time‑sliced vGPU modes on platforms that are marked as supporting these features in its vGPU knowledge‑base matrices. In a MIG-backed 1:1 vGPU configuration, a VM receives an exclusive, hardware-isolated MIG partition managed through the familiar vGPU management interface, delivering deterministic performance and physical fault isolation.
Conversely, MIG-backed time-sliced modes allow hypervisors to run time-sliced vGPU shares on top of underlying MIG partitions. This layered approach provides maximum architectural granularity: high-priority production workloads can inhabit strictly isolated hardware slices, while auxiliary virtual desktops share time-sliced allocations within a secondary partition on the same physical device.
Licensing Requirements: vPC, vWS, and Operational Realities
The enhanced flexibility of vGPU is governed by strict commercial and operational licensing frameworks. NVIDIA's current vGPU documentation states that products such as RTX Virtual Workstation (vWS), Virtual PC (vPC), and Virtual Applications (vApps) are licensed products on NVIDIA GPUs. For products such as RTX Virtual Workstation, Virtual PC and Virtual Applications, NVIDIA documents that vGPU instances run at reduced capability until a valid licence is acquired and checked out from an active licence server.
NVIDIA licensing FAQ documentation establishes that each virtual desktop requires a license after it is started and running. The current licensing metric is concurrent use: one vPC or vWS licence is needed for each VM that is running and drawing on virtual GPU resources. Indicative UK list pricing for subscription licensing typically ranges from roughly £35–£45 per concurrent user/year for Virtual Applications (vApps), £75–£95 per concurrent user/year for Virtual PC (vPC), to upwards of £200–£250 per concurrent workstation/year for RTX Virtual Workstation (vWS). In contrast, enterprise passthrough hardware—such as NVIDIA L40S, A16, or L4 PCIe accelerators—typically costs between £2,000 and £8,500+ per card upfront depending on silicon grade, with no recurring hypervisor vGPU software fees. Administrators managing dense remote desktop environments must therefore size their license pools against peak simultaneous users rather than total provisioned seats to optimise GPU density for VDI hosts.
Deploying vGPU software also alters standard IT operations and patching cadences. The NVIDIA product-support matrix requires administrators to log into an NVIDIA Enterprise Account and download the hypervisor-specific driver package directly from the NVIDIA Licensing Portal. Maintaining long‑term stability benefits from tracking branch lifecycles closely; for example, the vGPU 16 long‑term support release branch reached terminal maintenance with version 16.14 in April 2026, operating alongside the active vGPU 20 release stream.
View the data behind this chart
| Layer | Detail |
|---|---|
| Direct Passthrough Layer | 1:1 mapping, unmanaged scheduler, license-free |
| vGPU Slicing Layer | Multi-VM time-slicing, concurrent license bound |
| Hardware MIG Partition | Silicon-level isolation, optional vGPU broker |
Hypervisor Support Matrices and Feature Availability
Feature parity between GPU virtualisation methods varies considerably across hypervisors. Enterprise procurement specifications must be written against exact hypervisor release versions rather than generic platform names. NVIDIA's knowledge base reveals distinct capability boundaries between enterprise hypervisors.
NVIDIA's knowledge-base matrices document varying feature sets across hypervisors, as outlined below: | Hypervisor Platform | Multi-VGPU | vGPU Schedulers | Live Migration | MIG-Backed Modes | Heterogeneous vGPU | Suspend-Resume | UVM & DLSS | | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | | **VMware vSphere 9.0** | Supported | Supported | Supported | Supported (1:1 & Time-Sliced) | Supported | Supported | Supported | | **RHEL KVM 10.0** | Supported | Supported | Supported | Supported (1:1 & Time-Sliced) | Supported | Supported | Supported | | **Ubuntu KVM 24.04** | Supported | Supported | Supported | Supported (1:1 & Time-Sliced) | Supported | Supported | Supported | | **Citrix XenServer 8.4** | Supported | Supported | Not Supported | Not Supported | Not Supported | Supported | Supported | | **Windows Server 2025** | Supported | Supported | Not Supported | Not Supported | Not Supported | Supported | Supported | | **Azure Local 12.2504** | Supported | Supported | Not Supported | Not Supported | Not Supported | Not Supported | Supported |
As the matrix demonstrates, VMware vSphere 9.0, Red Hat Enterprise Linux with KVM 10.0, and Canonical Ubuntu with KVM 24.04 support the broadest vGPU feature footprint. Platforms like Citrix XenServer 8.4, Microsoft Windows Server 2025, and Microsoft Azure Local 12.2504 support critical workload execution engines such as Multi-VGPU and DLSS, but lack live migration or MIG-backed modes. NVIDIA documentation notes Windows Server guest support has been present since vGPU 18.0, and Azure Local support is documented across vGPU 18.0 and 19.0 matrices. For environments such as Nutanix AHV, SLES, and Proxmox VE, administrators must consult third-party vendor documentation directly.
UK Infrastructure Decision Framework and Operational TCO
For UK IT directors, systems architects, and public-sector procurement leads, choosing between passthrough and vGPU hinges on balancing hardware footprint against recurring operational software costs. From an NVIDIA vGPU licensing perspective, a dedicated passthrough model does not require vGPU licences on the GPU, which can make it commercially attractive for research clusters, specialised engineering workstations, or bare‑metal container pipelines where a 1:1 hardware‑to‑VM ratio is acceptable, though other software or optional NVIDIA licences may still apply.
However, when supporting distributed knowledge workers, visual designers, or mixed-tier engineering teams across regional UK offices, running bare passthrough often results in massive hardware over-provisioning. Implementing vGPU time‑slicing can reduce physical rack footprint, power draw, and cooling requirements in data centres by consolidating workloads onto fewer GPUs, which may help offset the ongoing software licensing fees for suitable workload profiles.
Procurement teams must also align deployments with UK regulatory and public-sector frameworks, including Crown Commercial Service (CCS) agreements such as G-Cloud and the Technology Products & Associated Services (TePAS) framework, alongside Cyber Essentials and NCSC cloud security principles. Consider two contrasting UK public-sector use cases: * **NHS Trust Clinical VDI Rollout:** An acute NHS trust deploying digital pathology and EPR visualisations to 500 clinical staff across multiple hospitals favours **NVIDIA vGPU (vPC/vWS)**. Procured via CCS TePAS, vGPU slicing delivers high user density per rack server, allows dynamic failover and non-disruptive host patching via live migration in vSphere, and conforms to Cyber Essentials controls through centralised image management, easily justifying £75–£95/user annual licensing against the prohibitive cost of 500 dedicated physical GPUs. * **MOD Research or Academic Compute Cluster:** A defence research programme handling sensitive sovereign model training or classified telemetry analysis favours **Direct GPU Passthrough**. Bound to local physical infrastructure without requiring external licence servers or continuous licence checkout, passthrough guarantees strict hardware isolation, eliminates recurring subscription overhead, and fits isolated air-gapped environments subject to strict Defence Infrastructure Organisation (DIO) and NCSC high-assurance architectural controls.
Sources
Every figure in this article traces to the sources below.
- •NVIDIA — vGPU Software Documentation v20.0-20.2 Index
- •NVIDIA — GRID vGPU User Guide
- •NVIDIA — vGPU Knowledge Base Matrix
- •NVIDIA — System Capabilities and Hypervisor Releases
- •NVIDIA — Network Licensing Service FAQ
- •NVIDIA — Enterprise IT Management Documentation