PCI Passthrough Explained: NICs, Storage Controllers, and GPUs

For a while, PCI passthrough felt more glamorous in my head than it deserved.

A GPU inside a VM sounded powerful.
A dedicated NIC inside a guest sounded cleaner.
A storage controller handed straight to a virtual machine sounded more honest than another virtual disk.

All of that can be true.
It just is not the whole story.

What finally made PCI passthrough click for me was realizing that it is not mainly a performance trick. It is a hardware ownership decision. The moment a VM receives a real PCI device, the host stops abstracting that piece of hardware and starts stepping aside for it. That changes not only speed, but flexibility, portability, migration behavior, troubleshooting, and what kind of VM you are actually building.

That is why I think passthrough deserves to be explained as architecture, not as magic.

For the technical baseline below, I use Proxmox VE documentation and separate documented platform behavior from my own placement and operating recommendations.

PCI passthrough is direct ownership, not a better virtual device

This was the first mental correction that helped me.

In ordinary virtualization, Proxmox presents virtual hardware to the guest. The VM gets a virtual NIC, a virtual storage controller, a virtual GPU model, and so on. The host remains in charge of the physical devices underneath that abstraction.

PCI passthrough changes that relationship.

Instead of offering a virtual stand-in, the host exposes a real PCI device to the VM through VFIO and IOMMU isolation. The Linux kernel VFIO documentation describes this in security terms very clearly: modern IOMMUs exist so devices can be isolated from each other and from arbitrary system memory access, which is what makes secure direct assignment to virtual machines possible.

That means the guest is no longer using an imitation of the hardware.
It is using the hardware.

This has immediate consequences:

• the guest can often use the vendor’s native driver;
• the host usually cannot use that device at the same time;
• the VM becomes more dependent on that exact hardware path;
• the hardware can no longer be treated as a purely poolable cluster resource.

That is why passthrough feels so different from simply adding another virtual device in the Proxmox UI. It is not another abstraction layer. It is the partial removal of one.

The real unit of assignment is often the IOMMU group, not the single card you wanted

This is where many first passthrough plans stop looking simple.

The VFIO documentation explains that devices are the target of assignment, but isolation is not always available at the granularity of one single device. Device topology, multifunction hardware, and bridges without sufficient access-control isolation can all reduce that neat one-device-per-boundary fantasy.

That is why IOMMU groups matter so much.

In practice, the question is not only:

"Do I want to pass through this NIC or this GPU?"

It is also:

"What else lives in the same isolation group?"

The kernel VFIO documentation is blunt about this too: if an IOMMU group contains multiple devices, the group only becomes viable for VFIO-style use when the whole group situation is handled correctly. That is one reason passthrough planning sometimes becomes motherboard planning.

I think this is one of the least glamorous but most important truths in the whole topic.

The device you bought is only half the story.
The way the platform groups it is the other half.

Passthrough starts with platform support before it starts with Proxmox

The official Proxmox administration guide says the requirement plainly: for PCIe passthrough, the CPU and motherboard need to support an IOMMU. On x86, that means Intel VT-d or AMD-Vi.

That reminder matters because passthrough is not mainly a guest feature.
It is a platform capability.

If the firmware, chipset behavior, and IOMMU layout are wrong or limited, the prettiest VM plan in the world will not repair the lower layer. This is why I increasingly think of passthrough readiness as part of hardware selection itself, not merely as a feature you toggle after the machine is already in the rack.

The biggest tradeoff is usually flexibility, not raw speed

This was the second major correction for me.

People often talk about passthrough as if the main question is whether direct hardware access is faster or more capable than the virtual alternative.

Sometimes it is.
But the deeper question is what you give up.

The Proxmox documentation for live migration states this very clearly: PCI or USB devices that are passed through currently block live migration. That single sentence explains a huge amount.

Once a VM owns a real PCI device:

• the VM becomes harder to move between nodes;
• cluster flexibility drops immediately;
• maintenance windows become more specific;
• HA thinking becomes colder and more hardware-bound;
• replacement-node assumptions become less casual.

This is why passthrough changes the personality of a VM. It is no longer just “a workload that could run somewhere in the cluster.” It becomes “a workload that belongs on the node that owns this hardware relationship.”

That does not make passthrough bad.
It just makes it expensive in a different currency.

NIC passthrough makes sense when the guest needs to behave like a real network appliance

NIC passthrough is one of the easiest categories to understand conceptually.

If the guest is meant to behave like a firewall, router, packet appliance, or system that genuinely benefits from owning a physical network interface directly, passthrough can be very sensible. The guest sees the real adapter, can often use the native driver stack, and is no longer relying on the host bridge model for that path.

That can be cleaner than a more abstract design when the VM itself is supposed to be the network boundary.

But it also asks a hard question:

does the guest truly need a physical NIC, or would a well-designed virtual NIC attached to a clean Proxmox bridge already solve the problem?

That is where bridge design in Proxmox stays relevant. A lot of people reach for NIC passthrough when what they really need is better network architecture, VLAN planning, or cleaner bridge separation.

I think NIC passthrough is best when the VM is intentionally becoming an appliance, not when passthrough is being used to compensate for unclear host networking.

Storage controller passthrough is often more honest than disk-by-disk improvisation

