🚨 OpenStack Error Guide: 'InstanceNotFound' nova-compute manager failure

Exact Error Message

2026-06-27 09:14:02.118 7 ERROR nova.compute.manager [req-7f1a2c9d-44b1-4e0a-9f12-8c2b1d3e44a0 - - - - -]
[instance: 6b2e9c41-8d3a-4f10-bb20-1a7c4e9d22f0] Instance not found during periodic task:
InstanceNotFound: Instance 6b2e9c41-8d3a-4f10-bb20-1a7c4e9d22f0 could not be found.
2026-06-27 09:14:02.118 7 ERROR nova.compute.manager Traceback (most recent call last):
2026-06-27 09:14:02.118 7 ERROR nova.compute.manager   File "/usr/lib/python3/dist-packages/nova/compute/manager.py", line 9981, in _sync_power_states
2026-06-27 09:14:02.118 7 ERROR nova.compute.manager     db_instance = objects.Instance.get_by_uuid(context, uuid)
2026-06-27 09:14:02.118 7 ERROR nova.compute.manager nova.exception.InstanceNotFound: Instance 6b2e9c41-8d3a-4f10-bb20-1a7c4e9d22f0 could not be found.

What the Error Means

InstanceNotFound is raised whenever Nova asks the database for an instance UUID and the row is absent (or marked deleted) for the context doing the lookup. The compute manager hits this most often during periodic tasks — _sync_power_states, _run_image_cache_manager_pass, _heal_instance_info_cache — that walk the hypervisor’s local guests and ask the database about each one.

The mismatch is the key: the hypervisor still has a libvirt domain (or a stale instances/<uuid> directory) for a VM that the database believes is gone. Nova tries to reconcile the two views, the lookup fails, and the periodic task logs the traceback. The same exception also surfaces synchronously on openstack server delete, server show, or server stop when a request targets a UUID that does not exist in the current project or cell.

Common Causes

• Orphaned libvirt domain after a failed delete — the database row was removed but virsh still lists the guest, so the next power-state sync trips on it.
• Cell mapping missing or pointing at the wrong cell — the instance exists in a cell database the API context cannot reach, so get_by_uuid returns nothing.
• Stale nova local instance directory — _run_image_cache_manager_pass finds a base image referenced by an on-disk directory whose instance is already deleted.
• Manual database deletion / archive — someone ran nova-manage db archive_deleted_rows or deleted rows directly while the guest was still running on a compute node.
• Request targeting a deleted or wrong-project UUID — a client retries a delete after it already succeeded, or queries a UUID belonging to another project without --all-projects.
• Split-brain after a cell or control-plane restart — a delete raced with a service restart and only half-committed.

How to Reproduce the Error

On a lab host you can recreate the orphaned-domain variant safely:

1. Launch a throwaway instance and note its UUID.
2. Remove only its database row (simulating a half-finished delete) without destroying the libvirt domain.
3. Wait for the next _sync_power_states periodic task (default 600s) or restart nova-compute.

Nova enumerates the libvirt guest, asks the database about its UUID, and logs InstanceNotFound. The synchronous variant reproduces instantly:

openstack server show 00000000-0000-0000-0000-000000000000

No server with a name or ID of '00000000-0000-0000-0000-000000000000' exists.

Diagnostic Commands

Confirm whether the database and hypervisor disagree about the UUID. These are all read-only.

# Does Nova's database know this instance (any state, all cells)?
openstack server show 6b2e9c41-8d3a-4f10-bb20-1a7c4e9d22f0 --all-projects

# Where Nova maps the instance to a cell
nova-manage cell_v2 list_cells
nova-manage cell_v2 verify_instance --uuid 6b2e9c41-8d3a-4f10-bb20-1a7c4e9d22f0

On the compute node, check whether libvirt still has the guest:

# Kolla-Ansible
docker exec nova_libvirt virsh list --all | grep 6b2e9c41
docker logs nova_compute 2>&1 | grep -i InstanceNotFound | tail

