🚨 OpenStack Error Guide: Placement 'Resource provider with uuid not found' / 404

Overview

Placement is the service that tracks quantitative resource inventory (VCPU, MEMORY_MB, DISK_GB) as resource providers (RPs), one per compute node. Nova’s scheduler queries Placement to find candidate hosts and claims allocations against the chosen RP. When the RP that Nova expects no longer exists — or its UUID has changed — Placement returns a 404 and the request fails.

You will see it in the nova-compute or nova-scheduler log, or as a raw 404 from the Placement API:

ERROR nova.scheduler.client.report [req-...] [None] Failed to retrieve resource provider tree from placement API for UUID 5b8a2f1c-77aa-4c2e-9d31-2e0c1f4ab9e0. Got 404: {"errors": [{"status": 404, "title": "Not Found", "detail": "No resource provider with uuid 5b8a2f1c-77aa-4c2e-9d31-2e0c1f4ab9e0 found"}]}

Resource provider with uuid 5b8a2f1c-77aa-4c2e-9d31-2e0c1f4ab9e0 not found (HTTP 404)

Because the RP name is derived from the hypervisor hostname, anything that changes that identity — a host rename, a redeploy with a new UUID, a manual resource provider delete — desyncs Nova from Placement. Until they agree again, scheduling to that node fails or allocations point at a ghost.

Symptoms

• No valid host was found even with idle capacity on the node.
• nova-scheduler/compute logs a 404 for a specific RP UUID.
• openstack resource provider list is missing a host you expect, or shows a duplicate.
• Allocations reference a UUID that resource provider show cannot find.

openstack resource provider list -c uuid -c name

+--------------------------------------+------------+
| uuid                                 | name       |
+--------------------------------------+------------+
| 1c4d...                              | compute-01 |
| 9a7b...                              | compute-02 |
+--------------------------------------+------------+

openstack resource provider show 5b8a2f1c-77aa-4c2e-9d31-2e0c1f4ab9e0

Resource provider with uuid 5b8a2f1c-77aa-4c2e-9d31-2e0c1f4ab9e0 not found (HTTP 404)

Common Root Causes

1. Orphaned or deleted RP after a host rename

Placement keys an RP by UUID but names it after the hypervisor hostname. Rename the host (or change host in nova.conf) and nova-compute creates a new RP under the new name, abandoning the old one. Anything still referencing the old UUID gets a 404.

openstack resource provider list -c uuid -c name | grep -iE 'compute-04|compute-04-new'

| 5b8a...  | compute-04      |   <-- old, now orphaned (nova-compute no longer updates it)
| e3f0...  | compute-04-new  |   <-- new RP created after rename

2. Mismatched hypervisor hostname vs. RP name

nova-compute finds “its” RP by matching the resource-tracker node name to an RP name. If the OS hostname, host option, and existing RP name disagree (FQDN vs. short name is the classic case), it cannot find the RP and either errors or makes a duplicate.

hostname -f
grep -E '^host' /etc/nova/nova.conf
openstack hypervisor list -c "Hypervisor Hostname"

compute-04.dc1.example.com   # hostname -f
# host = compute-04          # nova.conf short name -> RP named "compute-04", mismatch

3. Stale allocations referencing a deleted RP

When an RP is deleted but instances (or in-flight migrations) still hold allocations against it, those allocations point at a UUID Placement no longer knows. The scheduler trips over them.

openstack resource provider allocation unset --help >/dev/null 2>&1
nova-manage placement audit --verbose

Allocations referencing resource provider 5b8a2f1c-... were found for consumer 7c9e... but the resource provider does not exist. This is an orphaned allocation.

4. RP deleted while it still had inventory/allocations (delete conflict)

Trying to remove an RP that still has allocations returns a 409, and a half-deleted state can leave Nova expecting an RP that is gone.

openstack resource provider delete 5b8a2f1c-77aa-4c2e-9d31-2e0c1f4ab9e0

Unable to delete resource provider 5b8a2f1c-...: Resource provider has allocations. (HTTP 409)

You must clear allocations before the RP will delete cleanly.

5. Compute node re-added with a new UUID

Reimaging or redeploying a host regenerates /var/lib/nova/compute_id (or the node UUID), so nova-compute registers a brand-new RP. The old RP lingers, and any record still pointing at the previous UUID 404s.

cat /var/lib/nova/compute_id 2>/dev/null
openstack resource provider list --name compute-05 -c uuid -c name

b2d9...   # current compute_id
| 5b8a... | compute-05 |   <-- stale RP from the previous deployment, UUID no longer matches

6. Aggregate / trait references to a gone RP

Host aggregates, placement aggregates, or trait associations can still name a deleted RP UUID, so reconciliation and scheduling queries hit a 404 when walking those references.

openstack resource provider aggregate list 5b8a2f1c-77aa-4c2e-9d31-2e0c1f4ab9e0 2>&1
docker logs nova_scheduler 2>&1 | grep -i 'resource provider' | grep 404 | tail -5

Resource provider with uuid 5b8a2f1c-... not found (HTTP 404)

Diagnostic Workflow

Step 1: Capture the failing UUID and the host it belongs to

docker logs nova_scheduler 2>&1 | grep -iE '404|No resource provider' | tail -10   # Kolla-Ansible
sudo journalctl -u nova-scheduler | grep -iE '404|No resource provider' | tail -10  # Traditional

Extract the RP UUID from the 404. That UUID is the thread you pull on through every later step.

Step 2: Reconcile RP names against live hypervisors

