Skip to content

Flavors

A Flavor defines the virtual hardware of a VM — the number of vCPUs, the amount of RAM, and the size of the root disk. You pick a flavor when launching an instance.

Naming Scheme

Flavor names follow a scheme that encodes the family, generation, and resource sizes:

Prefix Family Description
g1.* Zero-Disk Boot from Volume — no integrated root disk. vCPUs and RAM are encoded in the name: g1.{vCPUs}c{RAM_GB}m (e.g. g1.2c4m = 2 vCPUs, 4 GB RAM).
m1.* / e1.* Standard General-purpose flavors with an integrated root disk (10–120 GB).
e1c.* Compute Compute-optimized — more vCPUs per GB of RAM.
e1m.* Memory Memory-optimized — more RAM per vCPU.
e1n.* Network Network-optimized — same specs as e1 but with enhanced network performance.
p1d.* / p1gd.* GPU GPU-enabled flavors.
a1.* / a1d.* Standard (Region 2) General-purpose x86 flavors in Region 2 (ch-ge1).
a1g6000d.* GPU (Region 2) GPU-enabled flavors in Region 2.

Tip

Zero-Disk flavors (g1.*) are recommended for most workloads. They boot from a persistent volume that can be resized, snapshotted, and survives instance deletion. See Standard vs Zero-Disk below.

Standard vs Zero-Disk Flavors

Standard Flavors have a persistent Boot Disk integrated in the offering alongside the vCPU, RAM, and IOPS specifications. For a possible expansion of storage, e.g., for data and programs, additional Volumes are simply added to these Flavors. These additional Volumes can be combined from various Volume Offerings that enable different maximum IOPS. Depending on the requirements, one or the other Flavor variant may make more sense.

The following table shows the differences between the Standard Flavors (with Disk) and the Zero-Disk Flavors.

Function Standard Flavors4 G - Flavors (Zero-Disk)5 Comment
Resize Instance Yes 1 Yes 2 * Resize Instance by changing Flavor
* Standard Flavor only from smaller to larger
* VM reboot required
Instance Snapshot Yes Yes 3
Volume Snapshot No Yes 3
Volume Backup No Yes

Footnotes

Flavor Lists

The available flavors differ between regions. Use openstack flavor list to see the current list in your project.

A complete list of all available flavors is available on our website:
Flavor Overview

Choosing a Flavor

  • General workloads — g1.* Zero-Disk flavors offer the most flexibility. Pick the vCPU/RAM combination that matches your workload, and size the boot volume independently.
  • CPU-intensive workloads (CI/CD, batch processing) — e1c.* Compute flavors provide more vCPUs per GB of RAM.
  • Memory-intensive workloads (databases, in-memory caches) — e1m.* Memory flavors provide more RAM per vCPU.
  • Network-intensive workloads (NFV, high-throughput) — e1n.* Network flavors offer enhanced network performance.
  • GPU workloads (ML/AI, rendering) — p1d.*, p1gd.*, or a1g6000d.* GPU flavors.
  • Region 2 — a1.* and a1d.* flavors; a1d.* variants have a capped disk size at 960 GB.

Note

The m1.* and e1.* Standard flavors have identical specs. m1.* is the older generation; e1.* is the current generation. Prefer e1.* when launching new instances.

Resizing a VM

A VM can be resized by changing its flavor:

  • Standard flavors — can only be resized from smaller to larger (CPU, RAM, and root disk).
  • Zero-Disk flavors — can be resized in both directions (CPU and RAM only). The boot volume size is adjusted separately via Storage — Extend Volumes.

A VM reboot is required after resizing.

Warning

A VM cannot be moved to a different Availability Zone after deployment. Choose the AZ carefully during launch.

  1. Resize Instance of a Standard Flavor includes always CPU, RAM and Root-Disk size ↩

  2. Resize Instance of a Zero-Disk Flavor includes only CPU and RAM (larger to smaller allowed). Resize of a Boot-Disk Volume only supported in the next OpenStack Release "Stein" ↩

  3. Stored in Images: Disk Format: QCOW2, Size: 0 bytes, plus under Volumes => Snapshot, Size of the Boot-Disk e.g. 50 GB ↩↩

  4. with fixed size integrated persistent Boot-Disk ↩

  5. with custom sized persistent Boot-Disk Volume ↩