☁️ OpenStack Error: nova-compute 'Error updating resources' — fix resource tracker claim failures

Exact Error Message

# /var/log/nova/nova-compute.log
ERROR nova.compute.manager [-] Error updating resources for node compute-03.
ERROR nova.compute.manager Traceback (most recent call last):
ERROR nova.compute.manager   File ".../nova/compute/resource_tracker.py", line 941,
    in _update_available_resource
ERROR nova.compute.manager   File ".../nova/compute/resource_tracker.py", line 1385,
    in _update
ERROR nova.compute.manager keystoneauth1.exceptions.connection.ConnectFailure:
    Unable to establish connection to https://controller:8778/allocations
WARNING nova.compute.resource_tracker [-] Instance abc-123 has allocations
    against this compute host but is not found in the list of instances.

You may also see ResourceProviderUpdateConflict, ComputeResourcesUnavailable: Insufficient compute resources, or Failed to compute_task_build_instances: No valid host was found on the scheduler side as a downstream effect.

What It Means

The Nova resource tracker runs inside nova-compute on every hypervisor. On each periodic run it inventories the host (CPU, RAM, disk, PCI, NUMA), reconciles running instances against claimed allocations, and reports the result to the Placement service. Error updating resources for node means that reconciliation raised an exception, so the compute node’s view of free capacity is now stale.

The consequence is real: if the tracker cannot update Placement, the scheduler works from wrong numbers. That produces both false No valid host was found rejections (host looks full when it is not) and orphaned allocations that pin capacity to instances that no longer exist.

Common Causes

• nova-compute cannot reach the Placement API (network, wrong [placement] endpoint, expired service token).
• Orphaned or leaked allocations in Placement for instances that were deleted out-of-band.
• A ResourceProviderUpdateConflict from concurrent generation updates (compute and a migration racing).
• The compute node’s reported inventory shrank below existing allocations (e.g. cpu_allocation_ratio changed).
• A corrupt or half-deleted instance leaving the tracker unable to reconcile.
• Clock skew or an invalid Keystone service user for the [placement] section.

Diagnostic Commands

Confirm the compute service and its tracker state:

openstack compute service list --service nova-compute
sudo tail -f /var/log/nova/nova-compute.log

Check the resource provider and its reported inventory in Placement:

openstack resource provider list --name compute-03
openstack resource provider inventory list <provider-uuid>
openstack resource provider usage show <provider-uuid>

Look for allocations that reference instances Nova no longer has:

openstack resource provider allocation list <provider-uuid>
openstack server list --all-projects --host compute-03

Validate connectivity from the compute node to Placement:

sudo -u nova openstack --os-cloud placement endpoint list | grep 8778

Step-by-Step Resolution

1. Fix connectivity first. Verify the [placement] credentials and endpoint in nova.conf, then restart the agent:

sudo crudini --get /etc/nova/nova.conf placement auth_url
sudo systemctl restart nova-compute

2. Watch the next tracker cycle complete cleanly:

sudo grep -E 'Final resource view|Error updating resources' /var/log/nova/nova-compute.log | tail

INFO nova.compute.resource_tracker [-] Final resource view: name=compute-03
    phys_ram=257000MB used_ram=64000MB phys_disk=3600GB used_disk=420GB

3. If the log reports allocations for missing instances, audit them before deleting. Confirm the instance is truly gone:

openstack server show abc-123   # "No server with a name or ID of 'abc-123'"

4. Heal the orphaned allocations with the Nova audit tool (dry run first):

nova-manage placement audit --verbose
nova-manage placement audit --delete --resource_provider <provider-uuid>

5. If inventory shrank below usage after a ratio change, restore a valid cpu_allocation_ratio/ram_allocation_ratio so allocations fit:

sudo crudini --set /etc/nova/nova.conf DEFAULT cpu_allocation_ratio 4.0
sudo systemctl restart nova-compute

6. Confirm the scheduler now sees correct capacity:

openstack hypervisor show compute-03 -c vcpus -c vcpus_used -c free_ram_mb

Prevention

• Monitor nova-compute.log for Error updating resources and alert on repeated occurrences.
• Always delete instances through the API; deleting domains directly in libvirt leaves orphaned allocations.
• Run nova-manage placement audit periodically to catch leaked allocations early.
• Keep Placement highly available and the [placement] service user valid so the tracker never loses its endpoint.
• Change allocation ratios deliberately and confirm existing usage still fits before applying.

Related Errors

• No valid host was found — the scheduler’s downstream symptom of stale/wrong capacity.
• ComputeResourcesUnavailable: Insufficient compute resources — a claim failed at build time.
• ResourceProviderUpdateConflict — a Placement generation conflict, often transient and self-healing.
• Instance ... is not found in the list of instances — an orphaned allocation, the trigger for a placement audit.

Frequently Asked Questions

Is it safe to delete orphaned allocations with nova-manage placement audit --delete? Yes, once you have confirmed the instance no longer exists via openstack server show. The audit only removes allocations that have no matching instance, freeing the capacity they falsely held.

Why does the scheduler say a host is full when it clearly has room? Stale allocations in Placement, usually from instances deleted out-of-band, make the resource provider look fully committed. Auditing and removing them restores the real free capacity.

Does restarting nova-compute clear the error? A restart forces a fresh tracker cycle and fixes transient connectivity issues, but it will not remove orphaned allocations — you still need the placement audit for those.

Can I prevent this on busy clusters? Keep Placement available, avoid out-of-band deletes, and script periodic audits — the automation patterns in the prompt library help. For more compute fixes, see the OpenStack guides.