Manage flavors

updated: 2021-04-10 07:30

Manage flavors

Todo

Merge this into 'flavors'

In OpenStack, flavors define the compute, memory, and storage capacity of nova computing instances. To put it simply, a flavor is an available hardware configuration for a server. It defines the size of a virtual server that can be launched.

Note

Flavors can also determine on which compute host a flavor can be used to launch an instance. For information about customizing flavors, refer to Flavors.

A flavor consists of the following parameters:

Flavor ID
Unique ID (integer or UUID) for the new flavor. If specifying 'auto', a UUID will be automatically generated.
Name
Name for the new flavor.
VCPUs
Number of virtual CPUs to use.
Memory MB
Amount of RAM to use (in megabytes).
Root Disk GB

Amount of disk space (in gigabytes) to use for the root (/) partition. This property is required.

The root disk is an ephemeral disk that the base image is copied into. When booting from a persistent volume it is not used. The 0 size is a special case which uses the native base image size as the size of the ephemeral root volume. However, in this case the filter scheduler cannot select the compute host based on the virtual image size. As a result, 0 should only be used for volume booted instances or for testing purposes. Volume-backed instances can be enforced for flavors with zero root disk via the os_compute_api:servers:create:zero_disk_flavor policy rule.

Ephemeral Disk GB
Amount of disk space (in gigabytes) to use for the ephemeral partition. If unspecified, the value is 0 by default. Ephemeral disks offer machine local disk storage linked to the lifecycle of a VM instance. When a VM is terminated, all data on the ephemeral disk is lost. Ephemeral disks are not included in any snapshots.
Swap
Amount of swap space (in megabytes) to use. If unspecified, the value is 0 by default.
RXTX Factor
Optional property that allows servers with a different bandwidth be created with the RXTX Factor. The default value is 1.0. That is, the new bandwidth is the same as that of the attached network. The RXTX Factor is available only for Xen or NSX based systems.
Is Public
Boolean value defines whether the flavor is available to all users. Defaults to True.
Extra Specs
Key and value pairs that define on which compute nodes a flavor can run. These pairs must match corresponding pairs on the compute nodes. It can be used to implement special resources, such as flavors that run on only compute nodes with GPU hardware.

As of Newton, there are no default flavors. The following table lists the default flavors for Mitaka and earlier.

Flavor VCPUs Disk (in GB) RAM (in MB)
m1.tiny 1 1 512
m1.small 1 20 2048
m1.medium 2 40 4096
m1.large 4 80 8192
m1.xlarge 8 160 16384

You can create and manage flavors with the openstack flavor commands provided by the python-openstackclient package.

Create a flavor

  1. List flavors to show the ID and name, the amount of memory, the amount of disk space for the root partition and for the ephemeral partition, the swap, and the number of virtual CPUs for each flavor:

    $ openstack flavor list

  2. To create a flavor, specify a name, ID, RAM size, disk size, and the number of VCPUs for the flavor, as follows:

    $ openstack flavor create FLAVOR_NAME --id FLAVOR_ID \
    --ram RAM_IN_MB --disk ROOT_DISK_IN_GB --vcpus NUMBER_OF_VCPUS

    Note

    Unique ID (integer or UUID) for the new flavor. If specifying 'auto', a UUID will be automatically generated.

    Here is an example with additional optional parameters filled in that creates a public extra_tiny flavor that automatically gets an ID assigned, with 256 MB memory, no disk space, and one VCPU. The rxtx-factor indicates the slice of bandwidth that the instances with this flavor can use (through the Virtual Interface (vif) creation in the hypervisor):

    $ openstack flavor create --public m1.extra_tiny --id auto \
    --ram 256 --disk 0 --vcpus 1 --rxtx-factor 1

  3. If an individual user or group of users needs a custom flavor that you do not want other projects to have access to, you can change the flavor's access to make it a private flavor. See Private Flavors in the OpenStack Operations Guide.

    For a list of optional parameters, run this command:

    $ openstack help flavor create

  4. After you create a flavor, assign it to a project by specifying the flavor name or ID and the project ID:

    $ nova flavor-access-add FLAVOR TENANT_ID

  5. In addition, you can set or unset extra_spec for the existing flavor. The extra_spec metadata keys can influence the instance directly when it is launched. If a flavor sets the extra_spec key/value quota:vif_outbound_peak=65536, the instance's outbound peak bandwidth I/O should be less than or equal to 512 Mbps. There are several aspects that can work for an instance including CPU limits, Disk tuning, Bandwidth I/O, Watchdog behavior, and Random-number generator. For information about supporting metadata keys, see Flavors.

    For a list of optional parameters, run this command:

    $ nova help flavor-key

Delete a flavor

Delete a specified flavor, as follows:

$ openstack flavor delete FLAVOR_ID
updated: 2021-04-10 07:30
Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.

found an error? report a bug questions?