OpenStack Nova 'No Valid Host Was Found': A Scheduling Failure Triage Guide

An instance stays in BUILD and then moves to ERROR. openstack server show reports a fault such as No valid host was found or Exceeded maximum number of retries when scheduling. Both mean the same thing at a high level: nova-scheduler either found no candidate hosts, or found candidates and rejected every one of them.

The fault text is an outcome, not a cause. Nova does not record which constraint failed in the fault field, so the useful evidence lives in nova-scheduler.log, nova-conductor.log, and the Placement API.

Two terms used throughout: Placement is the OpenStack service that stores per-host resource inventories and allocations; the scheduler asks it for allocation candidates. Scheduler filters are pluggable rules listed in scheduler_default_filters in nova.conf that narrow those candidates further.

Cause triage table

What you observe	Likely cause	First check
No nova-compute host listed, or a host shows down / disabled	Compute service stopped or administratively disabled	openstack compute service list --service nova-compute
Scheduler log shows a filter removing every candidate	A constraint excludes all hosts: resources, aggregate metadata, anti-affinity, or image	Grep the request ID in nova-scheduler.log
Hypervisor reports free RAM but Placement shows the provider fully allocated	Placement inventory drift or a stale nova-compute heartbeat	Compare openstack hypervisor show with openstack resource provider usage show
Fault says retries were exhausted with no filter detail	Scheduler retried and gave up; often transient, or every host was filtered	Read the full scheduler log window for that request
Instance lands in a cell with no mapped hosts	Cells v2 host mapping missing	nova-manage cell_v2 list_hosts

Ordered checks

Run the admin-scoped commands from a host with the OpenStack client installed and credentials carrying the admin role. The project-scoped commands work with ordinary project credentials.

1. Confirm the compute services are up and enabled

openstack compute service list --service nova-compute

Expected check: every host you expect to be a candidate shows State: up and Status: enabled. A host that is down or disabled is removed from scheduling immediately, so a single-host deployment with a stopped nova-compute produces exactly this fault.

If a host was disabled deliberately, re-enable it with openstack compute service set --enable <hostname> nova-compute. Re-enabling returns the host to the scheduling pool, so confirm it is healthy first.

2. Compare hypervisor capacity with Placement inventory

openstack hypervisor show <hostname> -c free_ram_mb -c free_disk_gb -c vcpus -c vcpus_used -c running_vms
openstack resource provider list
openstack resource provider usage show <provider-uuid>
openstack resource provider inventory list <provider-uuid>

Expected check: the free resources the hypervisor reports are broadly consistent with the inventory minus usage that Placement reports for the same host. A large gap, where the hypervisor reports free RAM but Placement reports the provider as fully allocated, points to inventory drift or a stale heartbeat rather than genuine exhaustion.

Reading Placement may require an admin or service role depending on the placement policy file in your deployment.

3. Find which filter rejected each candidate

grep <request-id> /var/log/nova/nova-scheduler.log
grep -i 'no valid host' /var/log/nova/nova-conductor.log

Take <request-id> from the x-openstack-request-id response header of the failed create, or from the server event list if your client supports openstack server event list <server>. Expected check: the log shows the candidate hosts and per-filter removal messages naming the exact constraint, for example an aggregate extra-specs filter or an anti-affinity filter.

Version note: from the Stein release onward, resource-based filtering largely happens through Placement allocation candidates rather than the older RamFilter and DiskFilter. Their absence from the log is not evidence that capacity is fine. Confirm the active filter list in nova.conf and the Nova release (nova-manage version on a controller) before interpreting the log.

4. Check cell mapping and host aggregates

nova-manage cell_v2 list_hosts
openstack aggregate list
openstack aggregate show <aggregate>
openstack server group show <group>

In a Cells v2 deployment, a healthy compute node in a different cell is not a candidate for an instance in the current cell. If list_hosts shows no mapped host for the cell the instance landed in, the fault is a mapping problem, not capacity. Similarly, aggregate metadata or a server group with an anti-affinity policy can exclude every host when the group has more members than there are eligible hosts.

5. Confirm the image is reachable from candidate hosts

openstack image show <image>
openstack image list --private

If the image is missing from the store the compute nodes read from, or is private to a different project, image-related filters can reject otherwise healthy hosts. Check the image location and the Glance backend configuration, for example file versus rbd, rather than assuming a scheduling bug.

Fixes tied to each finding

Finding	Fix	Risk and reversal
Compute service down or disabled	Restart nova-compute; re-enable with openstack compute service set --enable <hostname> nova-compute	Re-enabling returns the host to the pool; verify health first
Genuine capacity exhaustion	Add hosts, or adjust cpu_allocation_ratio, ram_allocation_ratio, or disk_allocation_ratio in nova.conf and restart the compute service	Ratios apply globally to future placements; revert the config and restart
Placement inventory drift	nova-manage placement heal_allocations and nova-manage placement sync_aggregates; confirm exact subcommand names with nova-manage placement --help	heal_allocations writes allocation records; use --dry-run first where available
Aggregate or extra-spec metadata too restrictive	Correct the aggregate metadata or the flavor extra-spec	Affects every instance using that flavor; record previous values
Anti-affinity group larger than the eligible host set	Add hosts, or revise the server group policy	Changing the policy weakens the placement guarantee for existing members
Image missing or unreachable	Re-upload the image or correct the Glance backend or location	No scheduling state changes; verify the compute can read the backend

Confirm the fix

Reproduce with a minimal request rather than the original flavor:

openstack server create --flavor m1.tiny --image <known-good-image> --network <net> verify-sched
openstack server show verify-sched -c status -c fault -c OS-EXT-SRV-ATTR:host

Poll until the status is ACTIVE or ERROR. A successful boot should show a host in OS-EXT-SRV-ATTR:host; cross-check that the same host appears as the selected host in nova-scheduler.log for the new request ID. Then re-run the Placement comparison from check 2 to confirm inventory and usage moved consistently.

Delete the test server when finished so it does not consume the capacity you just verified.

When to escalate

• Placement returns HTTP 500 errors, or the scheduler log shows internal placement failures. Escalate to the cloud platform team.
• Database connectivity errors, deadlocks, or RabbitMQ timeouts appear in nova-conductor.log or nova-scheduler.log.
• The root cause is shared-storage or provider-network reachability rather than scheduling. Escalate to the storage or network team.
• Capacity is genuinely exhausted cloud-wide, and the decision to add hosts or change overcommit is a platform-level one.

Limitations

• Default filter sets differ by release and by deployment. A custom scheduler_default_filters changes which log lines you will see.
• Do not disable RamFilter or DiskFilter to force a boot. That can place an instance on a host that cannot satisfy the flavor, producing memory or disk pressure later.
• Changing overcommit ratios or flavor extra-specs affects future scheduling globally. Validate in a test project or a dedicated aggregate before applying broadly, and record the previous values so the change can be reverted with a config edit and service restart.