Proxmox GPU Passthrough: How to Set Up a GPU for a VM

Proxmox GPU passthrough assigns a physical PCIe GPU directly to one virtual machine, so the guest uses the device and its native driver instead of an emulated display adapter. The setup requires working IOMMU support on the host, a usable IOMMU group for the card, and the GPU attached to the VM as a PCI device.

This Proxmox GPU passthrough setup guide covers full GPU passthrough to a QEMU/KVM VM: one physical GPU dedicated to one VM.

If you want a concrete implementation after making that decision, Linuxcore’s Proxmox homelab setup guide walks through enabling IOMMU, loading VFIO modules, binding the GPU by PCI ID, and assigning the device to a VM.

Proxmox GPU Passthrough Requirements

One distinction matters before you start: VT-x (Intel) or AMD-V CPU virtualization is not the same thing as VT-d or IOMMU device remapping. The first lets the CPU run VMs; the second allows a PCI device to be safely assigned to one of them. A system can have one enabled and not the other.

Passthrough also ties the guest to this specific node’s hardware. A VM with a passed-through GPU is less portable than one built entirely from virtual devices. Keep the VM powered off while changing passthrough configuration, and don’t pass through the host’s only display adapter without another way to manage the box afterward.

Step 1: Enable IOMMU in BIOS/UEFI

The setting is usually labeled one of:

• Intel: VT-d, or “Intel Virtualization for Directed I/O”
• AMD: IOMMU, or AMD-Vi

Exact wording and menu location vary by motherboard vendor. Check the board’s manual if the setting isn’t under a Virtualization or Advanced CPU Configuration menu.

Enable VT-d on Intel systems or IOMMU/AMD-Vi on AMD systems in firmware first; this applies regardless of kernel version. On the Proxmox side, the Proxmox PCI(e) passthrough documentation states that AMD IOMMU is enabled by default, and that with recent kernels (6.8 or newer) the same is true for Intel CPUs. On older kernels, Intel needs intel_iommu=on on the kernel command line (next step).

Either way, verify the active state after boot rather than assuming the firmware setting or kernel default took effect.

Step 2: Verify IOMMU on the Proxmox Host

Confirm the platform actually reports IOMMU support:

The exact message varies by hardware and kernel, but you’re looking for confirmation that IOMMU, Directed I/O, or interrupt remapping is enabled. If there is no relevant output, check firmware settings, the kernel command line, and platform support in that order.

Determine how the host boots before editing anything. Don’t infer it from whether a particular file happens to exist. Start with Proxmox’s boot-tool status, which shows whether proxmox-boot-tool is configured and how its bootable ESPs are managed:

Current Proxmox installs can use systemd-boot or GRUB through proxmox-boot-tool, while older or migrated systems may use plain GRUB. The boot method depends on disk setup, firmware mode, and Secure Boot state at install time, so check rather than assume. See Proxmox’s Host Bootloader documentation for what each status output means.

• systemd-boot: edit /etc/kernel/cmdline (single line, space-separated parameters), then run proxmox-boot-tool refresh.
• GRUB: edit /etc/default/grub, adding the parameter to GRUB_CMDLINE_LINUX_DEFAULT, then run update-grub.

On kernels older than 6.8, add intel_iommu=on via whichever method applies. Separately and optionally, iommu=pt can enable IOMMU passthrough mode for devices that don’t require translated mappings, using identity mappings to reduce unnecessary translation overhead. It’s an optimization, not a requirement for Proxmox GPU passthrough, so don’t treat it as mandatory alongside the actual IOMMU enable setting.

Reboot, then confirm the parameter actually took effect:

Next, make sure the VFIO kernel modules are loaded. Current Proxmox documentation adds them to a file under /etc/modules-load.d/, for example /etc/modules-load.d/vfio.conf:

After editing, refresh the initramfs and reboot:

Confirm the modules loaded:

Step 3: Identify the GPU and Its PCI Functions

Find your card in the output and note its PCI address (like 01:00.0) and its vendor:device ID pair in brackets (like [10de:1381]). A discrete GPU commonly exposes more than one PCI function under the same address prefix, typically the VGA/3D controller itself plus an HDMI/DisplayPort audio controller, and sometimes an additional USB-C or serial-bus function on newer cards. Not every GPU has the same layout, so check what’s actually listed rather than assuming a fixed count.

Step 4: Check the GPU’s IOMMU Group

