🚨 OpenStack Error Guide: 'Failed to allocate the network(s)' Nova/Neutron Setup Failure

Overview

“Failed to allocate the network(s)” is the Nova-side error you get when the compute host cannot finish wiring an instance’s networking during spawn. Nova asks Neutron to create and bind ports, plugs the VIFs into the hypervisor, and waits for Neutron to confirm the ports are live. If any of that fails or times out, Nova raises BuildAbortException with “not rescheduling” and the instance goes to ERROR.

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.

And just above it, the underlying compute-side error:

ERROR nova.compute.manager [instance: 7c9e2f1a-...] Instance failed network setup after 1 attempt(s): nova.exception.VirtualInterfaceCreateException: Virtual Interface creation failed
WARNING nova.virt.libvirt.driver [instance: 7c9e2f1a-...] Timeout waiting for [('network-vif-plugged', 'a1b2c3d4-...')] for instance with vm_state building

This is the Nova view of a networking problem. A Neutron port binding failure is one cause, but the timeout, dead-agent, and Neutron-unreachable cases all surface here too. This guide focuses on the Nova-side allocation failure and the chain that leads to it.

Symptoms

• Instance fault contains “Failed to allocate the network(s), not rescheduling.”
• nova-compute logs VirtualInterfaceCreateException or “Timeout waiting for network-vif-plugged”.
• The instance’s ports exist but stay DOWN, or show binding_failed.
• It is terminal: Nova does not reschedule, so the instance lands directly in ERROR.

openstack server show web-01 -c fault -f value

{'code': 500, 'message': 'Build of instance 7c9e2f1a-... aborted: Failed to allocate the network(s), not rescheduling.', ...}

openstack port list --server web-01 -c ID -c "Status" -c "Fixed IP Addresses" -f value

a1b2c3d4-1111-2222-3333-444455556666 DOWN  192.168.10.42

Common Root Causes

1. vif-plugging timeout (the classic case)

After plugging the VIF, Nova waits for Neutron to send a network-vif-plugged event for up to vif_plugging_timeout (default 300s). If the event never arrives and vif_plugging_is_fatal = True, Nova aborts with this error.

grep -E '^\s*(vif_plugging_timeout|vif_plugging_is_fatal)' /etc/nova/nova.conf
docker logs nova_compute 2>&1 | grep -i "Timeout waiting for .*network-vif-plugged" | tail -5

vif_plugging_timeout = 300
vif_plugging_is_fatal = True

The missing event almost always means the L2 agent never reported the port as wired (next cause), or notify_nova_on_port_status_changes is off in Neutron.

2. The L2 agent on the compute host is dead

If the OVS/Linuxbridge agent on the target host is down, it never wires the port and never triggers the vif-plugged notification, so Nova times out.

openstack network agent list --host compute-03

+--------+--------------------+------------+-------+-------+
| ID     | Agent Type         | Host       | Alive | State |
+--------+--------------------+------------+-------+-------+
| 9f1a.. | Open vSwitch agent | compute-03 | XXX   | UP    |
+--------+--------------------+------------+-------+-------+

Alive = XXX is the prime suspect. Restart the agent:

# Kolla-Ansible
docker restart neutron_openvswitch_agent
# Traditional packages
sudo systemctl restart neutron-openvswitch-agent

3. Port binding failed underneath

If Neutron could not bind the port to the host, the VIF type is binding_failed and Nova cannot create the interface, producing this allocation failure on the Nova side.

openstack port show <PORT_ID> -c binding_vif_type -c binding_host_id -f value

binding_failed
compute-03

See the dedicated port binding failure guide for the ML2/bridge-mapping side.

4. neutron-server unreachable or overloaded

If nova-compute cannot reach the Neutron API (down, slow, RabbitMQ backlog), port create/bind calls fail or time out and allocation aborts.

docker logs nova_compute 2>&1 | grep -iE "neutronclient|ConnectionFailed|Unable to .*Neutron" | tail -10
openstack network agent list >/dev/null && echo "neutron API reachable"

ERROR nova.network.neutron Neutron client was not able to generate a valid admin token... ConnectFailure: Unable to establish connection to http://controller:9696

5. Subnet IP exhaustion or no subnet on the network

If the network/subnet has no free IPs (or the network has no subnet at all), Neutron cannot allocate a fixed IP for the port and the allocation fails.

openstack subnet show <SUBNET_ID> -c allocation_pools -c cidr -f value
openstack ip availability show <NETWORK_ID>

+------------------+-------+--------+--------------+
| Subnet           | Total | Used   | Free         |
+------------------+-------+--------+--------------+
| internal-subnet  | 254   | 254    | 0            |

6. DHCP / metadata agent missing, or security groups blocking

A network with no live DHCP agent leaves the port DOWN (instance boots with no lease); a missing metadata agent breaks first-boot config. Over-restrictive default security groups can also leave an interface unusable even when the port is allocated.

openstack network agent list --agent-type dhcp
openstack network agent list --agent-type metadata
openstack security group rule list default

Diagnostic Workflow

Step 1: Confirm the Nova-side error and find the host

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

