Skip to content
Calcrivo

OpenStack Nova Capacity Calculator

Size Nova compute capacity using the cpu and ram allocation ratios, reserved host memory and a chosen flavor.

Inputs

nodes
cores
ratio

Nova defaults to 16.0, which is far too aggressive for production.

GiB
ratio

Nova defaults to 1.5; above 1.0 the host can swap.

MiB

Held back for the hypervisor and agents; the default 512 MiB is usually too low.

vCPU
GiB

Instances Supported

576instances

Schedulable vCPUs

2,304vCPU

Schedulable Memory

5,472.0GiB

Ceiling from cpu_allocation_ratio

576instances

Ceiling from ram_allocation_ratio

684instances

Limiting Ratio

cpu_allocation_ratio is the limit — raise it or add cores

Step by step

  1. Values used

    Compute nodes = 12 nodes; Physical cores per node = 48 cores; cpu_allocation_ratio = 4 ratio; Memory per node = 384 GiB; ram_allocation_ratio = 1.20 ratio; reserved_host_memory_mb = 4,096 MiB; vCPUs in the flavor = 4 vCPU; Memory in the flavor = 8 GiB

  2. OpenStack Nova Capacity

    schedulable vCPUs = nodes × cores × cpu_allocation_ratio; schedulable RAM = nodes × (node RAM − reserved_host_memory) × ram_allocation_ratio; instances is the lower of each divided by the flavor.

  3. Instances Supported

    = 576 instances

  4. Schedulable vCPUs

    = 2,304 vCPU

  5. Schedulable Memory

    = 5,472.0 GiB

  6. Ceiling from cpu_allocation_ratio

    = 576 instances

  7. Ceiling from ram_allocation_ratio

    = 684 instances

  8. Limiting Ratio

    = cpu_allocation_ratio is the limit — raise it or add cores

How it works

The Nova scheduler's core filters multiply each node's physical resources by the allocation ratios to produce a schedulable pool, after subtracting reserved_host_memory_mb from RAM. Instance count is then the pool divided by the flavor, taken as the smaller of the CPU and memory answers — and because placement is per-node, a fragmented cluster will hit the wall before the arithmetic says so. Nova ships with cpu_allocation_ratio 16.0 and ram_allocation_ratio 1.5, which will happily oversubscribe a production cloud into swap; setting these deliberately is one of the highest-impact configuration decisions in an OpenStack deployment.

Formula

OpenStack Nova Capacity

schedulable vCPUs = nodes × cores × cpu_allocation_ratio; schedulable RAM = nodes × (node RAM − reserved_host_memory) × ram_allocation_ratio; instances is the lower of each divided by the flavor.

cpu_allocation_ratio
How many vCPUs Nova will schedule per physical core
ram_allocation_ratio
Memory overcommit Nova permits; above 1.0 risks host swap
reserved_host_memory_mb
Memory excluded from scheduling for the hypervisor itself

Frequently Asked Questions

How is OpenStack Nova Capacity calculated?

schedulable vCPUs = nodes × cores × cpu_allocation_ratio; schedulable RAM = nodes × (node RAM − reserved_host_memory) × ram_allocation_ratio; instances is the lower of each divided by the flavor. The Nova scheduler's core filters multiply each node's physical resources by the allocation ratios to produce a schedulable pool, after subtracting reserved_host_memory_mb from RAM. Instance count is then the pool divided by the flavor, taken as the smaller of the CPU and memory answers — and because placement is per-node, a fragmented cluster will hit the wall before the arithmetic says so.

Why does OpenStack Nova Capacity matter?

Nova ships with cpu_allocation_ratio 16.0 and ram_allocation_ratio 1.5, which will happily oversubscribe a production cloud into swap; setting these deliberately is one of the highest-impact configuration decisions in an OpenStack deployment.

What values do I need to enter?

This calculator takes 8 inputs: Compute nodes, Physical cores per node, cpu_allocation_ratio, Memory per node, ram_allocation_ratio, reserved_host_memory_mb, vCPUs in the flavor, Memory in the flavor. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Why can the real instance count be lower than this figure?

Nova places instances on whole nodes, so capacity spread thinly across many nodes may not accommodate a large flavor even when the cluster total looks sufficient. This fragmentation effect is why operators keep a per-node headroom target as well as a cluster one.

You might also need