3.3. Manage Flavors

Each created instance is given a flavor (resource template), which determines the instance's size and capacity. Flavors can also specify secondary ephemeral storage, swap disk, metadata to restrict usage, or special project access (none of the default flavors have these additional attributes defined).

Table 3.1. Default Flavors

Name vCPUs RAM Root Disk Size
m1.tiny 1 512 MB 1 GB
m1.small 1 2048 MB 20 GB
m1.medium 2 4096 MB 40 GB
m1.large 4 8192 MB 80 GB
m1.xlarge 8 16384 MB 160 GB
The majority of end users will be able to use the default flavors. However, you might need to create and manage specialized flavors. For example, you might:
  • Change default memory and capacity to suit the underlying hardware needs.
  • Add metadata to force a specific I/O rate for the instance or to match a host aggregate.
Note
Behavior set using image properties overrides behavior set using flavors (for more information, see Section 4.1, “Manage Images”).

3.3.1. Update Configuration Permissions

By default, only administrators can create flavors or view the complete flavor list (select Admin > System > Flavors). To allow all users to configure flavors, specify the following in the /etc/nova/policy.json file (nova-api server):
"compute_extension:flavormanage": "",

3.3.2. Create a Flavor

  1. As an admin user in the dashboard, select Admin > System > Flavors.
  2. Click Create Flavor, and specify the following fields:
    Tab Field Description
    Flavor Information Name Unique name.
    ID Unique ID. The default value, 'auto', generates a UUID4 value, but you can also manually specify an integer or UUID4 value.
    VCPUs Number of virtual CPUs.
    RAM (MB) Memory (in megabytes).
    Root Disk (GB) Ephemeral disk size (in gigabytes); to use the native image size, specify '0'. This disk is not used if 'Instance Boot Source=Boot from Volume'.
    Epehemeral Disk (GB) Secondary ephemeral disk size (in gigabytes).
    Swap Disk (MB) Swap disk size (in megabytes).
    Flavor Access Selected Projects Projects which can use the flavor. If no projects are selected, all projects have access ('Public=Yes').
  3. Click Create Flavor.

3.3.3. Update General Attributes

  1. As an admin user in the dashboard, select Admin > System > Flavors.
  2. Click the flavor's Edit Flavor button.
  3. Update the values, and click Save.

3.3.4. Update Flavor Metadata

In addition to editing general attributes, you can add metadata to a flavor ('extra_specs'), which can help fine-tune instance usage. For example, you might want to set the maximum-allowed bandwidth or disk writes.
  • Pre-defined keys determine hardware support or quotas. Pre-defined keys are limited by the hypervisor you are using (for libvirt, see Table 3.2, “Libvirt Metadata”).
  • Both pre-defined and user-defined keys can determine instance scheduling. For example, you might specify 'SpecialComp=True'; any instance with this flavor can then only run in a host aggregate with the same key-value combination in its metadata (see Section 3.4, “Manage Host Aggregates”).

3.3.4.1. View Metadata

  1. As an admin user in the dashboard, select Admin > System > Flavors.
  2. Click the flavor's Metadata link ('Yes' or 'No'). All current values are listed on the right-hand side under Existing Metadata.

3.3.4.2. Add Metadata

You specify a flavor's metadata using a key/value pair.
  1. As an admin user in the dashboard, select Admin > System > Flavors.
  2. Click the flavor's Metadata link ('Yes' or 'No'). All current values are listed on the right-hand side under Existing Metadata.
  3. Under Available Metadata, click on the Other field, and specify the key you want to add (see Table 3.2, “Libvirt Metadata” ).
  4. Click the + button; you can now view the new key under Existing Metadata.
  5. Fill in the key's value in its right-hand field.

    Figure 3.2. Flavor Metadata

    Flavor Metadata
  6. When finished with adding key-value pairs, click Save.

Table 3.2. Libvirt Metadata

Key Description
hw:action
Action that configures support limits per instance. Valid actions are:
  • cpu_max_sockets - Maximum supported CPU sockets.
  • cpu_max_cores - Maximum supported CPU cores.
  • cpu_max_threads - Maximum supported CPU threads.
  • cpu_sockets - Preferred number of CPU sockets.
  • cpu_cores - Preferred number of CPU cores.
  • cpu_threads - Preferred number of CPU threads.
  • serial_port_count - Maximum serial ports per instance.
