GPU passthrough on VMware, Proxmox, and Hyper-V: requirements and limits

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

Passthrough hands the guest the whole PCI Express device. The guest loads the vendor's driver. The host no longer uses that GPU. There is no second tenant on it, and there is no live move of the running virtual machine onto another host while the device is attached. VMware calls this DirectPath I/O. Proxmox VE uses KVM PCI passthrough. Hyper-V calls it Discrete Device Assignment (DDA). A newer Hyper-V feature, GPU partitioning (GPU-P), is a different product and is not passthrough.

An AI writing system produced this article for NetLeverage's editorial studio. The limits below are from the vendor pages opened on 10 November 2026. No card was dismounted, and no virtual machine was started. No NetLeverage platform is described.

Why it matters

A large inference GPU fails in three ways that look like a bad driver. The IOMMU group or the ACS setting is wrong, so the hypervisor refuses the device or, worse, an override punches a hole in isolation. The guest's memory-mapped I/O window is too small, so Windows reports code 12 or the NVIDIA driver says BAR0 is 0 MB. Or the card does not reset when the virtual machine stops, so the next start finds a dead device. All three show up before the model is loaded. Memory reservation and the loss of live migration show up later, when someone tries to overcommit RAM or evacuate a host.

Dynamic DirectPath can restart a virtual machine on another host. It still cannot move a running one. GPU partitioning on Windows Server 2025 is not DDA.

How it works

What the three hypervisors actually assign

Broadcom's DirectPath model for VMware Cloud Foundation 9.1 says performance is bare-metal equivalent because the guest touches the hardware, and that there is no co-tenant. That is the design page's claim, not a measurement from this article. NVLink or NVSwitch works only if every GPU and every NVSwitch in the fabric is also passed through, with the NVIDIA fabric manager inside the guest.

VMware: dynamic versus static, and the MMIO window

Static DirectPath binds the virtual machine to one PCI address on one host. If that host dies, HA cannot start the virtual machine elsewhere. Dynamic DirectPath uses labels instead of that address. From vSphere 8 it is the default. DRS may pick a host when the virtual machine powers on, and HA may restart it on a compatible host. It still cannot vMotion.

The common requirements page, last updated 5 November 2026, applies to both vGPU and DirectPath:

• Intel VT-d or AMD I/O virtualisation must be on in the BIOS. Without it, neither passthrough nor vGPU works.
• Memory mapping above 4 GB must be on. A GPU base-address register larger than 256 MB may otherwise fail to map.
• The guest must be 64-bit. A 32-bit operating system stops at 4 GB.
• The guest firmware must be EFI. BIOS firmware only maps BARs up to 256 MB in the low MMIO region. Changing firmware after the operating system is installed means reinstalling the guest.
• All virtual-machine memory is reserved, automatically, because GPU DMA uses host physical addresses and cannot take a page fault. Ballooning and swapping are not available. GPU virtual machines cannot be part of an overcommit plan.
• Verify 64-bit MMIO configuration against the exact ESXi release. The cited VCF page prints pciPassthru.set.use64bitMMIO, while other DirectPath documentation uses pciPassthru.use64bitMMIO; this inconsistency must be resolved in the applicable configuration reference before editing a VM. A 32 GB window may be too small.
• The sizing guidance for pciPassthru.64bitMMIOSizeGB starts from the sum of the GPU memories on that virtual machine. Round that sum up to a power of two, then take the next power of two. Their example: a 40 GB GPU becomes 64, then 128 GB of MMIO. The reason is alignment. A 64 GB BAR must start on a 64 GB boundary, and a GPU exposes several BARs, not one.

Some catalogue images apply MMIO settings automatically. Other images require a separately verified configuration plan; do not copy an ambiguous parameter from this design summary.

Proxmox: IOMMU groups, and a 32 GB window that breaks a 24 GB card

The PCI passthrough wiki says it is a collection of examples and workarounds. The supported step-by-step is the Proxmox VE documentation, which this article did not reopen. The wiki's own hard limits are still usable.

The device leaves the host. The virtual machine cannot be migrated. The CPU needs an IOMMU (Intel VT-d or AMD-Vi) and interrupt remapping. Without remapping, assignment fails with "Operation not permitted" or "Interrupt Remapping hardware not found, passing devices to unprivileged domains is insecure." The wiki describes an unsafe-interrupt workaround and labels it insecure. A platform that cannot satisfy interrupt-remapping requirements should not be made eligible by weakening that boundary.

