Diagnosing 'No Valid Host Found' Errors in OpenStack Nova

The Scheduling Failure Problem

When an OpenStack instance remains in an ERROR state with the message No valid host was found, the Nova scheduler has exhausted all available compute nodes without finding one that satisfies the instance's requirements. This is rarely a failure of the scheduler itself, but rather a mismatch between the requested Flavor (the template defining VCPU, RAM, and Disk) and the available resources reported by the Placement API.

Quick Diagnostic Reference

Step 1: Identify the Filtering Culprit

The Nova scheduler uses a series of filters to narrow down the list of potential hosts. To find out exactly why hosts are being rejected, you must examine the scheduler logs on the controller node.

# Run on Controller Node as root or nova user
grep "Filtering" /var/log/nova/nova-scheduler.log | tail -n 100

Look for lines indicating which filter removed the hosts. Common culprits include:

• RamFilter: The host does not have enough available RAM based on the flavor and the ram_allocation_ratio.
• ComputeFilter: The compute service is down or disabled.
• AvailabilityZoneFilter: The requested AZ does not contain any active hosts.

Step 2: Verify Compute Service Health

Before analyzing resource numbers, ensure the compute nodes are actually available to accept workloads. A node marked as disabled is ignored by the scheduler regardless of its available RAM.

# Run on Controller Node
openstack compute service list

If a node is disabled, re-enable it using:

# Run on Controller Node
openstack compute service set --enable <host> nova-compute

Step 3: Audit Placement API Inventory

Nova relies on the Placement API to track resource providers. If the Placement database believes a host is full, but the physical host is empty, scheduling will fail. This "inventory drift" often happens after manual resource changes or failed instance deletions.

First, list the resource providers:

# Run on Controller Node
openstack resource provider list

Then, check the inventory for a specific provider to see if the allocation_ratio is causing a bottleneck:

# Run on Controller Node
openstack resource provider inventory show <UUID>

Step 4: Evaluate Overcommit Ratios

If physical resources exist but the scheduler still fails, check the nova.conf settings on the compute nodes. The ram_allocation_ratio determines how many virtual GBs can be assigned per physical GB.

Example Configuration:
If you have 64GB of physical RAM and a ratio of 1.5, Nova allows 96GB of total flavor assignments. If this is set to 1.0, you cannot overcommit.

# Check in /etc/nova/nova.conf on Compute Nodes
[DEFAULT]
ram_allocation_ratio = 1.5
cpu_allocation_ratio = 16.0
disk_allocation_ratio = 1.0

Risk: Increasing these ratios allows more VMs per host but increases the risk of Out-Of-Memory (OOM) kills on the hypervisor, which can crash all instances on that node.

Resolution Matrix

• Finding: RamFilter rejected all hosts, but resource provider inventory shows available space.
  Fix: Restart nova-compute on the target nodes to refresh the resource report to Placement.
• Finding: AvailabilityZoneFilter rejected hosts.
  Fix: Check if the instance is being launched into a specific AZ (e.g., nova boot --az nova) that has no active compute nodes.
• Finding: Flavor requires 32GB RAM, but the largest physical host only has 32GB (and some is used by the OS).
  Fix: Create a smaller flavor or add physical RAM to the compute nodes.

Verification and Rollback

To verify the fix, attempt to launch a minimal instance using a small flavor:

openstack server create --flavor <small-flavor> --image <image> test-instance

If you modified nova.conf, you must restart the service for changes to take effect:

# Run on Compute Nodes
systemctl restart nova-compute

Rollback: If the system becomes unstable after increasing allocation ratios, revert the nova.conf values to their previous state and restart nova-compute. Note that this will not remove already scheduled VMs; it only prevents new ones from being placed.

Escalation Criteria

If the following conditions are met, escalate to the infrastructure architect or storage admin:

• The DiskFilter is failing despite ample local storage (suggests a problem with the shared storage mount or LVM volume group).
• The Placement API reports 400 Bad Request or 500 Internal Server Error when queried.
• Instances are scheduled but immediately transition from BUILD to ERROR (suggests a hypervisor-level failure rather than a scheduler failure).