For Proxmox GPU passthrough, the IOMMU group matters as much as the card itself. IOMMU groups describe which PCI devices the platform can isolate from each other for DMA remapping. A GPU that shares an inseparable group with unrelated critical host hardware can make safe passthrough difficult without platform-specific workarounds. It is normal for a GPU to share a group with its own additional functions (like its HDMI audio device) or with its root port/bridge.

Check group membership through the Proxmox API rather than parsing /sys/kernel/iommu_groups/ by hand:

This lists PCI hardware along with IOMMU group information for each device.

If the GPU is grouped with something unrelated that must stay on the host, first try another PCIe slot. Some boards group physical slots differently at the chipset level, so try another slot before reaching for anything more invasive.

Step 5: Prepare the GPU for VFIO Passthrough

Before Proxmox GPU passthrough can work, the host must release the card. Proxmox VE tries to make a passed-through PCI device unavailable to the host automatically. If the host still claims the GPU, use lspci -nnk to identify the active driver, then reserve the device with vfio-pci or blacklist only the conflicting host driver as needed.

Look at the Kernel driver in use line for your GPU’s entry. If manual intervention is needed, two common approaches are:

Bind by vendor/device ID: add a file under /etc/modprobe.d/:

using the ID pairs from lspci -nn (include the GPU’s other functions, like its audio device, alongside the main ID). If the host contains multiple identical devices with the same vendor/device IDs (two of the same GPU, for example), ID-based binding can capture more than the one card you intended to pass through; verify the affected devices before making the binding persistent.

Blacklist the host driver: do this only for the specific driver actually bound to this card, not every GPU driver on the system as a matter of habit:

Don’t blacklist nouveau, nvidia, amdgpu, or i915 by default. Only detach the driver that’s actually claiming the specific device you’re passing through, and only if it’s needed. Refresh the initramfs and reboot after either change, then re-check with lspci -nnk: the device should now show vfio-pci as the kernel driver in use, or no driver listed at all.

Step 6: Add the GPU to the Proxmox VM

Add GPU in the Proxmox GUI

VM → Hardware → Add → PCI Device, then select the GPU from the list. Relevant options, applied only when they fit your situation:

• PCI-Express: passes the device as a PCIe device rather than legacy PCI; only available with the q35 machine type.
• All Functions: passes every PCI function under the device’s address together (equivalent to the shorthand address syntax on the CLI side).
• Primary GPU: marks this device as the VM’s primary display adapter.
• ROM-Bar: makes the device’s firmware ROM visible to the guest; leave it at the default unless a specific card needs it disabled.

Don’t enable every checkbox by default. Match the options to what your card and guest OS actually need. All Functions is convenient when the guest needs the GPU’s related audio/USB functions.

One narrow exception applies to compute workloads that depend on PCIe AtomicOps, such as some AMD ROCm multi-GPU setups. QEMU has historically not advertised AtomicOps for devices passed through as a multifunction set, and that behavior depends on the QEMU version your node runs. Ordinary display passthrough does not depend on it. If your workload does, pass the GPU function explicitly and verify AtomicOps support inside the guest.

Add GPU with qm / hostpci

For example, a card at address 02:00.0 set as the VM’s primary display:

pcie=1 requests PCIe rather than legacy PCI (q35 only); x-vga=1 marks it primary. This example passes the GPU’s main function explicitly rather than the shortened 02:00 form. Use the specific function unless the guest driver needs the card’s other functions (like its audio device) passed together, in which case the shortened all-functions address is the simpler choice. PCI addresses here are illustrative; use the one from lspci -nn on your own host.

Q35, OVMF, and PCIe

For Proxmox GPU passthrough specifically, Proxmox’s own documentation points to the q35 machine type with OVMF (UEFI) firmware and PCIe rather than legacy PCI as the combination with the best documented compatibility. OVMF requires a GPU with a UEFI-capable ROM; if the card’s ROM isn’t UEFI-capable, use SeaBIOS instead. If using Windows 11 as the guest, follow current Proxmox guidance for Windows 11 VMs generally (TPM, UEFI) alongside the passthrough-specific settings here.

Step 7: Install the GPU Driver Inside the Guest

The driver goes inside the guest, not on the host. This is the opposite of NVIDIA vGPU, where the host needs a vendor driver too.

• NVIDIA: install the standard driver for the card and guest OS from NVIDIA’s official downloads.
• AMD: install the standard driver from AMD’s official support site.
• Intel: install the driver appropriate to the specific device and guest OS.

Boot the guest, confirm it detects the physical card, and install the driver as you would on bare metal.

Verify Proxmox GPU Passthrough Is Working

Windows guest: check Device Manager for the GPU with no driver error, and Task Manager’s GPU tab for activity. nvidia-smi works inside an NVIDIA guest where supported.