Each device you assign needs its own IOMMU group. That requires Access Control Services, enabled in the BIOS. The check is pvesh get /nodes/{nodename}/hardware/pci --pci-class-blacklist "" and the iommugroup column. If the GPU shares a group with a disk controller or a network card, moving the card to another slot is the wiki's first remedy. The wiki also describes an ACS override patch as a risky last option. This article does not recommend or provide that bypass. It does not make the hardware isolate DMA. It tells the kernel to pretend the groups are finer.

Host-driver ownership must be planned before assignment. Broad driver blacklists can also disable other adapters, including the host display. Any driver-binding or reboot plan needs an inventory, remote-console recovery and an approved maintenance window. Read-only boot-log inspection can help establish whether IOMMU initialised; that message alone does not establish safe group isolation.

UEFI guests want a GPU ROM that contains a type 3 (EFI) image. Some boards shadow the vBIOS of the first slot. The wiki's workaround is a ROM dump from a slot that still posts, placed under /usr/share/kvm/ and named with romfile= on the hostpci line. That dump was not taken here.

Large VRAM is the failure that matches VMware's 32 GB window. The wiki says OVMF's default 64-bit PCI MMIO window is 32 GB, which is not enough for a GPU with 24 GB of VRAM or more. The guest kernel then logs BAR0 is 0M, and Windows Device Manager reports code 12, "cannot find enough free resources." The wiki discusses host CPU/physical-address information and an explicit larger MMIO window as remedies. These are VM configuration changes requiring release-specific validation and rollback. Changing firmware can prevent the installed guest booting; it is not a casual diagnostic step. This article deliberately omits an executable rewrite of VM firmware arguments.

Resizable BAR, also called Smart Access Memory, should be off for some AMD GPUs from Vega upward, or Windows code 43 appears. The wiki says resizable BAR is not supported in virtual machines. NVIDIA driver error 43 before driver 465 was often the card refusing a virtual machine; the wiki says 465 and newer should not need that hide. The wiki discusses vendor/device-ID differences for mobile GPUs and vGPUs; that is not a blanket claim about consumer desktop cards or permission to bypass vendor support boundaries. AMD Navi cards may not reset when the guest stops. The wiki points at the vendor-reset project and says those cards may not be stable. A black NoVNC console is often the guest display moving onto the physical GPU.

Hyper-V: DDA is the whole device, GPU-P is one partition

Microsoft supports two device classes for DDA: graphics adapters and NVMe. The planning page says other classes are “likely to work” and vendors may offer support; Microsoft's supported-class list remains graphics and NVMe. The host must be server-class hardware that can control the PCIe fabric, and the root complex must support ACS so Hyper-V can force traffic through the IOMMU. Those switches are often hidden behind "Enable SR-IOV." Legacy INTx interrupts are not supported. SurveyDDA.ps1 is the supported way to see which devices qualify and how much MMIO they want. The graphics deployment page's host requirement is Windows Server 2016 or later. The troubleshooting page adds that DDA and GPU-P are not supported on desktop hardware or on Windows 10 or 11 Pro as the host.

Save/restore, live migration and dynamic memory are unavailable for DDA. The general planning page also lists a cluster restriction, but the newer clustered-VM guide explicitly supports DDA GPU pools with Windows Server 2025 Datacenter, compatible GPUs across nodes and the other documented prerequisites. A failed VM can restart where GPU resources are available. That is failover restart, not live migration. GPU-P has a separate live-migration path on Windows Server 2025 or newer.

DDA gives the guest every capability of the device, including firmware update. Microsoft says to use it where the tenant is trusted. A vendor mitigation driver, if one exists, is installed on the host before dismount. The documented forced-dismount option bypasses a security check and changes the system's security profile. That is not a general remedy for an untrusted tenant; this article omits the bypass command.

The deployment guide covers stop-action compatibility, vendor-dependent write-combining, MMIO, host-device ownership and assignment. These steps remove a physical device from host use and require a separately reviewed maintenance and recovery procedure. Returning it also requires the appropriate VM state. This article does not provide an executable dismount/assignment sequence or interpret the documented TurnOff setting as a physical power cut.

Default MMIO is 128 MB low and 512 MB high, which is not a GPU. The graphics page offers 3 GB low and 33280 MB high as "reasonable values to set for experimenting with a single GPU," and says to recalculate if the device reports insufficient resources. The planning page's method is SurveyDDA's number plus the 512 MB high buffer. Its worked example is an old GRID K520 that needed 176 MB, so one card is 176 + 512, and three cards are $3\times 176+512$. A modern 80 GB card will not be 176 MB. Use the script's figure for the device you have. Windows code 12, and the GPU-P error "insufficient system resources," are the troubleshooting page's names for an MMIO window that is still too small.

