🚨 'No valid host was found' in OpenStack Nova — Causes & Fix

TL;DR: No valid host was found means Nova’s scheduler ended with an empty candidate list — either Placement returned no host with enough free MEMORY_MB/VCPU/DISK_GB (after allocation ratios and reservations), or a Nova filter eliminated every host. Read the scheduler log first: “Got no allocation candidates” points at Placement capacity/traits, while “Filtering removed all hosts” names the exact filter (disabled computes, host aggregates, or an anti-affinity server group). Confirm capacity with openstack allocation candidate list --resource VCPU=2 --resource MEMORY_MB=4096 --resource DISK_GB=20. Full diagnostic workflow below.

Overview

No valid host was found is Nova’s way of saying the scheduler started with a list of candidate compute hosts and ended with an empty list. Either Placement returned no allocation candidates with enough capacity, or the in-process scheduler filters eliminated every host that Placement did return. Because the scheduler never picked a target, the instance goes straight to ERROR and is not rescheduled.

You will see this in the instance fault:

NoValidHost: No valid host was found. There are not enough hosts available.

And in the nova-scheduler (or nova-conductor) log:

WARNING nova.scheduler.manager [req-...] Got no allocation candidates from the placement API. This could be due to insufficient resources or a temporary occurrence as compute nodes start up.

It happens at instance boot, resize/migrate (the destination is also scheduled), and evacuate. The decision is per-request: a flavor that boots fine today can fail tomorrow when the fleet fills up, when a host is disabled, or when a server group’s anti-affinity rule excludes the only host with room.

Symptoms

• Instance goes to ERROR immediately after BUILD with fault “No valid host was found”.
• Resize or live-migration to a specific host fails with the same message.
• The error appears even though openstack hypervisor list shows free capacity (filters, not raw capacity, are eliminating hosts).

openstack server show web-01 -c fault -f value

{'code': 500, 'created': '2026-06-24T14:02:11Z', 'message': 'No valid host was found. There are not enough hosts available.', 'details': 'Traceback ... NoValidHost: No valid host was found...'}

openstack server show web-01 -c 'OS-EXT-SRV-ATTR:hypervisor_hostname' -c status -f value

None
ERROR

Common Root Causes

1. Placement has no host with enough RAM, vCPU, or disk

The first cut happens in Placement, before any Nova filter runs. If no resource provider has unused MEMORY_MB, VCPU, and DISK_GB for the flavor, you get zero candidates and the scheduler stops.

openstack resource provider list
openstack resource provider inventory list <RP_UUID>
openstack resource provider usage show <RP_UUID>

+----------------+------------------+----------+----------+----------+-----------+-------+
| resource_class | allocation_ratio | min_unit | max_unit | reserved | step_size | total |
+----------------+------------------+----------+----------+----------+-----------+-------+
| VCPU           |             16.0 |        1 |       64 |        0 |         1 |    64 |
| MEMORY_MB      |              1.0 |        1 |   257000 |     4096 |         1 |  257000 |
| DISK_GB        |              1.0 |        1 |     1800 |        0 |         1 |   1800 |
+----------------+------------------+----------+----------+----------+-----------+-------+

Compare total * allocation_ratio - reserved - used to the flavor’s demand. Tight MEMORY_MB (ratio 1.0) is the usual culprit.

2. ComputeFilter excluding disabled or down computes

ComputeFilter drops any host whose nova-compute service is disabled or not reporting. If you disabled hosts for maintenance and forgot to re-enable them, capacity vanishes.

openstack compute service list --service nova-compute

+----+--------------+------------+------+----------+-------+----------------------------+
| ID | Binary       | Host       | Zone | Status   | State | Updated At                 |
+----+--------------+------------+------+----------+-------+----------------------------+
| 12 | nova-compute | compute-01 | nova | enabled  | up    | 2026-06-24T14:01:55.000000 |
| 13 | nova-compute | compute-02 | nova | disabled | up    | 2026-06-24T13:40:02.000000 |
| 14 | nova-compute | compute-03 | nova | enabled  | down  | 2026-06-24T11:12:18.000000 |
+----+--------------+------------+------+----------+-------+----------------------------+

compute-02 is disabled and compute-03 is down — both are filtered out. Re-enable:

openstack compute service set --enable compute-02 nova-compute

3. AggregateInstanceExtraSpecsFilter and host aggregates

