🚨 OpenStack Error Guide: 'Build of instance aborted' Nova Spawn Failure

Overview

A “Build of instance aborted” error means Nova hit a failure during spawn that it considers non-reschedulable and gave up on the build immediately, instead of trying another compute host. The instance goes straight to ERROR and its fault message names a specific reason.

You will see this in the instance fault or nova-compute log:

Build of instance 7c9e2f1a-44bb-4c0d-9e21-aa1122334455 aborted: Failed to allocate the network(s), not rescheduling.

Other common variants name a volume or image cause:

Build of instance 7c9e2f1a-... aborted: Volume 6d3a... did not finish being created even after we waited 187 seconds or 61 attempts. And its status is error.
Build of instance 7c9e2f1a-... aborted: Image <id> is unacceptable: Image disk size is larger than flavor root disk.

The key signal is the trailing “not rescheduling” / “aborted” wording. Nova distinguishes retryable failures (it reschedules to another host) from terminal failures (it aborts). Understanding which class you have tells you whether to look at one host or at the cluster.

Symptoms

• Instance transitions BUILD to ERROR with a fault message containing “aborted”.
• The fault text names a concrete reason: network, volume, image, or block device.
• No reschedule attempts appear in the scheduler log for that instance (contrast with “Exceeded maximum number of retries”).
• nova-compute logs show a BuildAbortException rather than a RescheduledException.

openstack server show app-07 -c fault -f value

{'code': 500, 'created': '2026-06-24T10:14:02Z', 'message': 'Build of instance 7c9e2f1a-... aborted: Failed to allocate the network(s), not rescheduling.', 'details': '...'}

openstack server show app-07 -c "OS-EXT-SRV-ATTR:host" -c status -f value

compute-04
ERROR

Common Root Causes

1. Network allocation failed (the most common abort)

When Nova cannot finish wiring the instance’s ports, it raises BuildAbortException with “Failed to allocate the network(s), not rescheduling.” This is deliberately terminal because re-running on another host rarely helps if the cause is a Neutron port binding failure or a vif-plugging timeout.

# Kolla-Ansible (compute host)
docker logs nova_compute 2>&1 | grep -i "Failed to allocate network" | tail -5
# Traditional packages
sudo journalctl -u nova-compute --no-pager | grep -i "Failed to allocate network" | tail -5

ERROR nova.compute.manager [instance: 7c9e2f1a-...] Instance failed network setup after 1 attempt(s): nova.exception.VirtualInterfaceCreateException: Virtual Interface creation failed

2. Volume / block device mapping (BDM) failure

Boot-from-volume or extra attached volumes that never reach available cause an abort. Nova polls Cinder and gives up after block_device_allocate_retries x block_device_allocate_retries_interval.

openstack volume show 6d3a-... -c status -c error -f value

error

Build of instance 7c9e2f1a-... aborted: Volume 6d3a... did not finish being created even after we waited 187 seconds or 61 attempts. And its status is error.

Inspect the Cinder volume service and backend for the real failure (full pool, dead cinder-volume, backend auth).

3. Image problems (unacceptable, missing, or corrupt)

A deleted Glance image, a checksum mismatch, or an image whose minimum disk/RAM exceeds the flavor produces a terminal abort.

openstack image show <IMAGE_ID> -c status -c min_disk -c min_ram -c size -f value

Build of instance 7c9e2f1a-... aborted: Image <id> is unacceptable: Image disk size is larger than flavor root disk.

4. Insufficient/invalid resources on the selected host

A flavor requesting more PCI/NUMA/hugepage resources than the claimed host can satisfy at spawn time (after the scheduler already picked it) aborts rather than reschedules in some releases.

docker logs nova_compute 2>&1 | grep -iE "Claim|PCI|NUMA|hugepage" | tail -10

5. Hypervisor / libvirt spawn errors

libvirt failing to define or start the domain (missing CPU feature, bad emulator path, AppArmor/SELinux denial) surfaces as a build abort with a libvirt traceback.

docker logs nova_compute 2>&1 | grep -iE "libvirtError|Failed to start domain" | tail -10
sudo journalctl -u libvirtd --no-pager | tail -30

6. Metadata or config-drive creation failure

If config-drive generation fails (no space, missing genisoimage/mkisofs) or the metadata service is unreachable for first-boot, the spawn aborts.

docker logs nova_compute 2>&1 | grep -iE "config drive|configdrive|metadata" | tail -10

Diagnostic Workflow

Step 1: Read the full fault and confirm it is an abort

openstack server show <SERVER> -c fault -f value

The word “aborted” (and often “not rescheduling”) confirms a terminal failure. The reason after the colon is your starting point.

Step 2: Find the compute host and pull its nova-compute log