GPU-P is the sharing path and requires Windows Server 2025 or newer in the cited deployment scope. The troubleshooting page's list of GPUs that support it, "at this time," is NVIDIA A2, A10, A16, A40, L2, L4, L40, and L40S. A100 and H100 are not on that list. Only one GPU partition can be assigned to a virtual machine, and the partition and the virtual machine must be on the same host. The guest is Generation 2. Live migration needs the driver from NVIDIA vGPU software 18.x or later and a licence that includes GPU-P. NVIDIA's datacentre driver and the vGPU driver do not replace each other: the page says to remove the datacentre driver before installing vGPU software. Get-VMHostPartitionableGpu is the check that the host can see a partitionable GPU. The same physical GPU cannot be in DDA and GPU-P at once.

What to choose and why

The check is the same on each platform. The guest driver binds, the MMIO window matches the documented rule for the cards attached, and the virtual machine was not made to start by disabling interrupt remapping or by an ACS override.

Risks and limits

• Passthrough and live migration are different features. GPU-P's live migration is not a property of DDA. Dynamic DirectPath's HA restart is not vMotion.
• Clustered DDA is version-specific. The newer clustered-VM guide supports Windows Server 2025 Datacenter GPU pools and failover restart under its prerequisites. It does not add DDA live migration.
• allow_unsafe_interrupts and pcie_acs_override weaken the isolation the IOMMU is there to provide. The Proxmox wiki says so. They are not a fix to carry into a shared server.
• Full memory reservation removes overcommit on ESXi once a PCI device is attached, and dynamic memory is off for Hyper-V DDA. Size the host as if those guests are pinned.
• Firmware update from the guest can affect the whole machine. That is Microsoft's warning, and the reason a forced security-check bypass is not a routine deployment step.
• AMD reset and NVIDIA's consumer-card policy are device-specific. The Proxmox wiki's "reported working" list is not a support matrix. A card absent from Microsoft's GPU-P list is not partitioned by that feature.
• The Proxmox page used here is the wiki of examples, not the product manual's step-by-step. Prepare any VM or kernel change against the manual for the exact Proxmox VE release.
• No command was run. Dismount, blacklist, and MMIO changes are disruptive. No NetLeverage hypervisor or GPU assignment is described.

Sources

1. Broadcom, Direct Path GPUs Compute Model, VCF 9.1 — https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/design/design-library/private-ai-compute-detailed-design(1)/direct-path-io-gpus-compute-model.html (opened 10 November 2026). Exclusivity, no vMotion, HA and DRS only at power-on for Dynamic DirectPath, no extra GPU licence, NVLink requirement.
2. Broadcom, Common Design Requirements for vGPUs and DirectPath GPUs, page last updated 5 November 2026 — https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/design/design-library/private-ai-compute-detailed-design(1)/common-design-requirements-and-recommendations-for-both-vgpus-and-passtrough-gpus-9-x.html (opened 10 November 2026). VT-d, above-4 GB, EFI, full memory reservation, and the MMIO power-of-two rule.
3. Proxmox VE wiki, PCI Passthrough — https://pve.proxmox.com/wiki/PCI_Passthrough (opened 10 November 2026). IOMMU, ACS, unsafe interrupts, 32 GB OVMF window, code 12, reset bug, driver 465 note.
4. Microsoft Learn, Deploy devices by using Discrete Device Assignment — https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/plan/plan-for-deploying-devices-using-discrete-device-assignment (opened 10 November 2026). Device classes, ACS, trusted-tenant warning, feature bans, default MMIO, SurveyDDA.
5. Microsoft Learn, Deploy graphics devices by using Discrete Device Assignment — https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/deploying-graphics-devices-using-dda (opened 10 November 2026). Stop action, example MMIO values, dismount and assign order.

6. Microsoft Learn, Troubleshooting guidance for Hyper-V GPU assignment, partitioning, and passthrough — https://learn.microsoft.com/en-us/troubleshoot/windows-server/virtualization/troubleshoot-hyper-v-gpu-assignment-partitioning-passthrough-issues (opened 10 November 2026). GPU-P versus DDA, the GPU list, Windows Server 2025 live migration, code 12.

7. Microsoft Learn, Use GPUs with Discrete Device Assignment in clustered VMs — https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/use-gpu-with-clustered-vm (opened 10 November 2026). Windows Server 2025 Datacenter GPU-pool prerequisites and failover restart without live migration.

This article was originally published on 10 November 2026.