Proxmox HBA Passthrough: ZFS, TrueNAS and IOMMU Guide

PCIe passthrough architecture

Proxmox HBA Passthrough: ZFS, TrueNAS and IOMMU Guide

Passing an entire HBA to a storage VM can give TrueNAS or another guest direct control of the controller and attached disks while Proxmox remains the hypervisor. The design is clean when the HBA sits in an isolated IOMMU group, the host boot device is elsewhere, and no Proxmox storage depends on that controller. It becomes fragile when the host and guest both expect access to devices behind the same PCIe function.

Quick answer

When should you pass through the whole HBA?

Use whole-controller passthrough when a storage VM should own the physical pool and you want the guest to see the disks through the actual controller. Keep the Proxmox boot drive and any host-managed datastore on separate hardware. If the host needs disks on the HBA, do not hand that controller to the VM. The architecture should have one clear owner per physical storage path.

Live Amazon hardware

Current controllers, cables and storage devices for this decision

These listings come from Sprint 4B's dedicated catalogue. HBA generations, connector families, breakout cables, cooling hardware and enterprise SSD candidates are separated. A marketplace phrase such as “IT mode” is treated as listing evidence, not proof of firmware state.

Checking the dedicated Proxmox HBA & Expansion catalogue…

Buying decision

IOMMU isolation is the gatekeeper

The HBA must be available for PCIe passthrough and should not be grouped with host-critical devices that you cannot safely bind away from Proxmox. Motherboard firmware, CPU support and slot topology all matter. Verify grouping before buying a controller solely for passthrough.

Interactive decision tool

Proxmox HBA Passthrough Planner

Use this planner to screen controller class, ports, PCIe bandwidth, passthrough ownership, ZFS cache/allocation-device roles or expansion headroom before buying hardware. Results are planning guidance, not a substitute for motherboard lane/IOMMU documentation, exact HBA firmware verification, current OpenZFS behavior or independent backups.

Compatibility checklist

Four checks before adding an HBA or expanding storage

Decide who owns the disks

Proxmox-owned ZFS and a TrueNAS VM passed an entire HBA are different architectures. Do not let both layers manage the same disks.

Match ports and connectors

Count final drive lanes and verify SFF-8087, SFF-8643, backplane and breakout-cable direction before ordering.

Check PCIe lanes and IOMMU

A full-length slot may run electrically at fewer lanes. Passthrough also depends on platform IOMMU support and usable isolation.

Plan cooling and recovery

HBAs need airflow, and more attached disks increase the data you must protect with an independent backup and documented replacement map.

01

Define host storage before enabling passthrough

Proxmox must be able to boot and operate without the controller you intend to pass through. Put the hypervisor boot drive on motherboard SATA, NVMe or a separate controller and make sure local logs, ISOs and recovery tools do not depend on the HBA.

This separation means the VM can be stopped, reinstalled or moved without taking the hypervisor with it. It also prevents the common mistake of assigning an HBA to a guest and then discovering that the host root filesystem or a critical datastore disappeared.

02

Enable IOMMU at firmware and kernel levels

PCIe passthrough depends on platform IOMMU support. Intel systems normally expose VT-d terminology while AMD platforms use IOMMU naming. The firmware setting alone is not the entire configuration; the running Proxmox kernel must also enumerate devices through the IOMMU path.

After enabling it, inspect groups rather than assuming that every slot is isolated. Board design, chipset lanes and ACS behavior determine which devices are grouped together.

03

IOMMU groups determine whether the HBA is safely separable

A controller grouped with unrelated host-critical hardware is a warning sign. Passthrough should not require binding away the NIC that provides management access or another device the host needs.

Moving the HBA to another physical slot can change grouping because different slots may route through different root ports. This is why slot choice belongs in the storage plan, not only in the final assembly step.

04

Pass the controller, not a RAID virtual disk

If the storage VM is meant to manage ZFS, giving it a hardware RAID volume defeats much of the reason to pass through a controller. The guest should see the underlying disks and their identities through a direct-attached HBA.

Confirm that the controller presents disks directly and that SMART/health information is visible in the guest. A seller claim of IT mode is not enough; validate the actual delivered board and firmware.

05

Do not split one controller between host and guest

PCIe passthrough assigns the function to the VM. The Proxmox host should not simultaneously rely on disks behind that same controller. Mixed ownership creates confusing failure modes during boot, VM restart and controller reset.

If you need host-managed disks and guest-managed disks, use separate controllers or keep one storage stack responsible for all disks behind the HBA.