openstack server show <SERVER> -c "OS-EXT-SRV-ATTR:host" -f value

# Kolla-Ansible (on that host)
docker logs nova_compute 2>&1 | grep "<INSTANCE_UUID>" | tail -60
# Traditional
sudo journalctl -u nova-compute --no-pager | grep "<INSTANCE_UUID>" | tail -60

Read the chain top-down: claim, network setup, BDM/volume wait, image fetch, libvirt spawn. The first ERROR in that sequence is the real cause; the BuildAbortException is just the summary.

Step 3: Branch on the reason

• “Failed to allocate the network(s)”: jump to Neutron — check port binding and vif_plugging_timeout.
• “Volume … did not finish being created”: inspect the Cinder volume and cinder-volume service.
• “Image … is unacceptable” / image errors: validate the Glance image and flavor sizing.

Step 4: Inspect the dependent service

# Network path
openstack port list --server <SERVER>
openstack network agent list
# Volume path
openstack volume show <VOL_ID> -c status -c error -f value
openstack volume service list
# Image path
openstack image show <IMAGE_ID> -c status -c checksum -f value

Step 5: Fix the root cause and rebuild or recreate

An aborted instance cannot be rescheduled, so fix the dependency and rebuild (same instance) or delete and recreate:

openstack server rebuild <SERVER>
# or
openstack server delete <SERVER> && openstack server create ...

Example Root Cause Analysis

A user reports db-replica-02 stuck in ERROR. The fault reads:

Build of instance 9a8b7c6d-... aborted: Volume 4f2e... did not finish being created even after we waited 187 seconds or 61 attempts. And its status is error.

This is the BDM/volume abort path, not a host problem, so we look at Cinder rather than rescheduling:

openstack volume show 4f2e... -c status -c error -f value

error
None

The cinder-volume log on the storage node shows the backend pool is out of space:

ERROR cinder.volume.manager Create volume failed: VolumeBackendAPIException: Failed to create volume: insufficient space on pool 'rbd-fast'

The root disk request landed on a Ceph pool that hit its quota. Nova waited the full retry window, the volume went to error, and the build aborted. Fix: free/expand the pool, delete the failed volume, and recreate the instance:

openstack volume delete 4f2e...
openstack server delete db-replica-02
openstack server create --flavor m1.large --image ubuntu-22.04 \
  --boot-from-volume 40 --network internal db-replica-02

The new volume provisions cleanly and the instance reaches ACTIVE.

Prevention Best Practices

• Alert on Cinder backend capacity and cinder-volume health; most volume aborts are full pools or a dead volume service, not Nova.
• Monitor Neutron agent liveness so network-allocation aborts (the most common kind) are caught before users hit them.
• Validate images at upload: enforce checksums and sane min_disk/min_ram so an oversized or corrupt image cannot abort builds later.
• Tune block_device_allocate_retries only after fixing the backend — longer waits just delay the same abort.
• Pre-flight new compute hosts with a boot-from-volume smoke test so libvirt, config-drive, and BDM paths are all exercised.
• For fast triage, the free incident assistant can summarize a nova-compute abort chain into the likely subsystem. See more in OpenStack guides.

Quick Command Reference

# Read the abort reason
openstack server show <SERVER> -c fault -f value

# Find the host and pull the compute log
openstack server show <SERVER> -c "OS-EXT-SRV-ATTR:host" -f value
docker logs nova_compute 2>&1 | grep "<INSTANCE_UUID>" | tail -60
sudo journalctl -u nova-compute | grep "<INSTANCE_UUID>" | tail -60

# Network-path checks
openstack port list --server <SERVER>
openstack network agent list

# Volume-path checks
openstack volume show <VOL_ID> -c status -c error -f value
openstack volume service list

# Image-path checks
openstack image show <IMAGE_ID> -c status -c min_disk -c min_ram -c size -f value

# Recover (aborts are not reschedulable)
openstack server rebuild <SERVER>

Conclusion

“Build of instance aborted” is Nova telling you a spawn failure was terminal and it deliberately did not reschedule. The reason after the colon points at the subsystem:

1. Network allocation failure (most common) — a Neutron port binding or vif-plugging problem.
2. Volume/BDM failure — a volume that never reached available (full pool, dead cinder-volume).
3. Image issues — deleted, corrupt, or oversized relative to the flavor.
4. Resource claim failures — PCI/NUMA/hugepage shortfalls on the chosen host.
5. libvirt/hypervisor spawn errors.
6. Config-drive or metadata creation failures.

Read the nova-compute chain for the instance UUID, find the first ERROR, and fix that dependency — an aborted build will not retry itself, so recreate or rebuild once the cause is resolved.