Understanding OpenStack Nova Flavors
A Nova flavor is a named hardware profile that defines the compute resources available to a virtual machine instance. When you launch an instance in OpenStack, you select a flavor — and that flavor determines exactly how many virtual CPUs, how much RAM, and how much root disk storage the instance receives. Think of flavors as t-shirt sizes for your cloud infrastructure: rather than specifying exact resources on every launch, you define the available sizes once and reference them by name.
Unlike public cloud providers where instance types are fixed by the vendor, OpenStack gives you complete control over your flavor catalog. As an operator you decide what sizes make sense for your workloads, what naming convention to follow, and what resource ratios to target. This flexibility is one of OpenStack's core strengths — and also the source of most sizing mistakes.
Flavor components
vCPUs
Virtual CPU count assigned to the instance. On a shared host this is the number of CPU threads the hypervisor schedules for the VM. With CPU pinning (hw:cpu_policy=dedicated) each vCPU maps to a dedicated physical thread — no sharing.
RAM (MB)
Memory allocated to the instance in megabytes. Specified in MB in the API but the calculator handles conversion. Unlike CPU, RAM is not typically overcommitted — what the flavor specifies is what the instance gets. Sizing RAM conservatively avoids OOM events.
Root Disk (GB)
Size of the ephemeral root disk in gigabytes. Set to 0 to create a diskless flavor — used when instances boot from Cinder volumes. Ephemeral root disks live on the compute node's local storage and are destroyed when the instance is terminated.
Ephemeral Disk
Additional local ephemeral storage attached as a second disk. Useful for scratch space, swap, or temporary data. Like root disk, ephemeral storage is not persistent — data is lost on instance deletion. Formatted and mounted by cloud-init.
Swap (MB)
Swap partition size in megabytes, created as a separate ephemeral disk. Most production deployments set swap to 0 and rely on properly sized RAM instead. Heavy swap activity on a shared host degrades neighbor VMs, which makes swap-heavy flavors unpopular with operators.
Extra Specs
Key-value metadata that extends flavor behavior beyond basic resources. Controls CPU pinning, NUMA topology, huge pages, hardware RNG, PCI passthrough, and many other advanced features. Extra specs are matched against compute node capabilities via the Nova scheduler.
RAM to vCPU Ratios by Workload
The most consequential decision when designing a flavor catalog is the RAM-to-vCPU ratio. Every workload type has a natural ratio — the amount of memory the application needs relative to its CPU consumption. Choosing the wrong ratio forces users to either overprovision the scarce resource or launch multiple instances, both of which waste capacity.
| Workload Type |
Target Ratio |
Typical Range |
Rationale |
| General Purpose |
4 GB / vCPU |
2–8 GB / vCPU |
Balanced for mixed applications. Mirrors AWS m-family and GCP n2-standard sizing. Good default when workload characteristics are unknown. |
| Compute Optimized |
2 GB / vCPU |
1–4 GB / vCPU |
CPU-intensive work: scientific computing, video encoding, CI/CD build agents, HPC. Memory needs are modest relative to CPU demand. |
| Memory Optimized |
16 GB / vCPU |
8–32 GB / vCPU |
In-memory databases, Redis, Memcached, real-time analytics, large dataset processing. Memory is the primary resource constraint. |
| Database |
8 GB / vCPU |
4–16 GB / vCPU |
Relational databases (MySQL, PostgreSQL, Oracle) need significant buffer pool memory. NoSQL (MongoDB, Cassandra) falls in the same range. |
| Web / API Server |
4 GB / vCPU |
2–8 GB / vCPU |
Stateless web tier instances running Nginx, Apache, or application servers. CPU handling concurrent connections; moderate memory per worker. |
| Big Data |
8 GB / vCPU |
4–16 GB / vCPU |
Hadoop, Spark, and Kafka benefit from large JVM heap allocations. Executor memory should be sized generously to avoid disk spill. |
| GPU / AI-ML |
8 GB / vCPU |
4–32 GB / vCPU |
Training and inference workloads. Host RAM needs scale with model size and batch size. GPU passthrough requires additional extra spec configuration. |
Flavor Naming Conventions
OpenStack does not enforce a naming convention — you can name flavors anything. In practice, consistent naming becomes critical as your catalog grows. The most widely adopted convention mirrors the format this calculator generates: a workload prefix followed by vCPU count, RAM tier, and optional modifiers.
Standard prefix system
The most common approach uses single-letter prefixes borrowed from cloud provider conventions: m for general-purpose, c for compute-optimized, r for memory-optimized, d for database, g for GPU, w for web tier, and b for big data. This makes the flavor's target workload immediately obvious from the name.
Appending vCPU count and a RAM tier descriptor creates names like m.4.large (general purpose, 4 vCPU, large RAM), c.8.xlarge (compute optimized, 8 vCPU, extra-large RAM), or r.2.medium (memory optimized, 2 vCPU). The size tiers — nano, micro, small, medium, large, xlarge, 2xlarge — scale linearly within each family.
CPU pinning suffix
Flavors with dedicated CPU pinning are typically distinguished with a .pin suffix — for example c.8.xlarge.pin. This immediately signals to users that the flavor provides deterministic CPU performance and that it will only schedule on compute nodes configured for CPU pinning. Mixing pinned and shared flavors in the same name family without a suffix causes confusion and scheduling failures.
CPU Overcommit Ratios
CPU overcommit is the practice of assigning more vCPUs to instances than there are physical CPU threads on the host. Nova's default overcommit ratio is 16:1, meaning a 32-thread host can run instances totaling 512 vCPUs. Whether this is reasonable depends entirely on the workload.
Workloads with bursty, low-average CPU utilization — web servers handling intermittent traffic, development environments, CI runners sitting idle most of the day — can tolerate aggressive overcommit ratios of 8:1 to 16:1 without degradation. Workloads that sustain high CPU utilization — HPC jobs, video transcoding, database servers under load — should run at or near 1:1 to avoid CPU steal and unpredictable latency.
The Nova scheduler uses the cpu_allocation_ratio configuration value on each compute node to calculate available capacity. This calculator applies the overcommit ratio you specify to show effective vCPU counts and flag configurations that might cause scheduling pressure.
Advanced: NUMA Topology and Huge Pages
Modern multi-socket servers have non-uniform memory access (NUMA) architecture — CPU cores on one socket access local memory faster than memory attached to a different socket. For latency-sensitive workloads, pinning an instance to a single NUMA node eliminates cross-socket memory access and can significantly improve throughput.
Nova supports NUMA topology hints through flavor extra specs. Setting hw:numa_nodes=1 requests that all vCPUs and memory for the instance come from a single NUMA node. For instances requiring guaranteed NUMA placement, this extra spec must be combined with CPU pinning — NUMA hints without pinning are best-effort only.
Huge pages reduce TLB pressure by using 2MB or 1GB memory pages instead of the default 4KB pages. Applications that allocate large working sets — databases, in-memory caches, HPC applications — see measurable performance improvements with huge pages enabled. The extra spec hw:mem_page_size=large requests 2MB huge pages. Compute nodes must be pre-configured with huge page reservations for this to take effect.
Frequently Asked Questions
What is the difference between the openstack CLI and the nova legacy CLI?
The openstack unified client is the current standard, introduced with the OpenStack client project. It consolidates operations across all OpenStack services into a single command-line tool and is the recommended interface for all new deployments. The nova CLI is the original project-specific client, now considered legacy. It still works in most environments but receives fewer updates. For flavor management specifically, the commands produce identical results — the openstack client's openstack flavor create calls the same Nova API as the legacy nova flavor-create.
Can I modify an existing flavor after instances are already using it?
No. Nova flavors are immutable once created — you cannot change the vCPU, RAM, disk, or extra specs of a flavor that has been used to launch instances. The workaround is to create a new flavor with the desired specifications, migrate existing instances to the new flavor using cold migration or resize, and then delete the old flavor once it has no associated instances. This immutability is intentional: it ensures that instances have a consistent, stable resource definition throughout their lifetime.
What does setting root disk size to 0 mean?
A root disk of 0 creates a diskless flavor that does not provision any ephemeral root disk. Instances using a diskless flavor must boot from a Cinder block storage volume — the volume is attached as the root device and provides persistent storage. Diskless flavors are common in production environments where data persistence is required, because ephemeral root disks are destroyed when an instance is terminated. If you specify root disk as 0, you must provide a boot volume when launching the instance.
What is CPU policy dedicated mode and when should I use it?
CPU policy dedicated — set via the hw:cpu_policy=dedicated extra spec — pins each vCPU in the flavor to a specific physical CPU thread on the host. No other instance can use those threads, eliminating CPU steal and providing deterministic, consistent performance. Use dedicated mode for latency-sensitive workloads where performance variability is unacceptable: real-time applications, high-frequency trading, low-latency databases, or any workload where the "noisy neighbor" problem must be eliminated. The tradeoff is lower host utilization — a host running only pinned instances cannot overcommit its CPU.
How do I see what flavors are already defined in my OpenStack environment?
Use openstack flavor list to see all public flavors. Add --all to include private flavors. For the full details of a specific flavor including extra specs, run openstack flavor show <flavor-name-or-id>. Private flavors are visible only to specific projects — they are useful for creating specialized configurations that should not appear in the general catalog presented to all users.
What happens if I specify a flavor with more resources than any single compute node has?
Nova's scheduler will fail to place the instance and it will remain in an ERROR state with a "No valid host" error in the instance fault message. The scheduler evaluates each compute node's available capacity against the flavor requirements and rejects nodes that cannot satisfy the request. Common causes include flavors requiring more RAM than available on any host, CPU pinning requirements that cannot be satisfied given current NUMA topology, or huge page requests on hosts without huge page reservations. Reviewing Nova scheduler logs and the openstack host list output helps diagnose placement failures.