Example: 'hw:cpu_max_sockets=2'
hw:NUMA_def
Definition of NUMA topology for the instance. For flavors whose RAM and vCPU allocations are larger than the size of NUMA nodes in the compute hosts, defining NUMA topology enables hosts to better utilize NUMA and improve performance of the guest OS.
NUMA definitions defined through the flavor override image definitions. Valid definitions are:
  • numa_nodes - Number of NUMA nodes to expose to the instance. Specify '1' to ensure image NUMA settings are overridden.
  • numa_mempolicy - Memory allocation policy. Valid policies are:
    • strict - Mandatory for the instance's RAM allocations to come from the NUMA nodes to which it is bound (default if numa_nodes is specified).
    • preferred - The kernel can fall back to using an alternative node. Useful when the numa_nodes is set to '1'.
  • numa_cpus.0 - Mapping of vCPUs N-M to NUMA node 0 (comma-separated list).
  • numa_cpus.1 - Mapping of vCPUs N-M to NUMA node 1 (comma-separated list).
  • numa_mem.0 - Mapping N GB of RAM to NUMA node 0.
  • numa_mem.1 - Mapping N GB of RAM to NUMA node 1.
    numa_cpu.N and numa_mem.N are only valid if numa_nodes is set. Additionally, they are only required if the instance's NUMA nodes have an asymetrical allocation of CPUs and RAM (important for some NFV workloads). Note: If the values of numa_cpu or numa_mem.N specify more than that available, an exception is raised.
Example when the instance has 8 vCPUs and 4GB RAM:
  • hw:numa_nodes=2
  • hw:numa_cpus.0=0,1,2,3,4,5
  • hw:numa_cpus.1=6,7
  • hw:numa_mem.0=3
  • hw:numa_mem.1=1
The scheduler looks for a host with 2 NUMA nodes with the ability to run 6 CPUs + 3 GB of RAM on one node, and 2 CPUS + 1 GB of RAM on another node. If a host has a single NUMA node with capability to run 8 CPUs and 4 GB of RAM, it will not be considered a valid match. The same logic is applied in the scheduler regardless of the numa_mempolicy setting.
hw:watchdog_action
An instance watchdog device can be used to trigger an action if the instance somehow fails (or hangs). Valid actions are:
  • disabled - The device is not attached (default value).
  • pause - Pause the instance.
  • poweroff - Forcefully shut down the instance.
  • reset - Forcefully reset the instance.
  • none - Enable the watchdog, but do nothing if the instance fails.
Example: 'hw:watchdog_action=poweroff'
hw_rng:action
A random-number generator device can be added to an instance using its image properties (see hw_rng_model in the "Command-Line Interface Reference" in RHEL OpenStack Platform documentation).
If the device has been added, valid actions are:
  • allowed - If 'True', the device is enabled; if 'False', disabled. By default, the device is disabled.
  • rate_bytes - Maximum number of bytes the instance's kernel can read from the host to fill its entropy pool every rate_period (integer).
  • rate_period - Duration of the read period in seconds (integer).
Example: 'hw_rng:allowed=True'.
hw_video:ram_max_mb
Maximum permitted RAM to be allowed for video devices (in MB).
Example: 'hw:ram_max_mb=64'
quota: option
Enforcing limit for the instance. Valid options are:
  • cpu_period - Time period for enforcing cpu_quota (in microseconds). Within the specified cpu_period, each vCPU cannot consume more than cpu_quota of runtime. The value must be in range [1000, 1000000]; '0' means 'no value'.
  • cpu_quota - Maximum allowed bandwidth (in microseconds) for the vCPU in each cpu_period. The value must be in range [1000, 18446744073709551]. '0' means 'no value'; a negative value means that the vCPU is not controlled. cpu_quota and cpu_period can be used to ensure that all vCPUs run at the same speed.
  • cpu_shares - Share of CPU time for the domain. The value only has meaning when weighted against other machine values in the same domain. That is, an instance with a flavor with '200' will get twice as much machine time as an instance with '100'.
  • disk_read_bytes_sec - Maximum disk reads in bytes per second.
  • disk_read_iops_sec - Maximum read I/O operations per second.
  • disk_write_bytes_sec - Maximum disk writes in bytes per second.
  • disk_write_iops_sec - Maximum write I/O operations per second.
  • disk_total_bytes_sec - Maximum total throughput limit in bytes per second.
  • disk_total_iops_sec - Maximum total I/O operations per second.
  • vif_inbound_average - Desired average of incoming traffic.
  • vif_inbound_burst - Maximum amount of traffic that can be received at vif_inbound_peak speed.
  • vif_inbound_peak - Maximum rate at which incoming traffic can be received.
  • vif_outbound_average - Desired average of outgoing traffic.
  • vif_outbound_burst - Maximum amount of traffic that can be sent at vif_outbound_peak speed.
  • vif_outbound_peak - Maximum rate at which outgoing traffic can be sent.
Example: 'quota:vif_inbound_average=10240'