🚨 OpenStack Error Guide: 'Quota exceeded' for cores, RAM, instances, ports, and floating IPs

Overview

A Quota exceeded failure stops a launch, a network attach, or a floating-IP allocation the moment a project’s accounted usage of a resource meets its limit. The literal errors differ by service and resource:

Quota exceeded for cores: Requested 8, but already used 56 of 64 cores (HTTP 403)
Quota exceeded for ram: Requested 16384, but already used 122880 of 131072 ram (HTTP 403)
Quota exceeded for instances: Requested 1, but already used 20 of 20 instances (HTTP 403)
OverQuota: Quota exceeded for resources: ['port']. (HTTP 409)
FloatingIpLimitExceeded: Maximum number of floating IPs exceeded. (HTTP 409)

It occurs whenever the project’s configured quota limit is reached — but the tricky part is that the accounted usage may not match the actual usage. Stale or leaked resources, oversubscription, and quota-usage drift all cause Quota exceeded to fire even when the operator believes there is headroom.

Symptoms

• openstack server create returns HTTP 403 with Quota exceeded for cores/ram/instances.
• openstack port create or attaching an interface returns HTTP 409 OverQuota.
• openstack floating ip create returns FloatingIpLimitExceeded.
• Usage looks wrong: the dashboard shows the project at its limit but the team insists they deleted those instances.

openstack quota show <project-id>

+----------------------+--------+
| Field                | Value  |
+----------------------+--------+
| cores                | 64     |
| ram                  | 131072 |
| instances            | 20     |
| ports                | 50     |
| floating-ips         | 10     |
+----------------------+--------+

openstack limits show --absolute --project <project-id> \
  -f value -c Name -c Value | grep -iE 'core|ram|instance'

maxTotalCores       64
totalCoresUsed      56
maxTotalRAMSize     131072
totalRAMUsed        122880
maxTotalInstances   20
totalInstancesUsed  20

When totalInstancesUsed equals maxTotalInstances, the next launch is rejected outright.

Common Root Causes

1. Tenant quota limit genuinely reached

The simplest case: the project is using everything it is allowed.

openstack limits show --absolute --project <project-id>

| maxTotalInstances  | 20 |
| totalInstancesUsed | 20 |

The fix is either to free resources or raise the quota — but confirm the usage is real first (root cause 3 below).

2. Stale / leaked resources not reclaimed

Ports, floating IPs, and volumes frequently outlive the instances that used them, silently consuming quota.

# Ports not attached to any device (leaked from deleted VMs)
openstack port list --project <project-id> -f value -c ID -c device_owner -c status \
  | grep -i 'down\|^$'
# Floating IPs allocated but not associated
openstack floating ip list --project <project-id> --status DOWN

2f9a3c6d-8e41-4b10-bb10-77b2c1e44a0 |              | DOWN
8c6e0a1f-7b22-4d0e-9b21-1f334a7d2c9 | network:dhcp | DOWN

Each of these still counts against the ports / floating-ips quota.

3. Quota usage drift vs actual resources

Nova and Neutron track usage in counters that can drift away from reality after failed operations, races, or database edits. The accounted usage exceeds the real count.

# What Nova thinks is used vs what actually exists
openstack limits show --absolute --project <project-id> -f value -c Name -c Value \
  | grep -i instancesused
openstack server list --project <project-id> --all-projects -f value -c ID | wc -l

totalInstancesUsed  20
# actual servers:
14

A gap of 6 between accounted and actual usage is drift — the quota counter never decremented when those instances were deleted.

4. Oversubscription / large flavor request

A single large flavor can exhaust cores or ram long before instances.

openstack flavor show <flavor> -c vcpus -c ram
openstack limits show --absolute --project <project-id> -f value -c Name -c Value \
  | grep -iE 'core|ram'

Quota exceeded for cores: Requested 16, but already used 56 of 64 cores (HTTP 403)

Requesting a 16-vCPU flavor with only 8 cores of headroom fails even though there is plenty of RAM and instance count.

5. Neutron port / floating-IP quota distinct from Nova

Neutron enforces its own quotas. A launch can pass Nova’s checks and still fail on Neutron’s ports or floating-ips.

openstack quota show <project-id> -c ports -c floating-ips -c routers -c networks
openstack port list --project <project-id> -f value -c ID | wc -l

OverQuota: Quota exceeded for resources: ['port']. (HTTP 409)

6. Default quota too low for the workload

New projects inherit the deployment defaults, which are often smaller than production workloads need.

# The class-wide defaults a new project inherits
openstack quota show --default

| instances | 10 |
| cores     | 20 |
| ram       | 51200 |

A team running 15 VMs hits the default instances: 10 wall immediately.

Diagnostic Workflow

Step 1: Read both the limit and the accounted usage

openstack limits show --absolute --project <project-id>
openstack quota show <project-id>

Identify exactly which resource is at its ceiling — cores, ram, instances, ports, or floating-ips.

Step 2: Count the actual resources in use

openstack server list --project <project-id> --all-projects -f value -c ID | wc -l
openstack port list --project <project-id> -f value -c ID | wc -l
openstack floating ip list --project <project-id> -f value -c ID | wc -l

Compare these to the accounted usage from Step 1. A mismatch is drift or leaks.

