A Passthrough Preflight for Proxmox: IOMMU, Boot Order, and Hardware Isolation

It's an ambitious and increasingly common Proxmox build: a GPU passed to one VM, the storage HBA passed to a TrueNAS VM, an LXC running an AI stack, and Docker workloads alongside — all on one box. It can work beautifully. It can also collapse on the next reboot when IOMMU groups shift, the host grabs a device you meant to pass through, or the boot order brings things up in the wrong sequence. The difference is a passthrough preflight: a stable failure model decided before apps depend on any of it.

IOMMU groups decide what you can isolate

Passthrough works at the granularity of IOMMU groups — you pass an entire group, not a single device. Before planning anything:

• Enable IOMMU (Intel VT-d / AMD-Vi) in BIOS and the kernel cmdline.
• List your groups and see what's actually separable. A GPU sharing a group with a controller you need on the host is a problem you want to find now, not after committing.
• If a device is stuck in a crowded group, that's a motherboard/slot reality to design around — sometimes moving a card to another slot regroups it.

Driver placement: bind passthrough devices to vfio early

The host and a guest can't both own a device. The reliable pattern is to bind passthrough devices to vfio-pci at boot, before the host's normal driver claims them:

• Blacklist the host driver for the GPU (e.g. the NVIDIA/AMD/i915 driver) so the host never grabs it.
• Bind the device IDs to vfio-pci via modprobe config.
• Make it persistent — the number-one passthrough failure is a setup that works until reboot because the binding wasn't made permanent, the same persistence trap as media GPU passthrough.

Boot order is part of the design

When several VMs/containers depend on each other, the order they start matters:

• A storage VM (TrueNAS with the passed-through HBA) must be up and exporting before VMs that mount its shares.
• A virtualized router must be up before anything that needs the network.
• Set VM start/shutdown order and delays in Proxmox so a cold boot reassembles the stack correctly instead of racing.

Keep a clear ownership map

The recurring danger with stacked passthrough is two things claiming one resource. Write down, explicitly:

• Which device is owned by the host, which by each guest (vfio).
• Which physical disks belong to TrueNAS (via the HBA) vs Proxmox — the one-owner-per-disk rule. Never half-virtualize a pool.

Have a recovery path for when passthrough breaks a boot

A bad vfio bind or a GPU the host now refuses to release can leave you without a console. Before you rely on it:

• Keep a way in that doesn't need the passed-through GPU (serial console, SSH, iKVM).
• Know how to boot with passthrough disabled to fix a misconfig.
• Make sure this fits your full-host disaster-recovery plan — a passthrough box is harder to rebuild blind.

Passthrough preflight checklist

• IOMMU enabled; groups listed and genuinely separable for what you're passing.
• Passthrough devices bound to vfio-pci at boot; host driver blacklisted; persistent.
• VM start order/delays set for storage → network → apps.
• Explicit device + disk ownership map; no shared/half-virtualized pools.
• Out-of-band access that survives the GPU being passed through.

Takeaway

Stacked passthrough on Proxmox fails on reboots, not on day one. Confirm your IOMMU groups isolate what you need, bind devices to vfio persistently, set a deliberate boot order, and keep a console that survives a bad bind. Build the failure model first and the powerful all-in-one box stays stable instead of becoming a reboot you're afraid to perform.