Linux guest:

confirms the guest sees the physical device and which driver has claimed it.

The actual success criterion is the same in either guest: the physical device is visible, the correct driver is active, and the intended workload can use the GPU. Seeing the device in a list alone is not enough.

NVIDIA vs AMD vs Intel GPU Passthrough

The mechanism is the same PCIe/VFIO path for all three vendors. Steps 1-7 above apply unchanged; the differences are in guest driver setup and model-specific quirks, not a fundamentally different Proxmox configuration.

NVIDIA GPU Passthrough in Proxmox

NVIDIA GPU passthrough in Proxmox uses the same IOMMU, VFIO, and hostpci workflow as any other card. Two things are specific in practice:

• Multiple PCI functions. Most NVIDIA cards expose at least the GPU and an HDMI/DisplayPort audio function, and some newer cards add USB-C or serial-bus functions. Capture all of them in Step 3, and include their IDs if you bind by vendor/device ID in Step 5.
• Code 43 in Windows guests. Older consumer drivers refused to run when they detected a hypervisor, which produced Code 43 and a long tail of hiding workarounds. Proxmox’s PCI Passthrough wiki page notes that VM detection “should no longer be an issue with Nvidia drivers 465 and newer,” so start with a current driver before applying any old fix.

Install the standard NVIDIA driver inside the guest, then confirm with nvidia-smi in both Windows and Linux guests. Windows and Linux guests do not need different Proxmox-side configuration for ordinary full-device passthrough.

AMD GPU Passthrough in Proxmox

Proxmox GPU passthrough with an AMD card follows the same core workflow. The AMD-specific issue worth knowing is reset behavior: some AMD cards do not reset correctly after the VM is stopped or rebooted, so the card works on the first VM start and fails on the next one until the host reboots. This is model-specific, not universal across AMD GPUs. For affected cards, Proxmox’s PCI Passthrough wiki page points to the community vendor-reset patch; check whether your specific model is affected before adding it.

Intel and Integrated GPU Passthrough

Discrete Intel GPUs follow the standard workflow above. Integrated GPU passthrough is different in practice: it is more dependent on the platform, CPU generation, and firmware than discrete-card passthrough, and the iGPU is often the device the host is using for its own console. Before passing an iGPU through, make sure the host has another management path (see Proxmox host loses local display below), and expect more per-platform variation than with a discrete card.

Proxmox GPU Passthrough Troubleshooting

IOMMU not detected

Recheck BIOS/UEFI settings, confirm the correct bootloader file was actually edited (Step 2), reboot, and re-run the dmesg check. Also check journalctl -b around boot time for anything platform-related that might explain a missing feature.

GPU doesn’t appear in Add PCI Device

Confirm lspci still sees the card at the expected address, that IOMMU is actually enabled (not just configured), and that you’re looking at the correct node if managing a cluster from a different member.

VM fails to start after adding the GPU

Check the Proxmox task log and the underlying QEMU error message first; it usually names the actual problem. Common causes: the IOMMU group isn’t cleanly isolated, the host driver or another VM still owns the device (recheck lspci -nnk from Step 5), not all of the card’s required functions were assigned together, or the VM’s machine/PCIe configuration doesn’t match what the device needs. If the VM starts once but fails after a guest reboot or stop/start, a card-specific reset problem is a stronger suspect (see the AMD note above). The VM won’t start troubleshooting guide and Proxmox logs guide cover reading these errors in more depth.

GPU shows a driver or device error in Windows

Check the guest driver version, the device’s state in Device Manager, and the VM’s firmware/machine configuration and passthrough options. Some specific NVIDIA consumer-driver combinations have historically shown a Code 43 error tied to hypervisor detection; verify current driver behavior for your specific driver version before applying any workaround, rather than assuming an old fix still applies (see the NVIDIA section above).

Black screen after passing through the GPU

A blank Proxmox console is not automatically a failed passthrough. Work through, in order: the VM may simply be running with display output now routed to the physical GPU rather than the Proxmox console (expected); the guest driver or device may genuinely have failed (check guest-side logs/Device Manager); the physical output might be unavailable due to cabling, a sleeping monitor, or the wrong input selected; or remote access into the guest wasn’t set up before the card became primary, leaving no way to see it.

Proxmox host loses local display

This is expected if you pass through the host’s only GPU. Make sure another management path works first. The host remains manageable through the web UI, SSH, or IPMI/iKVM where available; if none of those are already working, set them up before removing local display access. If out-of-band management isn’t in place yet, the Proxmox networking guide covers getting remote access working first.

