Machine Types / Flavors
Basic Information
SWITCHengines provides different machine types for any possible use case. Do you have high compute workloads? Do you require more memory for your application? No problem!
"Openstack Flavors" give you the ability to design the hardware specifications of your instance. Initially, we provide you with some general information. Please, don't skip this section, it is important to understand the basics!
Definitions
vCPU | Number of virtual CPUs |
RAM | Amount of RAM (GB) |
Root Disk | Non-persistent disk (if the instance is deleted, the data gets lost) |
Volume-backed Root Disk | Openstack Volume is created for the root disk (persistent) |
GPU | Number and type of the GPUs assigned to an instance |
Local SSD | Local SSD on the hypervisor (passed through to the guest instance) |
SWITCHengines Flavors Explained
SWITCHengines are historically grown what leads to some confusion when one is getting started with our flavors. We are aware of this fact and try to simplify this in the future. Unfortunately, flavors cannot be easily removed nor renamed what requires careful actions.
A very important decision is the storage of the instance. On a very simplified level, there are two types of instance storage:
- Root Disk (non-persistent):
- Defined via flavor option "Root Disk"
- Non-persistent disk → Data gets deleted if the instance is deleted.
- Volume-backed Root Disk:
- An Openstack Volume is the root disk.
- Defined before creating the instance, i.e. via "Project → Volumes → Volumes → Create Volume"
or on instance creation time with "Source: Create New Volume" - Default in SWITCHengines
When using the SWITCHengines dashboard, by default an new instance is created with a volume-backed root disk. This has several advantages like:
- More flexibility (Instance resizing is not dependent on the flavor disk size)
- Data persists over instance deletions
- Shelving instances is much faster
- Snapshotting volumes (via Volume Snapshot) is faster than snapshotting instances (via Instance Snapshot)
Implications For the Flavor Selection
- Snapshotting of volume-backed instances should be done via the Volumes dashboard:
- "Project → Volumes → Volumes → Volume Menu → Create Snapshot"
- CLI:
openstack volume snapshot create --volume VOL_UUID SNAP_NAME
- The "Root Disk" property only applies if you select the "Create New Volume: No" on instance launch (not volume-backed root disk).
This is generally not recommended! Local SSD flavors are the exceptions where it's required to have "Create New Volume: No", see explanation below!
Standard Flavors
The following flavors are the standards and are used the most:
Flavor Name | vCPU | vRAM (GB) | Root Disk (GB) | Description | Explanation |
c1.small c1.medium c1.large c1.xlarge c1.xxlarge |
1 2 4 8 16 |
1 2 4 8 16 |
20 20 20 20 20 |
Simplified resizing within c1 flavor family |
Ceph standard disk, |
m1.small m1.medium m1.large m1.xlarge m1.xxlarge |
1 2 4 8 16 |
2 4 8 16 32 |
20 40 80 160 160 |
Increasing ephemeral disk size, Not downward resizable |
Openstack Defaults, Ceph standard disk, RAM ~ 2GB x CPU |
n1.small n1.medium n1.large n1.xlarge n1.xxlarge |
1 2 4 8 16 |
4 8 16 32 64 |
20 20 20 20 20 |
Similar to c1, Simplified resizing within n1 flavor family |
Ceph standard disk, RAM ~ 4GB x CPU |
windows.small |
1 2 4 |
1 2 4 |
50 50 50 |
Similar to c1 flavors but with 50GB Root Disk |
DEPRECATED [1] Ceph standard disk |
[1]: Windows instances are not bound to a specific flavor! You can use a c1/m1/n1 flavor that serves your needs. Keep in mind that Windows has a requirement of >50GB disks in order to work properly.
Special Flavors
There are special flavors in SWITCHengines that give you even further functionality. GPU as well as Local SSD flavors need to be enabled for your project in https://engines.admin.switch.ch.
GPU Flavors
GPU flavors take care that your instance is scheduled to the right hypervisor and that the correct number of GPUs are passed to your guest instance.
Flavor Name | vCPU | RAM (GB) | Root Disk (GB) | GPU | Model | Description | Explanation |
g1.c8r32-p100 g1.c16r64-p100 g1.c24r112-p100 |
8 16 24 |
32 64 112 |
30 30 30 |
1 1 1 |
P100 P100 P100 |
See GPU Support | Ceph standard disk GPU passthrough |
g1.c04r46-1titanxp g1.c08r92-2titanxp g1.c16r184-4titanxp |
4 8 16 |
46 92 184 |
30 30 30 |
1 2 4 |
Titan XP | See GPU Support | Ceph standard disk GPU passthrough |
g1.c04r44-1t4 g1.c08r88-2t4 g1.c16r176-4t4 |
4 8 16 |
44 88 176 |
30 30 30 |
1 2 4 |
T4 | See GPU Support | Ceph standard disk GPU passthrough |
See GPU Support for more information about GPUs.
Local SSD
You have to explicitely use an ephemeral root disk (see above explanation). You can do the following:
- In Project → Compute → Instances → "Launch Instance"
- Source:
- Select Boot Source: Image
- Create New Volume: No
This is very important! Otherwise, you don't use the local SSD.
Flavor Name | vCPU | RAM (GB) | Root Disk (GB) | Description | Explanation |
i1.small i1.medium i1.large |
1 4 8 |
1 8 16 |
20 50 50 |
Local SSD flavor |
Important: [1] |
i1.cXrYdZ | X | Y | Z | Local SSD flavor | Important: [1] |
[1]: We don't recommend to use local SSDs because of the following pain points:
- NO data replication
- No live maintenance (VM has to be turned off on request)
- Very slow snapshotting
- No hypervisor migration
- No resizing is supported by SWITCHengines
- No migrations are supported by SWITCHengine
Recommendation: ceph-ssd
- Very good performance
- 3x replication
- Easy maintenance
- Easy snapshotting
In order to install a VM using ceph-ssd, you have to create a volume with ceph-ssd first where you use the required image as a basis. "Project → Volumes → Volumes → Create Volume"