GPUs in virtual machines: passthrough, DDA and what Windows guests can use

Verified 2026-10-293 min read

The three ways to give a Windows VM a GPU, what each one supports, and the IOMMU/vBIOS problems that decide whether it boots.

Tested onPro (26H2) / Server · Build 26300.9457 / 26100.33650 · x64

Build: 26300.9457 / 26100.33650
Edition: Pro (26H2) / Server
Architecture: x64
Support: Documentation (E1)
Evidence: E1Official documentation
Verified: 2026-10-29
Page type: Concept

The short answer

There are three different things people call “GPU in a VM”, and they are not interchangeable:

Approach	What the guest gets	Typical use
Discrete Device Assignment (DDA)	one physical GPU, exclusively	Hyper-V, workstation VMs
Full PCIe passthrough	one physical GPU, exclusively	Proxmox/KVM, gaming VMs
Virtual GPU (vGPU/GPU-P)	a slice of a supported GPU	VDI, many sessions

In all three cases the guest sees a real graphics driver, and the host loses the card (except vGPU, which is licensed and platform-specific).

What decides whether it works

IOMMU enabled in firmware and the hypervisor. Without it, passthrough is not possible.
The GPU must sit in its own IOMMU group — if it shares a group with the chipset or a NIC, you cannot isolate it.
The guest needs a driver for that card — the same driver as bare metal.
The vBIOS — some consumer cards refuse to initialise in a VM without a vBIOS dump or a vendor-specific flag.
The card must not be the host’s only display output while you configure it.

# in the guest: what did the VM actually get?
Get-PnpDevice -Class Display | Select-Object FriendlyName,Status,InstanceId
Get-CimInstance Win32_VideoController | Select-Object Name,DriverVersion,AdapterRAM

In the guest, InstanceId still looks like a PCI device — that is expected with passthrough. A Status : Error device usually means the driver bound but the card did not initialise.

Windows Server guests: DDA specifics

DDA is the supported path on Hyper-V:

the GPU is dismounted from the host and assigned to one VM;
the VM must be stopped to assign or remove;
the guest needs the vendor driver installed inside the VM;
some server GPUs support partitioning (GPU-P) instead, which requires vendor support and licensing.

DDA is not “GPU sharing”: one card, one VM at a time.

Desktop guests: what to expect

Gaming: works well enough in KVM with a vBIOS and a second GPU for the host; latency depends on the display path (looking-glass, HDMI passthrough, or a physical monitor on the passed-through card).
Compute (CUDA/ROCm): usually the easiest case — no display path needed.
Video encode: needs the vendor’s encoder support inside the guest; some consumer drivers disable encode in VMs.

Common failures and what they mean

Symptom	Usual cause
VM will not start with the device attached	IOMMU off, or device in a shared group
Guest boots, GPU shows error 43/31	vBIOS or driver refuses the VM
Works until reboot	host reclaimed the device, or a driver update
Host loses display	the only GPU was assigned away
Very low performance	link width/speed downgraded, or software rendering is active

Error 43 on a passed-through GPU is a driver policy refusal, not a hardware fault — the fix is vendor/driver-specific, and on some consumer cards it is simply not supported.

Check before you invest an evening

# host: IOMMU enabled and device grouping (Proxmox example)
# dmesg | grep -e DMAR -e IOMMU
# for d in /sys/kernel/iommu_groups/*; do echo "IOMMU group ${d##*/}"; done

On Windows hosts, Device Manager → View → Devices by connection shows which PCIe root port the GPU sits under; that maps to the grouping you will fight with.

Lab boundary

E1. DDA and GPU-P requirements are Microsoft-documented. The lab host has no discrete GPU assigned to a VM, so passthrough was not attempted — this page deliberately publishes no performance numbers.