06

Map every disk and cable before the VM goes live

Record HBA port, breakout leg, bay number and disk serial. This makes replacement deterministic when the storage VM reports a failed drive.

Without a map, a storage alert can turn into manual cable tracing inside a running chassis. A simple spreadsheet or printed bay map is one of the highest-value reliability steps in a multi-disk build.

07

Controller reset behavior matters

Some PCIe devices reset more cleanly than others when a VM stops and starts. Test a full guest shutdown and restart cycle before placing important data on the passed-through pool.

Also test a host reboot. The HBA should initialize predictably, remain bound to the intended driver path, and return to the storage VM without manual intervention.

08

Backups should survive a storage-VM failure

A storage VM is a convenient consolidation pattern, but it adds a dependency: the guest must run before its exported storage is available to other workloads. Keep backups on a path that does not require the same VM and same HBA to be healthy.

For example, a separate NAS, removable backup or Proxmox Backup Server target can preserve recovery options when the storage VM configuration or controller itself is the problem.

09

Consider migration and HA limits

A VM with a passed-through physical HBA is tied to hardware with an equivalent device arrangement. Normal live migration expectations no longer apply in the same way because another node would need a compatible controller and physical disks.

This is acceptable for a single-node home server, but it should be explicit in clustered designs. Hardware passthrough improves direct control at the cost of portability.

10

Cooling remains part of passthrough reliability

Passing a controller to a VM does not change its thermal needs. The card still sits in the Proxmox chassis and needs airflow.

Because storage VMs can keep an HBA busy during scrubs, replication and resilvers, test temperatures under sustained activity rather than only at idle.

11

Use stable PCI addresses and configuration records

Document the PCI address and controller identity used in the VM configuration. Firmware updates, slot changes or added devices can alter enumeration, so verify the mapping after hardware changes.

A recovery note should state which VM owns the HBA, which slot it occupies, which disks are attached and where the host boot storage lives.

12

Test recovery before trusting the design

Simulate the events that matter: storage VM shutdown, host reboot, one disk replacement and a controller-free host boot. Confirm that Proxmox management remains available and that the storage VM sees the expected disks after each event.

The best passthrough design is one whose failure path you have already practiced. Hardware isolation is only useful when the operating procedure is equally clear.

Questions people ask

Proxmox HBA Passthrough questions

Is whole-HBA passthrough better than passing individual disks?

For a storage VM that should own ZFS, whole-controller passthrough is often cleaner because the guest sees the actual controller and all attached disks. Individual disk mapping can still work, but it adds another host translation layer.

Can Proxmox boot from the HBA I pass through?

It should not. Keep the Proxmox boot device on storage that remains owned by the host.

Do I need IOMMU for HBA passthrough?

Yes. PCIe passthrough relies on IOMMU support and usable device grouping.

Can the host and TrueNAS share one HBA?

Not as a clean PCIe passthrough design. Give the controller to one owner and use another path for host-managed disks.

Will passthrough work on every motherboard?

No. CPU, firmware, slot routing and IOMMU grouping can make one board much easier than another.

Does the HBA need IT mode?

The storage VM should see individual disks directly. Verify actual firmware behavior and disk visibility on the delivered card.

Can I live-migrate a VM with an HBA passed through?

Physical passthrough ties the guest to hardware, so normal migration flexibility is reduced and equivalent hardware would be required on the target.

Should I passthrough a 9207-8i or 9300-8i?

Either can work. Choose by drive media, cabling, backplane and bandwidth; passthrough itself does not require SAS3.

Can I passthrough an HBA to an LXC container?

This page is about PCIe device passthrough to a VM. Container device access follows a different security and device-mapping model.

What should I test before putting data on the pool?

Test host boot without the HBA, VM shutdown/start, host reboot, disk visibility, SMART access and one documented replacement path.

Official references and methodology

Verify controller, passthrough and OpenZFS behavior before deployment

Passthrough guidance is based on Proxmox PCIe isolation concepts and direct-controller ownership. Hardware recommendations are constrained by port count, connector family and live marketplace evidence. The page does not assume that a motherboard has safe IOMMU grouping until the user verifies it.

As an Amazon Associate, Cloudzat may earn from qualifying purchases. Prices, seller claims, controller firmware, IT-mode status, exact board revisions, cable direction, enterprise SSD features and marketplace conditions can change. Verify the exact delivered hardware before deployment.

Scroll to Top