...
- t1 - Tiny VM's
- This class is intended for testing, or for VM's which does not really need much resources.
- The disk are shaped to 150 IOPS, which is similar to a regular hard-drive.
- m1 - Medium-size General purpose
- This class is for the general purpose VM's. These flavors have 4 GB RAM for each CPU (except for tiny, which have 1CPU/2GB RAM).
- The disk are shaped to 300 IOPS, which is faster than an enterprise grade hard-drive.
- l1 - Large general purpose
- This class is for general-purpose VM's where the m-series are too small. These flavors have 4GB RAM for each CPU.
- The disk are shaped to 300 IOPS, which is faster than an enterprise grade hard-drive.
- c1 - CPU intensive VM's
- This class is for VM's needing a lot of CPU, while not needing too much memory. These flavors have 2GB RAM for each CPU.
- The disk are shaped to 300 IOPS, which is faster than an enterprise grade hard-drive.
- r1 - RAM intensive VM's
- This class is for VM's needing a lot of RAM. These flavors have 4GB RAM for each CPU.
- The disk are shaped to 300 IOPS, which is faster than an enterprise grade hard-drive.
...
| Code Block | ||
|---|---|---|
| ||
+-----------+-------+--------+------+ | Name | VCPUs | RAM | Disk | +-----------+-------+--------+------+ | t1.tiny | 1 | 256 | 5 | | t1.small | 1 | 512 | 5 | | t1.medium | 1 | 768 | 10 | | t1.large | 2 | 1024 | 10 | | t1.xlarge | 2 | 1536 | 10 | | m1.tiny | 1 | 2048 | 20 | | m1.small | 1 | 4096 | 30 | | m1.medium | 2 | 8192 | 40 | | m1.large | 4 | 16384 | 50 | | m1.xlarge | 8 | 32768 | 50 | | c1l1.tiny | 812 | 1638449152 | 40 | | c1l1.small | 1216 | 2457665536 | 40 | | c1l1.medium | 1620 | 3276881920 | 40 | | c1l1.large | 24 | 4915298304 | 40 | | c1l1.xlarge | 32 | 131072 65536 | 40 | | r1c1.tiny | 8 | 6553616384 | 40 | | r1c1.small | 12 | 9830424576 | 40 | | r1c1.medium | 16 | 131072 32768 | 40 | | r1c1.large | 24 | 19660849152 | 40 | | r1c1.xlarge | 32 | 26214465536 | 40 | +-----------+-------+--------+------+ |
The Trondheim-cloud currently utilizes a slightly different scheme, with the following flavors available:
| Code Block |
|---|
| Name | RAM MB|Disk GB| Ephemeral | VCPUs | Is Public | +------------+--------+-------+-----------+-------+-----------+ | m1.micro | 512 | 5 | 0 | 1 | True | | m1.tiny | 1024 | 10 | 0 | 1 | True | | m1.small | 2048 | 20 | 0| r1.tiny | 1 | True | | m1.medium | 4096 | 40 | 0 | 2 | True | | m1.large | 8192 | 60 | 0 | 4 | True | | m1.xlarge | 16384 | 80 | 0 | 8 | True | | m1.2xlarge | 32768 | 100 | 0 | 16 | True | | r1.tiny | 65536 | 40 | 0 | 8 | True | | r1.small | 98304 | 40 12 | 098304 | 12 | True 40 | | r1.medmedium | 16 | 131072 | 40 | 0 | 16 | True | | r1.large | 196608 | 24 40 | 0 196608 | 24 | True | 40 | | r1.xlarge | 262144 | 40 32 | 0 262144 | 3240 | True | +------------+--------+-------+-----------+-------+-----------+ |
Flavor "Not available"
If a flavor get changed (ex: m1.medium gets more memory) the old flavor will be deleted and a new one will be created. In this case existing VM's would be listed with the flavor "Not Available". This does not really matter, as the quotas is counted correctly, and openstack knows which specs the machine is supposed to have, but if you would like to give the machine a new flavour you should simply resize it to a new flavor. If you resize to a flavor to small to support the machine nothing will happen, so you should not loose any data regardless of which flavor you decide to resize to.