☁️ OpenStack Error: Placement 'inventory in use' 409 Conflict Updating Resource Provider

Exact Error Message

$ openstack resource provider inventory set <rp-uuid> \
    --resource VCPU=32:16
Conflict (HTTP 409) (Request-ID: req-9c2f...): Update conflict: Inventory
for 'VCPU' on resource provider '<rp-uuid>' in use.

The placement-api log records the same rejection:

INFO placement.requestlog [req-9c2f...] 10.0.0.11 "PUT
/resource_providers/<rp-uuid>/inventories" status: 409 len: 312
WARNING placement.handlers.inventory [req-9c2f...] Cannot delete/modify
inventory of class VCPU: there are allocations against it.

What It Means

The Placement service tracks how much of each resource class (VCPU, MEMORY_MB, DISK_GB, PCI devices, and so on) a resource provider — usually a nova-compute host — advertises, and how much is currently allocated to consumers (instances, migrations). A 409 inventory in use means you tried to lower or delete an inventory below what is already allocated, or remove a resource class that still has live allocations against it.

Placement refuses because honoring the change would leave existing instances allocated against capacity that no longer exists, corrupting the scheduler’s accounting. The conflict is a safety check: you cannot shrink total below used, and you cannot drop a class while consumers hold allocations of it.

Common Causes

• You tried to set total (or total:reserved) below the amount already allocated to running instances.
• You attempted to delete an entire resource class that still has allocations.
• Orphaned allocations remain from instances that were deleted uncleanly or a migration that never completed.
• A failed/aborted live migration left double allocations on the source and destination providers.
• A leaked allocation from a compute service that was deleted without draining its instances.
• Manual inventory edits that ignore the current used value reported by Placement.

Diagnostic Commands

Show the provider’s current inventory, including used vs. total:

openstack resource provider inventory list <rp-uuid>
openstack resource provider usage show <rp-uuid>

List every allocation held against the provider and who owns it:

openstack resource provider show <rp-uuid> --allocations

Cross-check each consumer UUID against Nova to spot orphans (a consumer with no matching server is a leaked allocation):

openstack server show <consumer-uuid> -f value -c name 2>/dev/null \
  || echo "ORPHAN allocation: <consumer-uuid>"

Find stuck migrations that commonly leave double allocations:

openstack server migration list --status running
nova-manage placement audit --verbose

Step-by-Step Resolution

1. Compare used against the total you are trying to set. If used (say 20 VCPU) exceeds your target total (16), Placement is correct to refuse — you must free allocations first or pick a higher total.

2. Identify orphaned allocations. Run the built-in audit, which reports allocations whose consumer no longer exists as an instance:

nova-manage placement audit --verbose

3. Heal legitimate accounting drift automatically before editing inventory:

nova-manage placement heal_allocations --verbose

4. For a confirmed orphan (consumer has no server and no live migration), delete just that allocation so it stops holding capacity:

openstack resource provider allocation unset <consumer-uuid> \
  --provider <rp-uuid> --resource-class VCPU

5. Resolve stuck migrations that pin double allocations. Confirm or abort the migration through Nova rather than deleting allocations by hand:

openstack server migration abort <server-id> <migration-id>

6. Once used is at or below your new target, re-apply the inventory. Setting total:reserved is the correct way to shrink usable capacity without falling under used:

openstack resource provider inventory set <rp-uuid> --resource VCPU=32:8
openstack resource provider usage show <rp-uuid>

Prevention

• Always read openstack resource provider usage show before changing inventory, and never set total below the current used.
• Use the reserved field to fence off capacity instead of lowering total under live allocations.
• Drain and disable a compute host (openstack compute service set --disable) and migrate its instances before deleting the service or its provider.
• Schedule periodic nova-manage placement audit runs to catch orphaned allocations early.
• After any failed live migration, verify allocations on both source and destination providers and abort/confirm the migration cleanly.

Related Errors

• 409 Conflict: resource provider ... has inventory in use when deleting a whole provider — same allocation guard at the provider level.
• No valid host was found from the scheduler — often the downstream symptom of leaked allocations eating capacity.
• Unable to delete compute node ... because there are allocations in nova-compute logs.
• 409 Conflict: Inventory for 'MEMORY_MB' ... in use — the memory-class variant of this same error.

Frequently Asked Questions

Why can’t I lower a host’s VCPU inventory? Placement will not let total drop below the amount already allocated to running instances (used). Free or migrate those allocations first, or use the reserved field to reduce usable capacity without going under used.

How do I find orphaned allocations? Run nova-manage placement audit --verbose; it lists allocations whose consumer UUID no longer maps to a live instance. Those are the leaked ones safe to clean up after verification.

Is it safe to delete an allocation by hand? Only after confirming the consumer is neither a running server (openstack server show fails) nor an active migration. Deleting a live allocation will let the scheduler oversubscribe the host.

What causes double allocations? A live migration that aborts or crashes can leave allocations on both the source and destination provider. Abort or confirm the migration through Nova to release the extra set.

Where can I learn more? Explore the full OpenStack guides for Nova and Placement troubleshooting, and grab a ready-to-run investigation prompt from the prompt library.