☁️ OpenStack Error: 'PCI device not found' SR-IOV / PCI Passthrough Scheduling Failure

Exact Error Message

$ openstack server show sriov-vm-01 -c fault -f value
{'code': 500,
 'message': 'No valid host was found. There are not enough hosts available.'}

The nova-scheduler and nova-compute logs show the real cause — no host has a matching PCI device free:

nova.scheduler.filters.pci_passthrough_filter [req-...]
  (compute-02) doesn't have the required PCI devices
nova.pci.stats [req-...] Failed to allocate PCI devices for instance.
  Unable to find a matching pool for request: PciDeviceRequest ...
nova.exception PciDeviceNotFound: PCI device not found on compute-02

What It Means

When a flavor or port requests a PCI or SR-IOV device (via a pci_passthrough:alias extra spec or a vnic_type=direct port), Nova’s PciPassthroughFilter looks for a compute host whose PCI inventory contains a free device matching the requested vendor/product ID and physical network tag. If nothing matches — because the alias, device_spec, IOMMU, or SR-IOV VFs are misconfigured, or all VFs are already claimed — Nova cannot allocate the device and the instance fails with No valid host was found, backed by PciDeviceNotFound in the logs.

This is almost always a configuration or capacity mismatch between the flavor/alias and what nova-compute actually reports as available, not a broken card.

Common Causes

• The flavor’s pci_passthrough:alias name does not match any [pci] alias defined in nova.conf on the controller.
• The [pci] device_spec (formerly passthrough_whitelist) on the compute host doesn’t match the card’s real vendor/product ID or PF address.
• SR-IOV virtual functions were never created (sriov_numvfs is 0), so there are no VFs to hand out.
• IOMMU is disabled in BIOS or the kernel (intel_iommu=on / amd_iommu=on missing), so no devices are passthrough-capable.
• Every matching VF/device is already allocated to running instances (real exhaustion).

Diagnostic Commands

Confirm the card and its vendor:product ID and current VF count:

lspci -nn | grep -i -E 'ethernet|network'
cat /sys/class/net/enp3s0f0/device/sriov_numvfs

Check the compute host’s Nova PCI configuration:

sudo grep -A3 -E '^\[pci\]|device_spec|passthrough_whitelist' /etc/nova/nova.conf

Check the controller’s alias definition (must match the flavor):

sudo grep -A2 '\[pci\]' /etc/nova/nova.conf | grep alias
openstack flavor show sriov.large -c properties -f value

Verify IOMMU is active on the compute host:

sudo dmesg | grep -e DMAR -e IOMMU | head

Read why the scheduler rejected the hosts:

sudo grep -i -E 'pci|PciDeviceNotFound' /var/log/nova/nova-scheduler.log | tail -n 20

Step-by-Step Resolution

1. Match the flavor’s alias name to a controller alias. The string must be identical on both sides:

openstack flavor show sriov.large -c properties -f value
sudo grep 'alias' /etc/nova/nova.conf

2. Fix the compute host device_spec so the vendor/product ID (and physical_network for SR-IOV) match the real card:

sudo crudini --set /etc/nova/nova.conf pci device_spec \
  '{"vendor_id":"8086","product_id":"154c","physical_network":"physnet1"}'

3. If SR-IOV VFs are missing, create them and make it persistent:

echo 8 | sudo tee /sys/class/net/enp3s0f0/device/sriov_numvfs

4. Enable IOMMU if dmesg showed it off — add to the kernel cmdline and reboot:

sudo sed -i 's/GRUB_CMDLINE_LINUX="/GRUB_CMDLINE_LINUX="intel_iommu=on iommu=pt /' /etc/default/grub
sudo update-grub && sudo reboot

5. Restart the Nova services so the new PCI inventory is reported to Placement:

sudo systemctl restart nova-compute
sudo systemctl restart nova-scheduler   # on the controller

6. Confirm the compute node now advertises free PCI devices, then re-launch:

openstack resource provider list --resource VF:1
openstack server create --flavor sriov.large --image ubuntu-22.04 \
  --nic net-id=provider-net sriov-vm-01
openstack server show sriov-vm-01 -c status -f value

Prevention

• Keep the [pci] alias on controllers and [pci] device_spec on compute hosts in version control and templated together so names and IDs never drift.
• Persist sriov_numvfs via a udev rule or NetworkManager so VF counts survive reboots.
• Bake intel_iommu=on/amd_iommu=on into the base image for any host meant to serve passthrough.
• Use host aggregates so only PCI-capable hosts are eligible for SR-IOV flavors.
• Track VF utilization in Placement; alert before a physnet’s VFs are fully allocated.

Related Errors

• Requested instance NUMA topology cannot fit — a co-located pinning/NUMA failure often paired with PCI passthrough flavors.
• No valid host was found — the generic scheduler outcome this error produces.
• PciDevicePoolEmpty — all matching devices allocated; a genuine capacity variant.
• Unable to detach PCI device — a teardown-time passthrough error rather than scheduling.

Frequently Asked Questions

Why does the scheduler say no host when the card is installed? The card must be exposed correctly: device_spec must match its vendor/product ID, VFs must exist, and IOMMU must be on. If any of these is wrong, nova-compute reports zero matching devices even though the hardware is present.

How do I match the alias between flavor and nova.conf? The pci_passthrough:alias value on the flavor must exactly equal an alias name in the controller’s [pci] section. Compare them with openstack flavor show and grep alias /etc/nova/nova.conf. For generating matched alias/device_spec pairs, the OpenStack prompts library has templates.

Do I need IOMMU for SR-IOV? Yes. Without intel_iommu=on or amd_iommu=on the kernel will not present passthrough-capable devices, and Nova will find none to allocate. Check dmesg | grep IOMMU.

Why did VFs disappear after a reboot? sriov_numvfs is not persistent by default. Set it via a udev rule or NetworkManager profile so the VFs are recreated at boot.

Is this ever a real capacity problem? Yes — if all matching VFs are already assigned to instances you will see PciDevicePoolEmpty. Check allocations in Placement before assuming a misconfiguration. For more Nova fixes, see the OpenStack guides.