System Capabilities Supported by vGPU#
Secure Boot for Virtual Machines#
Secure boot is a security standard that ensures only trusted software, such as signed operating systems, firmware, and drivers, can execute during the boot process. In virtualized environments, secure boot protects the integrity of the virtual machines (VMs), ensuring that only trusted OS and software are loaded. This is particularly critical for sensitive workloads or environments requiring GPU acceleration, such as AI/ML or graphics processing, by ensuring the VM operates in a secure environment. In addition, it improves stability, ensuring that only compatible and verified drivers are used, reducing the risk of system crashes. Secure boot can help organizations meet regulatory and compliance requirements for secure computing environments.
Secure boot requires GPU drivers to be properly signed for compatibility. Without proper signing, the VM may fail to recognize the GPU or prevent the driver from loading, impacting acceleration capabilities. Unsigned or improperly signed drivers will prevent the system from booting or operating securely.
For Linux guest VMs, NVIDIA provides a procedure to sign guest drivers, ensuring compatibility with secure boot environments. Detailed instructions on signing NVIDIA drivers for Linux can be found here. The procedure applies to both regular Linux drivers and vGPU guest drivers. Follow the steps outlined in the documentation to sign and deploy your drivers in a secure boot-enabled environment.
Secure boot operates by verifying cryptographic signatures against trusted keys stored in firmware. For virtual machines:
The hypervisor provides secure boot capabilities as part of its VM configuration.
The VM must use an operating system signed by the OS vendor.
The hypervisor’s secure boot mechanism verifies driver signatures, ensuring that only properly signed GPU drivers are loaded.
The hypervisor’s secure boot mechanism validates the OS during the boot process using vendor-provided keys.
This requires OS vendors to sign their bootloaders and kernels with approved secure boot keys, ensuring compatibility with hypervisor environments. Hypervisors must also support secure boot natively, and not all platforms or guest operating systems provide seamless compatibility. Another limitation is the configuration complexity when deploying secure boot in environments with diverse OS needs, as administrators may need to manually import and manage custom keys. Additionally, while secure boot has minimal performance overhead, enabling it may slightly increase VM boot times.
When deploying secure boot, using supported operating systems pre-signed by their vendors, such as Microsoft-signed Windows distributions or Canonical-signed Ubuntu builds, is essential. Sticking to official distributions reduces configuration complexity and ensures compatibility with the hypervisor. Testing VM boot processes after enabling secure boot is also crucial to verify proper key signing and functionality, particularly for workloads relying on vGPU features. Updating the hypervisor firmware and GPU drivers further ensures smooth compatibility and mitigates security risks. For environments requiring custom OS builds administrators should prepare to sign bootloaders and drivers with custom keys that are compatible with the hypervisor’s secure boot framework.
Consult with your virtualization platform vendor or one of their partners to verify whether their platform supports secure boot and what VM operating systems are supported.
Note
Before using an NVIDIA GPU for a VM enabled with one or more virtual GPUs, if the VM uses UEFI boot and you plan to install a Linux guest OS but don’t intend to sign the vGPU drivers, ensure that secure boot is disabled.
Windows Subsystem for Linux (WSL)#
Windows Subsystem for Linux (WSL) is a Microsoft feature that enables users to run a full Linux terminal-based environment directly on Windows without needing a dual-boot setup or separate Linux VM. WSL is widely used in development, automation, and AI/ML workflows where access to native Linux tools is required. In particular, WSL 2 introduces a real Linux kernel running in a lightweight virtual machine, allowing for more complete Linux compatibility and support for container-based applications.
When paired with GPU acceleration, WSL allows Linux-based applications running inside Windows to access the GPU for compute-intensive tasks, including AI training, inference, and simulation workloads. This improves developer productivity by streamlining Linux and Windows workloads within a single VM.
Hypervisor |
vGPU Version |
Hypervisor Version and Guest OS Support |
|---|---|---|
Canonical Ubuntu with KVM |
Supported since vGPU 21.0 |
Supported since Canonical Ubuntu 22.04 (Windows guest VMs) |
Microsoft Azure Local |
Supported since vGPU 18.0 |
Supported since Microsoft Azure Local 12.2504 (Windows guest VMs) |
Microsoft Windows Server |
Supported since vGPU 18.0 |
Supported since Microsoft Windows Server 2025 (Windows guest VMs) |
Red Hat Enterprise Linux with KVM |
Supported since vGPU 21.0 |
Supported since Red Hat Enterprise Linux 10 (Windows guest VMs) |
Note
Information for Nutanix AHV, Suse Linux Enterprise Server (SLES), and Proxmox VE is available in the generic KVM vGPU release notes.
This allows GPU-accelerated Linux applications to run inside WSL 2 within a virtualized environment.
Running WSL 2 inside a virtual machine relies on nested virtualization. NVIDIA vGPU software does not support nested virtualization in general; WSL 2 is a specific exception, alongside Virtualization-Based Security. Nested virtualization must therefore be supported by the hypervisor and explicitly enabled for the guest VM before WSL 2 can be installed. On the KVM reference hypervisors, this means the nested kernel module parameter must be enabled and the guest CPU must be configured to expose virtualization extensions.
Enabling nested virtualization is a hypervisor-level task, and the steps are documented by each hypervisor vendor:
Hypervisor |
Setup Instructions |
|---|---|
Canonical Ubuntu with KVM |
|
Microsoft Azure Local |
|
Microsoft Windows Server |
|
Red Hat Enterprise Linux with KVM |
Once nested virtualization is enabled, WSL 2 is installed inside the Windows guest VM itself, so the remaining steps depend on the guest operating system rather than on the hypervisor. Refer to the Microsoft WSL documentation for Windows client guests, and to Install WSL on Windows Server for Windows Server guests. WSL 2 requires Windows Server 2022 or later.
For vGPU-specific support statements and system requirements, refer to the release notes for your hypervisor, and to the NVIDIA vGPU deployment guides for Windows Server, Azure Local, Canonical Ubuntu with KVM, and Red Hat Enterprise Linux with KVM.
Virtualization Based Security (VBS)#
Virtualization-Based Security (VBS) is a Microsoft feature that uses hardware-assisted virtualization to create an isolated, secure environment—separate from the operating system—to protect sensitive processes and data, even in the event of OS compromise. VBS leverages technologies such as IOMMU, TPM 2.0, and Secure Boot to establish a virtual trust boundary between the guest VM and the hypervisor.
When supported, enabling VBS in a vGPU-enabled virtual machine can enhance overall platform security. Potential benefits include:
Isolating credential and key storage
Reducing the risk of kernel-level attacks
Protecting security-sensitive components of the OS from tampering
This added layer of protection is particularly valuable in industries such as finance, healthcare, and government, where compliance and data integrity are critical.
For more information about VBS, refer to Virtualization-based Security (VBS) on the Microsoft learning website.
Hypervisor |
vGPU Version |
Supported GPUs, Hypervisor Versions, Guest OS Versions, and Requirements |
|---|---|---|
Microsoft Azure Local |
Supported since vGPU 19.0 |
|
Microsoft Windows Server |
Supported since vGPU 19.0 |
Microsoft Compute Driver Model (MCDM)#
On Windows, NVIDIA GPUs operate under a Microsoft-defined driver model. The Windows Display Driver Model (WDDM) is the standard model used whenever the GPU drives a display or runs graphics workloads, and it is what vGPU VMs running vPC and vWS workloads use. For compute-only workloads that do not need a display, NVIDIA has historically offered the Tesla Compute Cluster (TCC) driver model, which bypasses the Windows graphics stack to reduce overhead and remove the dependency on an active desktop session.
The Microsoft Compute Driver Model (MCDM) is a compute-only driver model based on a subset of the Windows Display Driver Model (WDDM). It allows compute devices to use the Windows driver infrastructure without providing display or graphics functionality.
Starting with vGPU 21.0, NVIDIA vGPU software uses MCDM rather than TCC for Windows compute workloads, with TCC mode targeted for deprecation. Administrators running compute workloads in Windows guest VMs should plan for this transition, particularly where tooling or scripts inspect or set the driver model.
MCDM is supported on both MIG-backed and non-MIG-backed configurations, where the vGPU profile supports it. The driver model is set per VM with nvidia-smi -fdm 2, and MCDM and WDDM VMs can run side by side on the same physical GPU, including in multi-vGPU and fractional multi-vGPU configurations.
A vGPU running in MCDM mode does not support display output or graphics operations. Suspend-resume, live migration and hibernation are supported for VMs running in MCDM mode.
MCDM is supported on all GPU architectures supported by vGPU 21.0. The Windows guest VM must run Windows 11 21H2 or later, which provides the WDDM 2.6 or later required by MCDM.
Hypervisor |
vGPU Version |
Minimum Guest OS Version |
|---|---|---|
Canonical Ubuntu with KVM |
Supported since vGPU 21.0 |
Windows 11 21H2 or later |
Microsoft Azure Local |
Supported since vGPU 21.0 |
Windows 11 21H2 or later |
Microsoft Windows Server |
Supported since vGPU 21.0 |
Windows 11 21H2 or later |
Red Hat Enterprise Linux with KVM |
Supported since vGPU 21.0 |
Windows 11 21H2 or later |
VMware vSphere |
Supported since vGPU 21.0 |
Windows 11 21H2 or later |
Wayland#
Wayland is a modern display server protocol designed to replace the traditional X11 system used by most Linux desktop environments. It combines the display server and window manager into a single component called the Wayland compositor, providing a simpler and more efficient architecture for graphical composition. This design reduces latency, improves performance and security, and offers better support for modern multi-monitor and high-resolution display configurations.
Starting with vGPU 20.0, NVIDIA vGPU software introduces support for Wayland across all supported GPUs, enabling virtual machines to run Wayland-based desktop environments on compatible Linux guest operating systems. Wayland is supported on RHEL 8, RHEL 9, RHEL 10, Ubuntu 22.04, and Ubuntu 24.04, and is available on all hypervisors that support Linux vGPU guest VMs. NVIDIA vGPU software supports up to four virtual displays in Wayland environments.
More information on wayland is available here.