“Failed to allocate the network(s), not rescheduling” confirms a Nova network-setup failure; note the compute host.

Step 2: Inspect the port(s) for the instance

openstack port list --server <SERVER> -c ID -c Status -f value
openstack port show <PORT_ID> -c binding_vif_type -c binding_host_id -c status -f value

• binding_failed -> binding problem (jump to Step 4).
• DOWN with a valid VIF type -> vif-plugging/agent problem (Step 3).

Step 3: Check the L2 agent and look for the missing vif-plugged event

openstack network agent list --host <HOST>
# Kolla-Ansible
docker logs nova_compute 2>&1 | grep -iE "vif-plugged|VirtualInterfaceCreate" | tail -10
docker logs neutron_openvswitch_agent 2>&1 | tail -40
# Traditional
sudo journalctl -u neutron-openvswitch-agent --no-pager | tail -40

A dead agent or no network-vif-plugged event explains a timeout-driven abort.

Step 4: Verify Neutron reachability and IP availability

docker logs nova_compute 2>&1 | grep -iE "neutron|ConnectFailure" | tail -10
openstack ip availability show <NETWORK_ID>
openstack network agent list --agent-type dhcp

Step 5: Fix the cause, then recreate or rebuild

This abort is not rescheduled, so once the agent/Neutron/subnet issue is resolved, rebuild or recreate:

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

If you need a non-fatal stopgap while diagnosing flaky vif events, you can set vif_plugging_is_fatal = False (instances boot without confirmation) — but treat that as temporary, not a fix.

Example Root Cause Analysis

web-04 lands on compute-03 and fails with “Failed to allocate the network(s), not rescheduling.” The compute log shows a timeout, not a binding failure:

WARNING nova.virt.libvirt.driver [instance: 8c2d-...] Timeout waiting for [('network-vif-plugged', 'b7e9-...')] for instance with vm_state building
ERROR nova.compute.manager [instance: 8c2d-...] Instance failed network setup after 1 attempt(s)

The port itself bound fine (binding_vif_type is ovs, not binding_failed), so this is a missing vif-plugged event. Checking the agent on that host:

openstack network agent list --host compute-03

| 9f1a.. | Open vSwitch agent | compute-03 | XXX | UP |

The OVS agent on compute-03 died after a recent OVS upgrade, so it wired no ports and emitted no notifications. Nova waited the full 300s and aborted. Fix: restart the agent and rebuild:

docker restart neutron_openvswitch_agent
openstack network agent list --host compute-03   # confirm Alive = :-)
openstack server rebuild web-04

The port goes ACTIVE, the vif-plugged event arrives, and the instance reaches ACTIVE.

Prevention Best Practices

• Alert on Neutron L2/DHCP agent liveness; a dead agent is the single most common cause of vif-plugging timeouts and this abort.
• Monitor subnet IP availability and alert before pools hit zero — exhausted subnets silently break new builds.
• Keep notify_nova_on_port_status_changes = True in Neutron so vif-plugged events actually fire; without it, Nova always times out.
• Tune vif_plugging_timeout to your fabric, but never paper over the problem with vif_plugging_is_fatal = False in production.
• Pre-flight new or upgraded compute hosts with a smoke-test instance so a broken agent is caught before real workloads land.
• For fast triage, the free incident assistant can correlate the Nova abort with the Neutron-side cause. See more in OpenStack guides.

Quick Command Reference

# Confirm the Nova-side failure and host
openstack server show <SERVER> -c fault -c "OS-EXT-SRV-ATTR:host" -f value

# Inspect the instance ports
openstack port list --server <SERVER> -c ID -c Status -f value
openstack port show <PORT_ID> -c binding_vif_type -c status -f value

# Agent health on the host + the missing vif-plugged event
openstack network agent list --host <HOST>
docker logs nova_compute 2>&1 | grep -iE "vif-plugged|VirtualInterfaceCreate" | tail -10

# Neutron reachability and IP availability
docker logs nova_compute 2>&1 | grep -iE "neutron|ConnectFailure" | tail -10
openstack ip availability show <NETWORK_ID>
openstack network agent list --agent-type dhcp

# Relevant config
grep -E 'vif_plugging_timeout|vif_plugging_is_fatal' /etc/nova/nova.conf

# Restart the L2 agent and recover
docker restart neutron_openvswitch_agent
sudo systemctl restart neutron-openvswitch-agent
openstack server rebuild <SERVER>

Conclusion

“Failed to allocate the network(s), not rescheduling” is Nova reporting that it could not finish wiring an instance’s networking, and it deliberately aborts rather than retrying. The chain almost always resolves to a Neutron-side cause:

1. A vif-plugging timeout because the network-vif-plugged event never arrived.
2. A dead L2 agent on the compute host that never wired the port.
3. An underlying port binding_failed.
4. neutron-server unreachable or overloaded.
5. Subnet IP exhaustion or a network with no subnet.
6. Missing DHCP/metadata agents or blocking security groups.

Start from the instance’s ports: binding_failed points at binding, a DOWN port with a good VIF type points at a dead agent or a missing vif-plugged event. Fix the Neutron side, then rebuild — this abort never reschedules itself.