Skip to content

Virtomat Flavor Catalog (Generation 1)

⚖️ Standard / Balanced — s1.*

Flavor vCPU RAM (GiB) Disk Boot Notes
s1.small 2 6 0 Volume-backed Entry-level balanced VM
s1.medium 4 12 0 Volume-backed Typical workload VM
s1.large 8 24 0 Volume-backed Multi-service app VM
s1.xlarge 16 48 0 Volume-backed Heavy balanced workload
openstack flavor create s1.small --vcpus 2 --ram 6144 --disk 0 --public

⚖️ Standard / Balanced (Ephemeral) — s1e.*

Flavor vCPU RAM (GiB) Disk (GB) Boot Notes
s1e.small 2 6 40 Ephemeral Fast local storage for dev/test
s1e.medium 4 12 60 Ephemeral CI/CD, temporary workloads
s1e.large 8 24 80 Ephemeral Build servers, staging
s1e.xlarge 16 48 100 Ephemeral Ephemeral multi-service apps
openstack flavor create s1e.small --vcpus 2 --ram 6144 --disk 40 --public

⚡ Compute-Optimized — c1.*

Flavor vCPU RAM (GiB) Disk Boot Notes
c1.small 2 4 0 Volume-backed CPU-heavy, minimal memory
c1.medium 4 8 0 Volume-backed Batch, compilers, CI runners
c1.large 8 16 0 Volume-backed Compute-focused workloads
c1.xlarge 16 32 0 Volume-backed Parallel processing, microservices
openstack flavor create c1.small --vcpus 2 --ram 4096 --disk 0 --public

⚡ Compute-Optimized (Ephemeral) — c1e.*

Flavor vCPU RAM (GiB) Disk (GB) Boot Notes
c1e.small 2 4 40 Ephemeral Compilation, short-lived compute
c1e.medium 4 8 60 Ephemeral Build pipelines, test runners
c1e.large 8 16 80 Ephemeral Parallel builds, batch jobs
c1e.xlarge 16 32 100 Ephemeral Heavy compute, distributed tasks
openstack flavor create c1e.small --vcpus 2 --ram 4096 --disk 40 --public

🧠 Memory-Optimized — m1.*

Flavor vCPU RAM (GiB) Disk Boot Notes
m1.small 2 8 0 Volume-backed In-memory apps, caching
m1.medium 4 16 0 Volume-backed Databases, analytics
m1.large 8 32 0 Volume-backed Data-intensive workloads
m1.xlarge 16 64 0 Volume-backed Heavy RAM usage, high throughput
openstack flavor create m1.small --vcpus 2 --ram 8192 --disk 0 --public

🧠 Memory-Optimized (Ephemeral) — m1e.*

Flavor vCPU RAM (GiB) Disk (GB) Boot Notes
m1e.small 2 8 40 Ephemeral Fast scratch workloads
m1e.medium 4 16 60 Ephemeral Caching, temp data
m1e.large 8 32 80 Ephemeral CI/CD, testing
m1e.xlarge 16 64 100 Ephemeral Big temporary datasets
openstack flavor create m1e.small --vcpus 2 --ram 8192 --disk 40 --public

✨ GPU-Enabled — g1.*

Flavor vCPU RAM (GiB) GPU Disk Boot Notes
g1.large 8 32 1 × GPU 0 Volume-backed GPU workloads, AI inference
g1.xlarge 16 64 2 × GPU 0 Volume-backed Multi-GPU or training tasks
openstack flavor create g1.large --vcpus 8 --ram 32768 --disk 0 --public \
  --property pci_passthrough:alias='nvidia_a6000:1'

(GPU model and count defined via flavor extra-specs, e.g. pci_passthrough:alias=nvidia_a6000:1)

⚙️ Common Extra-Specs

Key Value Purpose
hw:cpu_policy=shared default Time-sharing CPUs (most workloads)
hw:mem_page_size=large optional Use large memory pages for better performance
hw:cpu_policy=dedicated optional Pin vCPUs to physical cores (no sharing)
hw:cpu_thread_policy=isolate optional Each vCPU gets entire physical core (no HT sibling sharing)
pci_passthrough:alias=nvidia_a6000:1 GPU-specific Map GPU devices to VM

📝 Performance Tuning Recommendations

Memory-Optimized Flavors (m1.*, m1e.*)

Recommended for m1.large, m1.xlarge, m1e.large, m1e.xlarge:

openstack flavor set m1.large --property hw:mem_page_size=large

Benefits: - Uses huge pages (2MB or 1GB vs 4KB) → reduces TLB misses - Improves memory access performance for databases, in-memory analytics, caching - Lower CPU overhead for memory management

Requirements: - Host must have huge pages pre-allocated (vm.nr_hugepages kernel parameter) - Less flexible memory management (no swapping, harder to overcommit) - VM creation fails if host runs out of huge pages


Compute-Optimized Flavors (c1.*, c1e.*)

Recommended for c1.large, c1.xlarge, c1e.large, c1e.xlarge:

# Option 1: Dedicated CPUs (recommended for most high-performance workloads)
openstack flavor set c1.large --property hw:cpu_policy=dedicated

# Option 2: Full isolation (for maximum performance/security)
openstack flavor set c1.xlarge \
  --property hw:cpu_policy=dedicated \
  --property hw:cpu_thread_policy=isolate

hw:cpu_policy=dedicated benefits: - Pins vCPUs to specific physical cores (no VM sharing) - Predictable, consistent performance (eliminates "noisy neighbor" issues) - Better CPU cache locality

hw:cpu_thread_policy=isolate additional benefits: - Each vCPU gets entire physical core (no hyperthreading sibling sharing) - Maximum performance isolation for HPC, real-time, security-sensitive workloads - Eliminates hyperthreading side-channel vulnerabilities

Trade-offs: - dedicated only: Reduces host CPU overcommit capability - dedicated + isolate: Uses 2× physical threads per vCPU (further reduces host density) - Requires careful host CPU topology planning