Native ZVM still does not have a clearly documented first-party PCIe passthrough workflow, so do not plan an LSI HBA VM around an assumed checkbox that may not exist. IceWhale originally said PCIe passthrough was long-term roadmap work; in 2026, a community ZVM-Extra module added VFIO-based PCIe passthrough, but it remains a community extension rather than core ZVM.
If HBA passthrough is mission-critical, Proxmox remains the more conventional host choice. If you want to stay on ZimaOS, validate IOMMU groups and the community extension in a test VM before putting important storage behind it.
What IceWhale Said in the Original Thread
In November 2025, IceWhale said PCIe passthrough was not planned in the short term but was listed on the long-term roadmap.
What Changed in 2026
The community ZVM-Extra module thread introduced PCIe passthrough via VFIO and IOMMU-group checks. IceWhale later acknowledged that the module addressed current ZVM gaps.
Community Support Is Not Native Support
ZVM-Extra sits alongside official ZVM and uses the same libvirt backend. It does not mean native ZVM has gained an officially documented passthrough UI or that every future ZimaOS update will preserve third-party extension behavior.
Check IOMMU Before Anything Else
dmesg | grep -Ei 'DMAR|IOMMU'
find /sys/kernel/iommu_groups/ -type lYour HBA must be in a safe IOMMU group that can be isolated without stealing critical host hardware.
An LSI HBA Is a High-Impact Device to Pass Through
Once bound to VFIO and assigned to the VM, the host should no longer use the controller's disks. Do not place the ZimaOS system disk or host-critical storage behind the same HBA.
Use Proxmox When Passthrough Is the Core Requirement
For TrueNAS, Unraid, or another storage VM that must own an HBA directly, Proxmox has a mature PCIe passthrough workflow and makes the architecture easier to reason about.
Keep ZimaOS as a Guest If Needed
You can run ZimaOS as a Proxmox VM for its apps/UI while letting another VM own the HBA. The current ZimaOS on Proxmox guide documents the current supported ZimaOS guest installation.
Test Reboot Persistence
A passthrough setup that works once can still fail after reboot if host drivers reclaim the device or extension metadata is not reapplied. Test cold boot, VM start/stop, and storage visibility before trusting production data.
The virtualization hardware guide covers the hardware constraints.
Back Up the VM Definition Before VFIO Changes
Save the VM XML/configuration and storage metadata before binding an HBA to VFIO. Device-binding mistakes can make a VM fail to start or remove the controller from host access until the next recovery step.
Check the Whole IOMMU Group
Do not pass a device merely because its PCI address appears in lspci. Inspect every function in the same IOMMU group and verify that isolating the group will not take away a host NIC, SATA controller, or another critical device.
Storage VMs Need a Recovery Plan
If TrueNAS or another guest owns the HBA, document how to recover that guest, its VM disk, and the passthrough configuration independently of the disks behind the HBA. Otherwise a host failure can make the storage pool inaccessible even when the data disks are healthy.
FAQ
Does native ZVM officially support PCIe passthrough now?
No clear first-party passthrough workflow was found in current official docs; the 2026 working path discussed publicly is a community extension.
Can ZVM-Extra pass through PCIe devices?
Its community documentation says yes via VFIO with IOMMU-group checks.
Should I pass an LSI HBA to a storage VM?
Only if the HBA can be isolated cleanly and the host does not depend on any disks behind it.
Is Proxmox easier for this?
Yes when PCIe passthrough is a core design requirement rather than an optional experiment.