openstack resource provider list -c uuid -c name
openstack hypervisor list -c "Hypervisor Hostname" -c State

Look for an RP whose name has no matching live hypervisor (orphan), or two RPs for the same host (rename/redeploy left a duplicate).

Step 3: Check the host’s identity for a name/UUID mismatch

# On the affected compute host
hostname -f
grep -E '^host' /etc/nova/nova.conf
cat /var/lib/nova/compute_id 2>/dev/null

If the compute_id or hostname differs from the RP name Placement holds, that mismatch is why nova-compute cannot find its provider.

Step 4: Audit for orphaned allocations

# Run from a controller / nova_api container
nova-manage placement audit --verbose
# Inspect a specific consumer's allocations
openstack resource provider allocation show <CONSUMER_UUID>

This lists allocations pointing at non-existent RPs — the records you must clear before deleting or recreating cleanly.

Step 5: Clean up the stale RP and let nova-compute recreate it

# Clear allocations holding the dead RP, then delete it
openstack resource provider allocation unset --provider 5b8a2f1c-... <CONSUMER_UUID> 2>/dev/null
openstack resource provider delete 5b8a2f1c-77aa-4c2e-9d31-2e0c1f4ab9e0

# Force nova-compute to re-register its (correct) RP and refresh inventory
docker restart nova_compute            # Kolla-Ansible
sudo systemctl restart nova-compute    # Traditional

# Confirm a single, current RP with inventory
openstack resource provider list --name compute-04
openstack resource provider inventory list <NEW_RP_UUID>

Example Root Cause Analysis

After reimaging compute-05, every instance scheduled to it fails with No valid host was found, and nova-scheduler logs a 404 for RP 5b8a2f1c-.... Because the host was just redeployed, a UUID change is the obvious suspect.

Listing providers shows the smoking gun — two RPs for one host:

openstack resource provider list --name compute-05 -c uuid -c name

+----------+------------+
| 5b8a...  | compute-05 |   <-- old deployment, orphaned
| b2d9...  | compute-05 |   <-- new compute_id after reimage
+----------+------------+

The reimage regenerated /var/lib/nova/compute_id to b2d9..., so nova-compute now updates the new RP, but a host aggregate and lingering allocations still reference the old 5b8a... UUID — which is what 404s.

A placement audit confirms orphaned allocations against the dead RP:

Orphaned allocations found for consumer 7c9e... against resource provider 5b8a2f1c-... (does not exist as a usable provider).

Fix: clear the stale allocations, delete the old RP, and let nova-compute reconcile:

openstack resource provider allocation unset --provider 5b8a2f1c-... 7c9e... 2>/dev/null
openstack resource provider delete 5b8a2f1c-77aa-4c2e-9d31-2e0c1f4ab9e0
docker restart nova_compute
openstack resource provider list --name compute-05

+----------+------------+
| b2d9...  | compute-05 |   <-- single, current RP with full inventory
+----------+------------+

Scheduling resumes immediately against the correct provider.

Prevention Best Practices

• Treat the hypervisor hostname as immutable: never rename a live compute host or flip between FQDN and short name in nova.conf, since the RP name is derived from it.
• Preserve /var/lib/nova/compute_id across reimages (back it up and restore it) so a redeployed node keeps its existing RP UUID instead of orphaning it.
• Run nova-manage placement audit on a schedule and alert on orphaned allocations — they are the early warning for a 404 storm.
• Before deleting any RP, clear its allocations first to avoid the 409/half-deleted state that strands Nova.
• After decommissioning a host, explicitly remove its RP and aggregate references so nothing keeps pointing at a gone UUID.
• For ad-hoc triage, the free incident assistant can summarize placement 404s into the likely stale-RP cause. See more in OpenStack guides.

Quick Command Reference

# Capture the failing RP UUID
docker logs nova_scheduler 2>&1 | grep -iE '404|No resource provider' | tail -10
sudo journalctl -u nova-scheduler | grep -iE '404|No resource provider' | tail -10

# Reconcile RPs against live hypervisors
openstack resource provider list -c uuid -c name
openstack hypervisor list -c "Hypervisor Hostname" -c State

# Inspect a specific provider / its inventory
openstack resource provider show <RP_UUID>
openstack resource provider inventory list <RP_UUID>

# Host identity (name/UUID mismatch check)
hostname -f
grep -E '^host' /etc/nova/nova.conf
cat /var/lib/nova/compute_id 2>/dev/null

# Audit for orphaned allocations
nova-manage placement audit --verbose
openstack resource provider allocation show <CONSUMER_UUID>

# Clean up stale RP, then let nova-compute recreate
openstack resource provider allocation unset --provider <OLD_RP_UUID> <CONSUMER_UUID>
openstack resource provider delete <OLD_RP_UUID>
docker restart nova_compute
sudo systemctl restart nova-compute

Conclusion

A Placement “resource provider not found” 404 means Nova is asking for an RP whose UUID no longer exists or no longer matches the host’s identity. The usual root causes:

1. An orphaned RP left behind after a host rename.
2. A hypervisor-hostname vs. RP-name mismatch (FQDN vs. short name).
3. Stale allocations still referencing a deleted RP.
4. A delete conflict (409) that left an RP half-removed.
5. A reimaged node that re-registered under a new compute_id UUID.
6. Aggregate or trait references pointing at a gone RP.

Pull the failing UUID from the log, reconcile RP names against live hypervisors, clear orphaned allocations, then let nova-compute recreate the correct provider. Protecting the hostname and compute_id from drift prevents almost every recurrence.