☁️ OpenStack Error: Nova Instance Stuck in ERROR State With a Fault Trace

Exact Error Message

$ openstack server show my-instance -f value -c status -c fault
ERROR
{'code': 500, 'created': '2026-07-17T09:22:41Z', 'message': 'No valid host was found. There are not enough hosts available.', 'details': 'Traceback (most recent call last):\n  File "/usr/lib/python3/dist-packages/nova/conductor/manager.py", line 1450, in schedule_and_build_instances\n    host_lists = self._schedule_instances(...)\n  nova.exception.NoValidHost: No valid host was found. There are not enough hosts available.\n'}

Other common faults in the same fault field include:

'message': 'Build of instance ... aborted: Volume ... did not finish being created even after we waited ...'
'message': 'Unexpected vif_type=binding_failed'
'message': "internal error: process exited while connecting to monitor ... unable to find CPU model 'Haswell'"

What It Means

When Nova cannot finish building or acting on an instance, it sets the server status to ERROR and records the reason in the fault field. The fault is a snapshot of the last exception nova-conductor or nova-compute hit, so it is the single most useful piece of diagnostic data — it tells you whether the failure was scheduling (NoValidHost), networking (binding_failed), storage (volume did not finish), or hypervisor-level (libvirt/QEMU).

ERROR is a terminal state: Nova will not retry on its own. You have to fix the root cause and then rebuild, hard-reboot, or reset the state.

Common Causes

• NoValidHost — no compute host satisfies the flavor’s RAM/vCPU/disk after filters (host full, aggregate/AZ mismatch, or Placement out of inventory).
• binding_failed — Neutron could not bind the port (dead OVS agent, wrong physical network, no segment).
• Volume attach/creation — a Cinder volume never reached available/in-use, so the build aborted.
• libvirt/QEMU spawn failure — missing CPU model, no hardware virtualization, or a bad image format.
• Quota or image issues — over quota mid-build, or a corrupt/killed Glance image.

Diagnostic Commands

Read the fault first — it decides everything else:

openstack server show my-instance -c status -c fault -c "OS-EXT-SRV-ATTR:host"

Review the instance action log to see which step failed:

openstack server event list my-instance
openstack server event show my-instance <request-id>

If the fault is NoValidHost, check capacity and Placement:

openstack hypervisor list --long
openstack resource provider list
openstack resource provider inventory list <compute-uuid>

On the target compute host, pull the compute log around the build:

sudo journalctl -u nova-compute --since "-20min" --no-pager | grep -i <instance-uuid>
sudo tail -n 200 /var/log/nova/nova-compute.log

Step-by-Step Resolution

1. Classify the fault. The message field points you at the subsystem: scheduling, networking, storage, or hypervisor. Everything below branches from that.

2. NoValidHost: confirm real capacity exists and Placement inventory is not exhausted. If a host is disabled or an aggregate/AZ filter is excluding it, fix that:

openstack compute service list --service nova-compute
openstack compute service set --enable compute2 nova-compute

3. binding_failed: check the Neutron agents and the port. A dead OVS agent or a physical-network mismatch is the usual cause:

openstack network agent list --host compute2
openstack port show <port-id> -c binding_vif_type -c binding_host_id

4. Volume did not finish: inspect the volume the build waited on and clear or recreate it:

openstack volume show <volume-id> -c status -c "os-vol-mig-status-attr:migstat"

5. libvirt/QEMU: read nova-compute.log for the exact internal error. A missing CPU model usually means cpu_mode/cpu_models in nova.conf does not match the hardware:

grep -iE "cpu_mode|cpu_models" /etc/nova/nova.conf
sudo virsh capabilities | grep -A2 "<model"

6. Once the root cause is fixed, recover the instance. If the config/backing resources are now correct, a rebuild or hard reboot is cleanest:

openstack server reboot --hard my-instance
# or, to redeploy from the image:
openstack server rebuild my-instance --image <image-id>

7. Only if the instance is actually healthy and Nova’s state is stale should you force it back to active. Do this deliberately — it does not fix anything, it only changes the recorded state:

openstack server set --state active my-instance

Prevention

• Alert on Placement inventory headroom so NoValidHost is caught before tenants hit it, not after.
• Monitor Neutron agents; most binding_failed faults trace back to a dead OVS/L2 agent.
• Validate images (openstack image show status active, correct disk_format) before offering them to tenants.
• Pin cpu_mode/cpu_models consistently across a compute aggregate so migrations and spawns do not hit missing-model errors.
• Keep quotas and capacity dashboards visible so builds are not aborted mid-flight by exhaustion.

Related Errors

• No valid host was found — the scheduling-specific form of this fault, worth its own capacity/Placement investigation.
• Unexpected vif_type=binding_failed — the Neutron port-binding failure behind many ERROR states.
• cannot fit instance NUMA topology — a pinning/NUMA scheduling failure that also lands the instance in ERROR.
• Flavor could not be found — a launch-time failure before the build even starts.

Frequently Asked Questions

Should I just reset the state to active? No — server set --state active only rewrites Nova’s bookkeeping. Use it only when the instance is genuinely running and the state is stale; otherwise fix the fault and rebuild or hard-reboot.

Why is there no retry? ERROR is terminal by design. Nova records the fault and stops so an operator can inspect it rather than looping on a failing build.

The fault says NoValidHost but I have free hosts — why? Filters, host aggregates, availability zones, disabled services, or exhausted Placement inventory can all exclude otherwise-idle hosts. Check openstack resource provider inventory list and the scheduler filters.

Can I get a quick triage checklist from the fault text? Yes — paste the fault message into the DevOps AI prompt library to map it to the right subsystem and next commands.

Where can I find more Nova troubleshooting? Browse the full OpenStack guides for related compute, scheduling, and networking fixes.