Proxmox GPU Passthrough Guide: A Low-Drama VFIO Workflow for Clean VM Access to a GPU

Disclosure: This article contains affiliate links. If you purchase through these links, HomelabAddiction may earn a commission at no additional cost to you.

Documentation basis: This guide is grounded in the Proxmox PCI passthrough documentation, the Proxmox QEMU/VM documentation, and the Linux kernel VFIO documentation. The workflow below is organized around documented verification checkpoints rather than folklore-driven copy-paste sequences.

Proxmox GPU passthrough goes more smoothly when the workflow is treated as a sequence of verifiable checkpoints: confirm the boot path, make sure IOMMU is really active, inspect grouping, bind the device to VFIO, then move into guest firmware and driver work.

Most failed passthrough attempts are not exotic. They usually come from the host still claiming the GPU, an incomplete device pair, the wrong guest machine type, or hardware grouping that was never checked before edits started.

This guide keeps the order documentation-led so each stage can be proven before the next one adds more variables.

Key Takeaways

• Proxmox GPU passthrough is easiest when the host keeps an iGPU or alternate console path and the guest receives the discrete GPU.
• Check whether the host uses GRUB or systemd-boot before editing kernel parameters or rebuilding the boot path.
• IOMMU grouping and VFIO ownership should be verified before guest tuning, driver troubleshooting, or ACS override experiments.
• q35, OVMF, the GPU audio function, and a realistic HA expectation are the baseline checks that prevent most low-value detours.

When GPU passthrough is the right fit

In a homelab, GPU passthrough makes sense when a VM needs real hardware acceleration instead of whatever fake video adapter QEMU gives it.

That usually means one of four jobs:

1. A Windows VM for gaming or CAD.

2. A Linux VM for AI workloads, CUDA, or local inference.

3. A media VM doing hardware transcoding.

4. A workstation VM you want to feel close to bare metal.

If the real goal is only media transcoding, full VM passthrough may be unnecessary. An LXC container with an iGPU or a simpler device-mapping path can be easier to maintain when the guest does not need near-native direct access to a discrete card.

Choose the least painful hardware path first

This matters more than any kernel flag.

Best path: iGPU for the host, discrete GPU for the guest

This is the cleanest setup by far.

The Proxmox host keeps local console output through integrated graphics, while the VM gets the dedicated card. You still manage the host through the web UI and SSH, but you are not one boot mistake away from blind recovery.

A host CPU with usable integrated graphics often makes passthrough easier because the Proxmox host can keep local console access while the guest claims the discrete GPU.

Acceptable path: headless host, discrete GPU for the guest

This works fine if you are comfortable treating the Proxmox host like a headless server.

Just be honest with yourself before you start. If you rely on plugging a monitor into the box every time something goes sideways, this path is going to teach you new vocabulary.

Worst path: one GPU expected to serve host and guest cleanly

You can find threads where people try to make this work elegantly.

Single-GPU passthrough can work, but it is usually the less forgiving path. If the hardware budget allows, keeping the host on an iGPU or secondary adapter reduces recovery friction.

Before you touch Proxmox, check the BIOS

You need these features enabled:

• Intel VT-d or AMD-Vi / IOMMU
• CPU virtualization support (VT-x or SVM)
• Above 4G Decoding enabled
• CSM disabled if your hardware behaves with pure UEFI

Resizable BAR can also complicate passthrough on some combinations of hardware, firmware, and guest drivers.

If you get weird BAR allocation errors later, disable ReBAR first before you start rewriting half your config. It is one of those settings that feels modern and helpful right until it is not.

Figure out your bootloader before editing kernel parameters

This is the first place many guides get lazy.

Some Proxmox hosts use GRUB. Others use systemd-boot, especially on newer installs. If you edit the wrong place, nothing changes, you reboot confidently, and the machine ignores you with impressive professionalism.

Check what you are using

bootctl status

If bootctl shows active entries, you are likely on systemd-boot.

If not, GRUB may be the path. On many systems, checking whether /etc/kernel/cmdline exists is also a useful clue.

Enable IOMMU on the host

If you are using GRUB

Edit /etc/default/grub.

For Intel:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"

For AMD:

GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt"

Then apply it:

update-grub\nreboot

If you are using systemd-boot

Edit /etc/kernel/cmdline and append the correct IOMMU flags to the existing line.

Intel:

intel_iommu=on iommu=pt

AMD:

amd_iommu=on iommu=pt

Then refresh the boot entries and reboot:

proxmox-boot-tool refresh\nreboot

