I want to use Proxmox as VM but Proxmox cant find iommu enabled, i own an Intel B50 and want to use its sriov until Unraid can do it. The devices are on their own groups inside Proxmox sooo is it a cosmetic error or what? Does anybody know ?

Right now the b50 sriov capability is Not not detected but it could be an Loser Firmware Update on the Card I did an Update inside an ein 11 VM but it was Late and you know I would try To Flash on something bare Metal again later. Should work

Regards dom

Edited November 7, 2025Nov 7 by domrockt

On 11/7/2025 at 9:11 AM, domrockt said:

I want to use Proxmox as VM but Proxmox cant find iommu enabled, i own an Intel B50 and want to use its sriov until Unraid can do it. The devices are on their own groups inside Proxmox sooo is it a cosmetic error or what? Does anybody know ?

Right now the b50 sriov capability is Not not detected but it could be an Loser Firmware Update on the Card I did an Update inside an ein 11 VM but it was Late and you know I would try To Flash on something bare Metal again later. Should work

Regards dom

to clarify you want unraid as host and proxmox as teh VM?

then you may need to add virtual IOMMU or use qemu arguments and pass host device iommu.

the best way to do this is add custom xml code the webui has an area now for cutom qemu aruments and commands...

*the important part: vIOMMU is real and required for nested passthrough, but “guest sees an IOMMU” and “nested SR-IOV actually works end-to-end” are not the same thing.

What you need is nested virtualization + a virtual IOMMU (vIOMMU) in the Proxmox VM. For QEMU/KVM, the Intel vIOMMU is only supported on a q35 machine, and for assigned devices it should be paired with caching-mode=on; for nested passthrough, interrupt remapping also matters, and libvirt notes that intremap='on' requires split I/O APIC. Proxmox’s own passthrough docs also explicitly say vIOMMU is what enables passing PCIe devices to level-2 VMs from a level-1 VM.

more info can be found here: https://www.qemu.org/docs/master/system/qemu-manpage.html

So if your goal is:

Unraid host (L0) → Proxmox VM (L1) → pass device/VF to a VM inside Proxmox (L2)

then “Proxmox can’t find IOMMU enabled” is not cosmetic. For that use case, the Proxmox guest really does need a vIOMMU exposed to it. If you are only passing a device directly from Unraid into the Proxmox VM and using it only inside that Proxmox VM, then the warning can be less important. But for nested passthrough / SR-IOV use inside Proxmox, it matters.

Also, nested KVM must be available on the Unraid host. Kernel docs say Intel nested virtualization is controlled by kvm-intel.nested, and modern kernels default it to enabled, though distros can override that; the guest CPU must also expose VMX rather than using a generic CPU model.

Use this as your libvirt domain XML basis for the Proxmox VM on Unraid:

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
  <name>proxmox</name>
  <memory unit='MiB'>16384</memory>
  <vcpu placement='static'>8</vcpu>

  <os>
    <type arch='x86_64' machine='pc-q35-8.2'>hvm</type>
  </os>

  <features>
    <acpi/>
    <apic/>
    <ioapic driver='qemu'/>
  </features>

  <cpu mode='host-passthrough' check='none'>
    <feature policy='require' name='vmx'/>
  </cpu>

  <devices>
    <emulator>/usr/local/sbin/qemu</emulator>

    <!-- vIOMMU for the Proxmox guest -->
    <iommu model='intel'>
      <driver intremap='on' caching_mode='on' iotlb='on' aw_bits='48'/>
    </iommu>

    <!-- Example virtio disk with iommu awareness -->
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' iommu='on'/>
      <source file='/mnt/user/domains/proxmox/vdisk1.img'/>
      <target dev='vda' bus='virtio'/>
    </disk>

    <!-- Example virtio-net with ATS + iommu -->
    <interface type='bridge'>
      <mac address='52:54:00:12:34:56'/>
      <source bridge='br0'/>
      <model type='virtio'/>
      <driver iommu='on' ats='on'/>
    </interface>

    <!-- Pass through a PCIe device from Unraid into the Proxmox VM -->
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
    </hostdev>
  </devices>
</domain>

That XML is aligned with libvirt’s documented IOMMU device support: <iommu model='intel'> plus intremap, caching_mode, iotlb, and aw_bits. The iommu='on' / ats='on' attributes on virtio devices are also documented by libvirt for use with emulated IOMMU and device-IOTLB. https://libvirt.org/formatdomain.html

If Unraid’s libvirt GUI/XML editor does not honor all of that cleanly, you can force it with QEMU args. Equivalent QEMU-side pieces look like this:

-machine q35,accel=kvm,kernel_irqchip=split \
-cpu host,vmx=on \
-device intel-iommu,intremap=on,caching-mode=on,device-iotlb=on,aw-bits=48

Those options come straight from QEMU’s Intel IOMMU device docs: intel-iommu on q35, caching-mode=on required for vfio-pci, and device-iotlb=on for virtio/vhost use cases with ATS.

If you want to inject them via the Unraid/libvirt XML, use:

<qemu:commandline>
  <qemu:arg value='-machine'/>
  <qemu:arg value='q35,accel=kvm,kernel_irqchip=split'/>
  <qemu:arg value='-cpu'/>
  <qemu:arg value='host,vmx=on'/>
  <qemu:arg value='-device'/>
  <qemu:arg value='intel-iommu,intremap=on,caching-mode=on,device-iotlb=on,aw-bits=48'/>
</qemu:commandline>

On the Unraid host, also verify these before blaming Proxmox:

cat /sys/module/kvm_intel/parameters/nested
egrep -o 'vmx|svm' /proc/cpuinfo | head
cat /proc/cmdline
dmesg | grep -i -e iommu -e dmar

For Intel, you want to see nested enabled and host IOMMU/DMAR active. Kernel docs confirm kvm-intel.nested is the switch for nested VMX.

Inside the Proxmox VM, check:

dmesg | grep -i -e iommu -e dmar
find /sys/kernel/iommu_groups -maxdepth 2 -type l

If Proxmox still says no IOMMU after the above, the usual causes are:

1. VM is not using q35.

2. No vIOMMU device was actually added.

3. CPU is not host-passthrough / VMX exposed.

4. kernel_irqchip=split / <ioapic driver='qemu'/> is missing.

5. Unraid rewrote the XML and dropped the custom options.

One more important practical point: vIOMMU lets Proxmox pass devices onward to L2 guests, but it does not guarantee that a passed-through physical function will expose fully working SR-IOV management inside the VM. In practice, the more reliable design is often:

• enable SR-IOV on the Unraid host,

• create the VFs on Unraid,

• pass the needed VF(s) to the Proxmox VM or directly to target guests.

If your Intel B50 is not showing SR-IOV capability at all, that may indeed be firmware / card support / driver exposure, separate from the Proxmox vIOMMU issue. The two problems can exist at the same time.

My bottom line: for PVE-in-a-VM doing nested passthrough, this is not just a cosmetic Proxmox error. Add the Intel vIOMMU, use q35, expose VMX, use split irqchip, and then test again. If you want, I can turn your current Unraid VM XML into a fully corrected paste-ready version.

so to clarify first try adding this custom edit to the bottom of the xml before teh end of </domain>

a

<qemu:commandline>
  <qemu:arg value='-machine'/>
  <qemu:arg value='q35,accel=kvm,kernel_irqchip=split'/>
  <qemu:arg value='-cpu'/>
  <qemu:arg value='host,vmx=on'/>
  <qemu:arg value='-device'/>
  <qemu:arg value='intel-iommu,intremap=on,caching-mode=on,device-iotlb=on,aw-bits=48'/>
</qemu:commandline>