If your flavor carries aggregate_instance_extra_specs:<key> extra_specs, only hosts in an aggregate with the matching metadata pass. A typo or a missing aggregate membership eliminates everything.

openstack aggregate list
openstack aggregate show ssd-aggregate
openstack flavor show m1.fast -c properties -f value

{'aggregate_instance_extra_specs:storage': 'ssd'}

If no aggregate has metadata storage=ssd (or no compute is a member), the filter returns zero hosts.

4. Allocation ratios and reserved capacity

CPU/RAM oversubscription is governed by allocation_ratio (now stored on the Placement inventory, historically cpu_allocation_ratio / ram_allocation_ratio in nova.conf). A ratio of 1.0 on RAM with reserved_host_memory_mb set high can make a host look full while free still shows memory.

grep -E '^(cpu_allocation_ratio|ram_allocation_ratio|disk_allocation_ratio|reserved_host_memory_mb)' \
  /etc/nova/nova.conf

cpu_allocation_ratio = 16.0
ram_allocation_ratio = 1.0
reserved_host_memory_mb = 8192

5. Anti-affinity server groups

A server group with the anti-affinity policy forbids two members on the same host. Once every host already runs one member, the next instance has nowhere legal to land — even with abundant capacity.

openstack server group list
openstack server group show db-cluster -c policy -c members -f yaml

policy: anti-affinity
members:
- 7c9e... (on compute-01)
- 4a2b... (on compute-02)
- 0f5d... (on compute-03)

A 3-host cloud cannot place a 4th anti-affinity member. Use soft-anti-affinity or add hosts.

6. Flavor extra_specs the fleet cannot satisfy

ComputeCapabilitiesFilter, NUMATopologyFilter, or trait-based extra_specs (trait:CUSTOM_GPU=required, hw:cpu_policy=dedicated) can match nothing if no host advertises that capability or trait.

openstack flavor show g1.gpu -c properties -f value

{'trait:CUSTOM_GPU': 'required', 'hw:cpu_policy': 'dedicated'}

If no resource provider has the CUSTOM_GPU trait, Placement returns no candidates before Nova filters even run.

Diagnostic Workflow

Step 1: Read the fault and the scheduler log

openstack server show <SERVER> -c fault -f value

# Kolla-Ansible (controller)
docker logs nova_scheduler 2>&1 | grep -iE "no allocation candidates|no valid host|Filter .* returned 0 hosts" | tail -10
# Traditional packages
sudo journalctl -u devstack@n-sch 2>/dev/null || \
  sudo grep -iE "no allocation candidates|Filtering removed all hosts" /var/log/nova/nova-scheduler.log | tail -10

“Got no allocation candidates” points at Placement (Step 3); “Filtering removed all hosts” points at a Nova filter (Step 4).

Step 2: Confirm raw hypervisor capacity

openstack hypervisor list --long
openstack hypervisor stats show

This shows vcpus_used/vcpus, memory_mb_used/memory_mb, and free disk per host — a sanity check that the cloud is not simply full.

Step 3: Query Placement directly for the flavor’s resources

openstack allocation candidate list \
  --resource VCPU=2 --resource MEMORY_MB=4096 --resource DISK_GB=20

If this returns rows, Placement has capacity and the elimination is a Nova filter. If it returns nothing, the gap is inventory/ratio/traits (Step 5).

Step 4: Check service state and the enabled filters

openstack compute service list --service nova-compute
grep -E '^(enabled_filters|scheduler_default_filters)' /etc/nova/nova.conf

enabled_filters = AvailabilityZoneFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,AggregateInstanceExtraSpecsFilter

Cross-reference the enabled filters with the flavor’s extra_specs, aggregates, and server group to find which one applies.

Step 5: Inspect inventory, usage, and allocation ratios

for rp in $(openstack resource provider list -f value -c uuid); do
  echo "== $rp =="
  openstack resource provider inventory list $rp
  openstack resource provider usage show $rp
done

total * allocation_ratio - reserved - used per resource class tells you exactly how much is bookable. If that is below the flavor’s demand on every provider, you have a capacity problem; add hosts or raise ratios.

Example Root Cause Analysis

A request to boot four db.large instances into the db-cluster server group succeeds three times and fails on the fourth with No valid host was found.

openstack hypervisor list --long shows all three compute nodes at well under 50% RAM and CPU, so the cloud is not full. The scheduler log is the tell:

DEBUG nova.filters [req-...] Filter ServerGroupAntiAffinityFilter returned 0 hosts
INFO nova.filters [req-...] Filtering removed all hosts for the request with instance ID '9d1c...'. Filter results: ['AvailabilityZoneFilter: (start: 3, end: 3)', 'ComputeFilter: (start: 3, end: 3)', 'ServerGroupAntiAffinityFilter: (start: 3, end: 0)']

The group policy is anti-affinity and all three hosts already run a member. With only three computes, a fourth anti-affinity member is mathematically impossible.

Fix: either add a fourth compute node, or recreate the group with soft-anti-affinity so Nova best-effort spreads members but still places the fourth:

openstack server group create db-cluster-soft --policy soft-anti-affinity
# boot the 4th member with --hint group=<new-group-uuid>

The fourth instance then schedules onto the least-loaded host and reaches ACTIVE.

Prevention Best Practices

• Alert on disabled/down computes: poll openstack compute service list and page when a nova-compute is disabled or down. Forgotten maintenance disables silently shrink the schedulable pool.
• Capacity-plan against Placement, not nova.conf: monitor total*ratio - reserved - used per resource class so you raise ratios or add hosts before RAM (ratio 1.0) is exhausted.
• Size anti-affinity groups to your host count: never request more anti-affinity members than you have compute hosts; prefer soft-anti-affinity for clusters that may grow.
• Keep flavor extra_specs and aggregate metadata in sync via config management; a single typo’d aggregate_instance_extra_specs key zeroes the host list.
• Advertise GPU/NUMA traits on the hosts that actually have them, and validate every specialized flavor against openstack allocation candidate list before publishing it.
• For ad-hoc triage, the free incident assistant can turn a scheduler log dump into the likely filter or capacity cause. See more in OpenStack guides.

Quick Command Reference

# The fault and scheduler reason
openstack server show <SERVER> -c fault -f value
docker logs nova_scheduler 2>&1 | grep -iE "no allocation candidates|Filtering removed all hosts" | tail -10
sudo grep -iE "no allocation candidates|Filtering removed all hosts" /var/log/nova/nova-scheduler.log | tail -10

# Raw capacity and service state
openstack hypervisor list --long
openstack compute service list --service nova-compute

# Does Placement have candidates for the flavor's resources?
openstack allocation candidate list --resource VCPU=2 --resource MEMORY_MB=4096 --resource DISK_GB=20

# Inventory, usage, and ratios
openstack resource provider inventory list <RP_UUID>
openstack resource provider usage show <RP_UUID>
grep -E '^(cpu_allocation_ratio|ram_allocation_ratio|reserved_host_memory_mb|enabled_filters)' /etc/nova/nova.conf

# Flavor extra_specs, aggregates, server groups
openstack flavor show <FLAVOR> -c properties -f value
openstack aggregate list
openstack server group show <GROUP> -c policy -c members -f yaml

# Re-enable a host
openstack compute service set --enable <HOST> nova-compute

Related OpenStack Errors

• OpenStack: ‘Got no allocation candidates from the placement API’ — the Placement-side half of this error; start here when the scheduler log says “no allocation candidates.”
• OpenStack: ‘Filtering removed all hosts for the request’ — the Nova-filter half; walks through reading Filter results: to name the offending filter.
• OpenStack: ‘Quota exceeded’ for instances, cores, or RAM — the other common reason a boot fails before it ever schedules.
• Next step: the OpenStack troubleshooting hub collects the top OpenStack errors, a launcher, and the incident assistant, or browse all OpenStack guides.

Conclusion

No valid host was found means the candidate host list reached zero — either in Placement (no inventory) or in a Nova filter. The usual root causes:

1. No provider has enough free MEMORY_MB/VCPU/DISK_GB after ratios and reservations.
2. ComputeFilter dropped disabled or down nova-compute services.
3. AggregateInstanceExtraSpecsFilter found no aggregate matching the flavor metadata.
4. Allocation ratios or reserved_host_memory_mb made hosts look full.
5. A server group anti-affinity policy left no legal host.
6. Flavor extra_specs (traits, NUMA, dedicated CPU) that no host can satisfy.

Read the scheduler log first: “Got no allocation candidates” sends you to Placement inventory, while “Filtering removed all hosts” names the exact filter to fix.