# Traditional packages
virsh list --all | grep 6b2e9c41
journalctl -u openstack-nova-compute | grep -i InstanceNotFound | tail

 -     instance-000004b2          shut off

A domain present in virsh list --all but absent from openstack server show is the orphan.

Step-by-Step Resolution

1. Confirm the database truly has no row. Run openstack server show <uuid> --all-projects. If it returns a server, the problem is a wrong cell mapping (step 2), not an orphan.

2. Repair the cell mapping if the instance exists in a cell. When verify_instance reports a missing or wrong mapping, recreate it:

   nova-manage cell_v2 map_instances --cell_uuid <cell-uuid>

   Re-run verify_instance to confirm it now resolves.

3. For a genuine orphan, identify the stray libvirt domain. Match the instance-XXXXXX name back to the UUID via the domain’s metadata:

   # Kolla-Ansible
   docker exec nova_libvirt virsh dumpxml instance-000004b2 | grep -i uuid
   # Traditional
   virsh dumpxml instance-000004b2 | grep -i uuid

4. Destroy and undefine the orphaned domain once you have confirmed the database row is gone and the UUID matches:

   # Kolla-Ansible
   docker exec nova_libvirt virsh destroy instance-000004b2
   docker exec nova_libvirt virsh undefine instance-000004b2
   # Traditional
   virsh destroy instance-000004b2
   virsh undefine instance-000004b2

5. Clean the stale instance directory if _run_image_cache_manager_pass was the source:

   ls -d /var/lib/nova/instances/6b2e9c41-* 2>/dev/null

   Remove the directory only after confirming no live domain references it.

6. Restart nova-compute and watch the next periodic sync run clean:

   docker restart nova_compute            # Kolla-Ansible
   systemctl restart openstack-nova-compute   # Traditional

Prevention and Best Practices

• Never delete Nova database rows by hand while a guest is running — always go through openstack server delete so the compute node tears down libvirt first.
• Run nova-manage db archive_deleted_rows only on a schedule that excludes recently deleted instances, and never with --purge until deletes have fully reconciled.
• Keep cell mappings healthy: after adding a compute host or restoring a cell, run nova-manage cell_v2 verify_instance for a sample of UUIDs.
• Alert on repeated InstanceNotFound in compute logs — a single occurrence after a delete is normal, but a recurring loop signals a true orphan needing cleanup.
• Route compute-manager error spikes into an automated triage flow such as /dashboard/incident-response/ so the responder sees the offending UUID immediately.

Related Errors

• InstanceNotFound during sync_power_state — the periodic-task variant described here.
• nova.exception.InstanceMappingNotFound — the cell mapping, not the instance, is missing.
• No server with a name or ID of '<uuid>' exists — the synchronous client-side form of the same lookup failure.
• Instance <uuid> could not be found. raised during live-migration — covered in our /categories/openstack/ guides.

Frequently Asked Questions

Is a single InstanceNotFound after a delete a problem? No. Right after a delete, an in-flight periodic task can race the row removal and log it once. Only a repeating pattern indicates a real orphan.

Will the error stop new instances from launching? Not directly. It is a reconciliation error on one UUID. But the periodic task that hits it may be doing useful work (power-state sync), so a persistent orphan can mask drift on other guests.

Can I just delete the libvirt domain whenever I see this? Only after confirming the database has no row for that UUID with --all-projects and verifying the domain’s UUID matches. Destroying a domain whose database row still exists will create a worse inconsistency.

Does this affect Kolla-Ansible differently from package installs? The cause is identical; only the access path differs — docker exec nova_libvirt virsh ... versus virsh ... directly, and docker logs versus journalctl.

Why does the cell mapping matter? The API context queries through cell mappings. If an instance lives in a cell the mapping does not reference, get_by_uuid returns nothing and Nova raises InstanceNotFound even though the row physically exists.