Verify it actually worked

After the host comes back:

dmesg | grep -E 'DMAR|IOMMU|AMD-Vi'

On Intel, you want to see something like DMAR: IOMMU enabled.

On AMD, you want AMD-Vi messages showing the IOMMU came up correctly.

Also verify interrupt remapping:

dmesg | grep remapping

If interrupt remapping is missing, passthrough is already on shaky ground.

Load VFIO modules

Add the required modules to /etc/modules:

vfio\nvfio_iommu_type1\nvfio_pci

Then rebuild initramfs and reboot:

update-initramfs -u -k all\nreboot

Some older guides still tell you to add vfio_virqfd. On newer kernels, that advice is often stale. This is why blindly following old passthrough posts is a hobby inside the hobby.

Check IOMMU groups before you do anything clever

This is the checkpoint that tells you whether your motherboard is going to behave like a grown-up.

Run:

for d in /sys/kernel/iommu_groups/*/devices/*; do\n  g=${d#*/iommu_groups/*}\n  g=${g%%/*}\n  echo "IOMMU Group $g"\n  lspci -nns "${d##*/}"\n  echo\n done

You want the GPU and its audio function grouped together, ideally without a pile of unrelated junk attached.

A healthy example looks something like this:

IOMMU Group 17\n01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:xxxx]\n01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:yyyy]

When mixed IOMMU groups need extra care

On some consumer boards, the GPU can share a group with devices such as USB or SATA controllers. That is the point to pause and validate firmware updates, alternate slots, and motherboard lane layout before using ACS override.

ACS override is a fallback, not proof that the underlying grouping is healthy.

When to use ACS override

If your grouping is bad and you have exhausted firmware updates, BIOS options, and slot changes, ACS override can help:

pcie_acs_override=downstream,multifunction

But treat it as a workaround, not as best practice.

It weakens isolation. For a lab, you may accept that tradeoff. For anything you pretend is production, think twice.

Identify the GPU and audio device IDs

List your PCI devices:

lspci -nn | grep -Ei 'vga|3d|display|audio'

You are looking for both the GPU and its companion audio function.

Example:

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU117 [10de:1fb2]\n01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:10fa]

Those bracketed IDs are what you bind to VFIO.

Bind the GPU to VFIO before the host grabs it

Create /etc/modprobe.d/vfio.conf:

options vfio-pci ids=10de:1fb2,10de:10fa disable_vga=1

Replace those IDs with your own.

If the host is still grabbing the card, blacklist the native drivers.

For NVIDIA, that often means:

blacklist nouveau

For AMD, you may need to keep the host from binding amdgpu if the card is supposed to belong exclusively to the guest.

Then rebuild initramfs and reboot again:

update-initramfs -u -k all\nreboot

Verify VFIO owns the device:

lspci -nnk -d 10de:1fb2

You want to see:

Kernel driver in use: vfio-pci

If you still see nouveau, nvidia, or amdgpu, stop there. Do not move on to VM configuration yet. Passthrough fails fast when the host never actually gave up the card.

Build the VM with settings that do not sabotage you

Use these defaults unless you have a reason not to:

• Machine: q35
• BIOS: OVMF (UEFI)
• CPU type: host
• Display: none or a non-primary virtual adapter if the passthrough GPU is the real display target
• Memory ballooning: disabled for consistency

In the Proxmox UI, add the GPU as a PCI Device and pass all functions if the GPU audio device is paired with it.

If you prefer editing the config directly, the VM file at /etc/pve/qemu-server/VMID.conf ends up looking roughly like this:

bios: ovmf\nmachine: q35\ncpu: host\nhostpci0: 0000:01:00,pcie=1,x-vga=1

For some cards, you may also need a second passthrough line for the audio function if you are not using the all-functions toggle.

If the passthrough GPU is supposed to be the guest's main display, set the VM display thoughtfully. A lot of "black screen" reports are just the guest output going to the physical GPU while the admin keeps staring at noVNC like it personally offended them.

Windows guest notes

Windows is still the path where most people notice passthrough first, because it is the path where a broken driver setup complains loudly.

If you are building a Windows VM:

• Use OVMF.
• Keep the VM on q35.
• Install VirtIO drivers.
• Expect the real output to appear on the passed-through GPU, not in noVNC.

NVIDIA and Error 43

This is less common than it used to be on newer drivers, but it still shows up often enough to deserve its own paragraph.

If the guest sees the card but the NVIDIA driver throws Error 43, start with these checks:

• whether the host really bound the card to vfio-pci,
• whether the VM is using q35 and OVMF,
• whether the GPU audio function was included,
• whether the card needs a cleaner UEFI path or a ROM file,
• whether someone copied an old workaround that no longer applies.

On stubborn setups, hypervisor-hiding tweaks can still help, but only after the simpler checks are clean. In practice, incorrect VFIO binding, missing guest firmware settings, and incomplete device selection fail more often than exotic vendor quirks.

Code 12 and BAR errors

If you see Code 12 or BAR allocation issues, look at these in order:

1. Above 4G Decoding in BIOS

2. ReBAR disabled

3. OVMF in the guest

4. clean q35 machine type

5. whether the motherboard firmware is ancient and unhelpful

Linux guest notes

Linux guests often expose driver and device-state problems more directly than Windows guests, which can make early validation easier.

You still need correct driver support inside the guest, but once VFIO ownership and VM config are right, Linux tends to make its complaints in a more readable tone.

For compute workloads, verify from inside the VM with something basic first:

lspci -nn

Then vendor tooling:

nvidia-smi

or, for Intel and AMD stacks, the appropriate driver and render-node checks.

Homelab realities most guides skip

This part matters more than people admit.

Passthrough and high availability do not mix well

If a VM has a physical GPU attached, your life gets less portable.

Once a VM depends on a passed-through GPU, live migration and HA expectations usually need to be adjusted. If that is new territory, review the companion Proxmox cluster setup guide before promising mobility features the hardware path cannot provide.

Backups still matter, even if the workload is "special"

A passed-through GPU does not make the VM sacred. It just makes the restore plan more specific.

Back up the VM as if the host or guest disk could fail without warning. The companion Proxmox backup strategies guide covers the broader backup and restore posture.

Networking still matters

If the guest is doing streaming, AI, or remote desktop, network bottlenecks become much more visible once the GPU side is fast.

If bridges, VLANs, and firewall rules are still improvised, clean those up too. The related guides on Proxmox networking and homelab firewall rules pair well with this one.

Troubleshooting checklist in a low-drama order

When passthrough fails, work through this order:

1. Did BIOS settings stick? Check VT-d / AMD-Vi and Above 4G again.

2. Did the kernel parameters apply? Verify with dmesg.

3. Are IOMMU groups usable? If not, stop and solve that first.

4. Did VFIO actually claim the GPU? Confirm with lspci -nnk.

5. Is the VM using q35 + OVMF + host CPU? Fix the obvious config mismatches.

6. Was the audio function passed too? Forgetting this is very common.

7. Is the wrong display being checked? Use the physical GPU output if it is the primary guest display.

8. Only then start chasing vendor quirks, ROM files, or hidden hypervisor flags.

That order sounds unglamorous because it is unglamorous. It also saves a lot of wasted time.

Recommended gear if you are building around passthrough

None of the following hardware suggestions are mandatory, but they generally reduce friction instead of creating more debugging branches.

• Intel Core i5-14500 - a very practical host CPU if you want the Proxmox host on the iGPU and the VM on a discrete card: check price on Amazon
• Intel Arc A380 - a decent low-power option for media or lab workloads where AV1 support and modern transcode capability matter: check price on Amazon
• NVIDIA T400 - still one of the least ridiculous low-profile cards for compact homelab builds and light workstation use: check price on Amazon

These are not the only workable parts, but they tend to create fewer detours than bargain hardware chosen without checking IOMMU grouping, firmware maturity, or host-console needs.

The official docs you should keep open

Even if you follow this guide, keep the vendor references nearby:

• Proxmox PCI Passthrough wiki
• Proxmox admin guide - PCI(e) passthrough section
• Linux kernel VFIO documentation

Those are the references to check when you need exact wording on a passthrough error or the supported meaning of a given flag.

Final verdict

GPU passthrough on Proxmox is absolutely worth doing when the workload genuinely needs direct hardware access.

But it rewards clean planning more than brute-force troubleshooting. If you pick the right hardware path, verify every layer, and resist the urge to throw ACS override and mystery flags at the problem too early, it becomes very manageable.

If you do the opposite, it becomes one of those projects where you technically learn a lot but mostly about your own decision-making.

Frequently Asked Questions

Sources and verification

Last verified: 2026-07-31. This article was reviewed against the primary documentation listed below. Unsupported first-person or faux-tested framing was removed unless the claim was backed by a cited primary source.

• Proxmox PCI(e) Passthrough
• Proxmox VM hardware / PCI passthrough docs
• Linux kernel VFIO documentation