Step 3: Hunt for leaked / stale resources

openstack port list --project <project-id> --status DOWN
openstack floating ip list --project <project-id> --status DOWN
openstack volume list --project <project-id> --all-projects --status available

Step 4: Check the service logs for the rejection

# Nova (Kolla-Ansible)
docker logs nova_api 2>&1 | grep -i "over quota\|quota exceeded" | tail
# Nova (traditional)
journalctl -u openstack-nova-api | grep -i "over quota\|quota exceeded" | tail
# Neutron (Kolla-Ansible / traditional)
docker logs neutron_server 2>&1 | grep -i "overquota" | tail
journalctl -u neutron-server | grep -i "overquota" | tail

2026-06-23 16:02:14.551 7 INFO nova.api.openstack.wsgi [req-...] HTTP exception thrown:
Quota exceeded for cores: Requested 16, but already used 56 of 64 cores

Step 5: Reconcile drift or adjust the quota

For drift, delete the leaked resources (which decrements the counter) or, if the counter itself is wrong, recalculate it. For a genuine capacity need, raise the quota:

# Free leaked resources
openstack floating ip delete <fip-id>
openstack port delete <port-id>
# Or raise the limit
openstack quota set --cores 128 --ram 262144 --instances 40 <project-id>

Example Root Cause Analysis

A team reports they cannot launch a new instance — Quota exceeded for instances: already used 20 of 20 — yet they swear only 14 VMs are running. The scenario:

1. openstack limits show --absolute confirms totalInstancesUsed: 20, maxTotalInstances: 20.

2. The actual count tells a different story:

openstack server list --project <project-id> --all-projects -f value -c ID | wc -l

14

3. Investigation — six instances were deleted earlier in the day during a failed batch operation. The Nova quota counter did not decrement because the deletes raced with a control-plane restart, leaving the accounting six instances high. This is classic quota-usage drift: the accounted usage (20) exceeds the real usage (14).

4. Fix — recalculate the project’s quota usage so the counter matches reality, then confirm:

# Refresh the per-project usage counters (modern Nova counts resources live;
# on deployments with cached counts, the admin refresh path is:)
openstack quota show <project-id> --usage 2>/dev/null
nova-manage placement heal_allocations --project-id <project-id>   # if allocations also drifted
openstack limits show --absolute --project <project-id> -f value -c Name -c Value \
  | grep -i instancesused

totalInstancesUsed  14

The counter now reads 14 and launches succeed. If the deployment still showed drift, the durable fix is to ensure deletes complete cleanly (root cause 2) rather than editing counters by hand.

Prevention Best Practices

• Periodically reconcile accounted usage against actual resources per project and alert on any gap — drift is invisible until someone hits the wall.
• Sweep for leaked ports, unassociated floating IPs, and orphaned available volumes on a schedule and reclaim them.
• Set per-project quota defaults that match the intended workload tier instead of leaving everyone on the deployment default.
• Alert when a project crosses ~85% of any quota dimension (cores, ram, instances, ports, floating-ips) so the team can request an increase before launches fail.
• Route quota-rejection events into a runbook or an automated triage flow such as /dashboard/incident-response/ so the responder sees accounted-vs-actual usage immediately.

# Quota utilization snapshot for alerting
for p in $(openstack project list -f value -c ID); do
  openstack limits show --absolute --project "$p" -f value -c Name -c Value \
    | grep -iE 'totalCoresUsed|maxTotalCores|totalInstancesUsed|maxTotalInstances'
done

Quick Command Reference

# Limits vs accounted usage
openstack quota show <project-id>
openstack limits show --absolute --project <project-id>

# Actual resource counts
openstack server list      --project <project-id> --all-projects -f value -c ID | wc -l
openstack port list        --project <project-id> -f value -c ID | wc -l
openstack floating ip list --project <project-id> -f value -c ID | wc -l

# Leak hunting
openstack port list        --project <project-id> --status DOWN
openstack floating ip list --project <project-id> --status DOWN
openstack volume list      --project <project-id> --all-projects --status available

# Logs
docker logs nova_api 2>&1       | grep -i "quota exceeded" | tail
docker logs neutron_server 2>&1 | grep -i "overquota" | tail
journalctl -u openstack-nova-api | grep -i "quota exceeded" | tail
journalctl -u neutron-server     | grep -i "overquota" | tail

# Reclaim or adjust
openstack floating ip delete <fip-id>
openstack port delete <port-id>
openstack quota set --cores 128 --ram 262144 --instances 40 <project-id>

Conclusion

When Nova or Neutron returns Quota exceeded, the typical root causes are:

1. The project genuinely reached its configured quota limit.
2. Stale or leaked resources (DOWN ports, unassociated floating IPs, orphaned volumes) are still consuming quota.
3. Quota-usage drift — the accounted counter is higher than the actual resource count.
4. A large-flavor request exhausted cores or ram before instances.
5. Neutron’s own ports/floating-ips quota fired even though Nova’s checks passed.
6. The inherited default quota is too low for the workload.

Always compare accounted usage to the real resource count before raising a limit — half of all Quota exceeded tickets are drift or leaks, not a true capacity shortfall. More OpenStack quota and capacity troubleshooting lives under /categories/openstack/.