This is one of the most practical passthrough cases in homelabs.

If a guest operating system or appliance is supposed to manage disks directly, especially in ways that depend on controller visibility, SMART behavior, or direct storage-stack assumptions, passing through the whole storage controller can be much cleaner than layering virtual disks on top of host-managed abstractions and pretending the guest still sees the same truth.

That is why storage-controller passthrough often feels more coherent than piecemeal disk tricks.

The guest is no longer being handed a curated imitation of storage.
It is being trusted with the controller itself.

But this is also where consequences become very real:

• the host gives up direct use of that controller;
• the disks behind it stop being ordinary Proxmox-managed host storage;
• recovery planning becomes more guest-specific;
• hardware replacement becomes more sensitive to controller compatibility.

I think storage passthrough is worth it when the storage logic genuinely belongs inside the guest. If it does not, I would rather let Proxmox stay the storage owner and keep the VM more portable.

GPU passthrough is the most visible example, but not the only important one

GPU passthrough gets the most attention because it is vivid.

People can picture gaming, desktop acceleration, CUDA, AI workloads, media workflows, and native vendor drivers inside the guest. The result feels dramatic because the hardware itself feels dramatic.

But the same architectural truth still applies.

Once the GPU belongs to the VM:

• the host stops treating it as shared infrastructure;
• the guest becomes tied to firmware and machine-type choices more carefully;
• boot behavior may matter more;
• migration flexibility drops;
• troubleshooting becomes more specific to that VM’s hardware story.

The Proxmox QEMU documentation notes that in most cases people move from SeaBIOS to OVMF only when they plan to use PCIe passthrough, and that the Q35 machine type may be desirable when passing through PCIe hardware because it provides a virtual PCIe bus. That is exactly the kind of detail that shows how passthrough reaches deeper than one device line in the config.

It starts influencing how the VM itself is modeled.

That is one reason I like linking this back to firmware choices in Proxmox. GPU passthrough is never only about the GPU.

It is about the whole guest layout that needs to host it cleanly.

PCI passthrough to a VM is not the same thing as device access inside an LXC

This distinction is worth saying plainly because it confuses a lot of people.

Passing a GPU or other device into an LXC usually means exposing selected device nodes while the host still owns the real kernel driver. Full PCI passthrough to a VM is different: the guest takes direct ownership of the PCI device through VFIO-style assignment.

These are different models with different tradeoffs.

That is why the article on GPU access for LXC containers should not be mentally merged with VM PCI passthrough. They may solve similar workload goals, but they do so with very different ownership boundaries.

Backup and restore planning should get stricter the moment passthrough enters the design

This is where the operational cost becomes easier to feel.

A fully virtual guest can often be thought of as a more movable, more generic unit. A passthrough guest is more exact. It may depend on a particular controller, a particular GPU path, a particular slot layout, or a particular node identity.

That means backup and recovery notes deserve more specificity:

• what hardware is required for the VM to come back fully;
• whether recovery on a different node is realistic;
• which hardware assumptions live outside the backup itself;
• whether a restore drill should explicitly include hardware validation.

That is one reason passthrough belongs in the same mental neighborhood as a restore drill. Backup files are not the whole recovery story when the workload also depends on hardware ownership.

My rule now is simple: use passthrough when the guest truly needs ownership, not when I merely want neatness

This is the shortest version of what finally clicked for me.

I reach for passthrough when:

• the guest needs direct control of the hardware to fulfill its real role;
• the virtual alternative materially changes the behavior I care about;
• I accept the loss of mobility and generic recoverability;
• the platform’s IOMMU layout actually supports the assignment cleanly.

I avoid passthrough when:

• I mainly want the setup to feel more advanced;
• the virtual device model is already good enough;
• the benefit is aesthetic rather than operational;
• the hardware dependency would make the VM more fragile than the workload deserves.

That framing has made the whole feature much easier to respect.

Conclusion

PCI passthrough in Proxmox is not just a way to make a VM stronger. It is a way to make a VM more specific. NICs, storage controllers, and GPUs all become more powerful in the guest when they are handed over directly, but they also become less abstract, less movable, and more dependent on the hardware reality of the node. That is why I think the most useful way to understand passthrough is not as a checkbox for advanced users, but as a deliberate trade between capability and flexibility.

FAQ

What does PCI passthrough actually do in Proxmox?

It gives a VM direct access to a real PCI device instead of presenting only a virtualized version of that hardware. In practice, the guest becomes the owner of that device path.

Why do IOMMU groups matter so much?

Because isolation is not always available per individual device. The VFIO model depends on IOMMU grouping, and sometimes the grouping around a device is what determines whether passthrough is practical.

Is PCI passthrough only useful for GPUs?

No. GPUs are the most visible case, but passthrough is also very relevant for NICs and storage controllers when the guest genuinely needs direct hardware control.

What is the biggest downside of PCI passthrough in Proxmox?

Often it is the loss of flexibility. Proxmox documents that passed-through PCI devices block live migration, which makes the guest more tied to the hardware of one node.

When should I avoid passthrough?

Avoid it when the virtual device model already solves the workload well enough and the main motivation is only aesthetic, experimental, or based on the feeling that direct hardware access must automatically be better.