GPU Passthrough in a Proxmox Cluster

A passed-through GPU is physical hardware on one specific node, so the VM is less portable than one built purely from virtual devices. Device availability and hardware compatibility both matter for migration or failover, not just compute capacity.

Resource mapping. Proxmox’s cluster-wide resource mapping gives a device a cluster-unique name that can point to equivalent hardware on different nodes, even at a different PCI address. That helps prevent HA from starting a guest against the wrong device after a hardware or address change.

Migration. Ordinary Proxmox GPU passthrough should not be assumed to support live migration. With resource mapping, a VM can be moved offline between nodes that provide a compatible mapped device.

Experimental live migration. Proxmox also has an experimental option for PCI mappings marked live-migration-capable. It requires driver and hardware support, and Proxmox’s documentation notes that only NVIDIA GPUs with recent kernels are known to support it. Treat it as a special case, not a general GPU passthrough capability.

For broader HA design, see Proxmox HA cluster requirements for how passthrough devices fit into a cluster.

GPU Passthrough vs vGPU vs LXC GPU Access

Setup steps for vGPU and LXC GPU access are out of scope because each uses a different mechanism.

FAQ

Does Proxmox support GPU passthrough?

Yes. Proxmox GPU passthrough works through PCI/PCIe host device passthrough, provided the host platform supports IOMMU (Intel VT-d or AMD IOMMU).

How do I enable GPU passthrough in Proxmox?

Enable IOMMU in firmware, verify it on the host, identify the GPU and check its IOMMU group, free the device from the host driver for VFIO, add it to the VM as a PCI device, then install the native driver inside the guest.

Do I need IOMMU for Proxmox GPU passthrough?

Yes. Proxmox GPU passthrough needs IOMMU, called VT-d on Intel platforms and IOMMU (or AMD-Vi) on AMD platforms: different vendor names for the same underlying requirement.

Do I need VFIO for GPU passthrough?

VFIO is the kernel framework that actually hands the device to the VM safely, so yes, though on many current systems Proxmox handles the module loading and binding automatically, and you only need to intervene manually when the host’s own driver has already claimed the card.

Should I use Q35 for Proxmox GPU passthrough?

For most GPU passthrough setups, yes. Proxmox documents q35 with OVMF and PCIe as the combination with the best compatibility, especially when the device needs PCIe behavior. It isn’t an absolute requirement: a card without a UEFI-capable ROM needs SeaBIOS, and other passthrough use cases (like a simple NIC) may not need q35 at all.

Can I pass an NVIDIA GPU through to a Proxmox VM?

Yes, given IOMMU support and a compatible IOMMU group, with the standard NVIDIA driver installed inside the guest.

Can I pass an AMD GPU through?

Yes. It uses the same underlying mechanism; check for model-specific reset behavior if you run into issues on a particular card.

Can I pass an Intel integrated GPU through?

Sometimes, but iGPU passthrough is more platform- and generation-dependent than discrete-card passthrough, and often competes with the host wanting to use the same GPU for its own console output.

Why is the Proxmox console black after GPU passthrough?

A black Proxmox console may simply mean display output has moved to the physical GPU. Once a monitor or remote desktop session inside the guest is available, a blank virtual console by itself does not mean passthrough failed.

Can one GPU be passed through to multiple VMs?

Not with ordinary full-device PCI passthrough at the same time. One physical GPU goes to one VM. Sharing a card across VMs needs vGPU/mediated devices or GPU partitioning instead.

Can I live migrate a VM with a passed-through GPU?

Ordinary PCI/GPU passthrough should not be assumed to support live migration. With cluster resource mapping, a VM can be moved offline between nodes that provide a compatible mapped device. Proxmox also has an experimental live-migration option for PCI mappings marked live-migration-capable, but it requires specific driver and hardware support. Currently, only NVIDIA GPUs with recent kernels are known to support it, and it shouldn’t be treated as a general GPU passthrough capability.

Final Thoughts

Proxmox GPU passthrough follows a straightforward chain: IOMMU, an isolated group, a driver freed from the host, and a PCI device attached to the VM. Each step depends on the previous one working correctly. Most failures trace back to skipping verification at one of those steps rather than to passthrough itself being unreliable: IOMMU configured but not actually confirmed with dmesg, a driver still bound to the card, or a machine-type setting that doesn’t match what the GPU needs.

Verify each stage before moving to the next, keep a management path to the host that does not depend on the GPU you’re about to hand to a VM, and treat vendor-specific quirks as specific to that vendor and model rather than universal rules for every passthrough setup.