openstack_flavor_advanced.md

Working with Flavors

Flavors define the compute, memory, and storage capacity of Compute instances. A flavor is an available hardware configuration for a server. It defines the size of a virtual server that can be launched.

You can modify an existing flavor on the Dashboard from the Flavors page and clicking Edit Flavor.

Flavors define the following elements:

Element	Description
Name	A descriptive name. XX.SIZE_NAME is typically not required, though some third party tools may rely on it.
Memory MB	Instance memory in megabytes.
Disk	Virtual root disk size in gigabytes. This 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.
Ephemeral	Specifies the size of a secondary ephemeral data disk. This is an empty, unformatted disk and exists only for the life of the instance. Default value is 0.
Swap	Optional swap space allocation for the instance. Default value is 0.
VCPUs	Number of virtual CPUs presented to the instance.
RXTX Factor	Optional property allows created servers to have a different bandwidth cap than that defined in the network they are attached to. This factor is multiplied by the rxtx_base property of the network. Default value is 1.0. That is, the same as attached network. This parameter is only available for NSX-based systems.
Is Public	Boolean value, whether flavor is available to all users or private to the tenant it was created in. 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. Use to implement special resources, such as flavors that run on only compute nodes with GPU hardware.

Assigning Flavors

Flavor customization is limited by the hypervisor in use. For example, the libvirt driver enables quotas on CPUs available to a VM, disk tuning, bandwidth I/O, watchdog behavior, random number generator device control, and instance VIF traffic control.

You can assign flavors to particular projects. By default, a flavor is public and available to all projects. Private flavors are only accessible to those on the access list and are invisible to other projects.

To create and assign a private flavor to a project, run:

$ openstack flavor create --private p1.medium auto 512 40 4

Setting CPU Limits

You can configure the CPU limits using control parameters with the nova client. For example, to configure the I/O limit, use:

$ openstack flavor set <FLAVOR-NAME> \
--property quota:read_bytes_sec=10240000 \
--property quota:write_bytes_sec=10240000

Use these optional parameters to control weight shares, enforce intervals for runtime quotas, and set a quota for maximum allowed bandwidth:

Parameter	Description
cpu_shares	The proportional weighted share for the domain. If this element is omitted, the service defaults to the OS provided defaults. There is no unit for the value; it is a relative measure based on the setting of other VMs. For example, a VM configured with value 2048 gets twice as much CPU time as a VM configured with value 1024.
cpu_shares_level	The allocation level on VMware. Can be custom, high, normal, or low. If you choose custom, set the number of shares using cpu_shares_share
cpu_period	The enforcement interval (unit microseconds) for QEMU and LXC hypervisors. Within a period, each VCPU of the domain is not allowed to consume more than the quota worth of runtime. The value should be in range [1000, 1000000]. A period with value 0 means no value.
cpu_limit	The upper limit for VMware machine CPU allocation in MHz. This parameter ensures that a machine never uses more than the defined amount of CPU time. It can be used to enforce a limit on the machine's CPU performance.
cpu_reservation	The guaranteed minimum CPU reservation in MHz for VMware. This means that if needed, the machine is allocated the reserved amount of CPU cycles.
cpu_quota	The maximum allowed bandwidth (unit microseconds). A domain with a negative-value quota indicates that the domain has infinite bandwidth, which means that it is not bandwidth controlled. The value should be in range [1000, 18446744073709551] or less than 0. A quota with value 0 means no value. You can use this feature to ensure that all vCPUs run at the same speed.

Setting Disk Tuning:

You can set maximum disk write to 10 MB per second for a VM user. For example:

$ openstack flavor set <FLAVOR-NAME> --property quota:disk_write_bytes_sec=10485760

The disk I/O options are:

• disk_read_bytes_sec
• disk_read_iops_sec
• disk_write_bytes_sec
• disk_write_iops_sec
• disk_total_bytes_sec
• disk_total_iops_sec

Bandwidth I/O—The vif I/O options are:

• vif_inbound_average
• vif_inbound_burst
• vif_inbound_peak
• vif_outbound_average
• vif_outbound_burst
• vif_outbound_peak

Incoming and outgoing traffic can be shaped independently. The bandwidth element can have at most one inbound and one outbound child element. If you leave any of these child elements out, no quality of service (QoS) is applied on that traffic direction. To shape the incoming traffic, use inbound only. Each element has one mandatory attribute average, which specifies the average bit rate on the interface being shaped.

There are two optional attributes:

• peak(integer)—Specifies the maximum rate at which a bridge can send data (kilobytes/second)
• burst(integer)—The amount of bytes that can be burst at peak speed (kilobytes). The rate is shared equally within domains connected to the network.

The example below sets network traffic bandwidth limits for existing flavor as follows:

• Outbound traffic:
  • average—256 Mbps (32768 kilobytes/second)
  • peak—512 Mbps (65536 kilobytes/second)
  • burst—65536 kilobytes
• Inbound traffic:
  • average—256 Mbps (32768 kilobytes/second)
  • peak—512 Mbps (65536 kilobytes/second)
  • burst—65536 kilobytes

$ openstack flavor set <FLAVOR-NAME> \
    --property quota:vif_outbound_average=32768 \
    --property quota:vif_outbound_peak=65536 \
    --property quota:vif_outbound_burst=65536 \
    --property quota:vif_inbound_average=32768 \
    --property quota:vif_inbound_peak=65536 \
    --property quota:vif_inbound_burst=65536

Note All the speed limit values in above example are specified n kilobytes/second. And burst values are in kilobytes.

Setting Watchdog Behavior for the Libvirt Driver

You can enable and set the behavior of a virtual hardware watchdog device for each flavor. Watchdog devices keep an eye on the guest server, and carry out the configured action, if the server hangs. The watchdog uses the i6300esb device (emulating a PCI Intel 6300ESB). If hw:watchdog_action is not specified, the watchdog is disabled.

To set Watchdog behavior:

$ openstack flavor set <FLAVOR-NAME> --property hw:watchdog_action=<ACTION>

Valid ACTION values are:

• disabled—(default) The device is not attached.
• reset—Forcefully reset the guest.
• poweroff—Forcefully power off the guest.
• pause—Pause the guest.
• none—Only enable the watchdog; do nothing if the server hangs.

Note Watchdog behavior set using the specific image properties overrides behavior set using flavors.

Using a Random Number Generator

If a random number generator device has been added to the instance through its image properties, the device can be enabled and configured using the following command:

$ openstack flavor set <FLAVOR-NAME> \
    --property hw_rng:allowed=True \
    --property hw_rng:rate_bytes=<RATE-BYTES> \
    --property hw_rng:rate_period=<RATE-PERIOD>

Where:

• RATE-BYTES (integer)—Allowed amount of bytes that the guest can read from the host's entropy per period.
• RATE-PERIOD (integer)—Duration of the read period in seconds.

Defining CPU Topology for the Libvirt Driver

You can define the topology of the processors in the virtual machine using properties. The properties with max limit the number you can select with image properties.

$ openstack flavor set <FLAVOR-NAME> \
    --property hw:cpu_sockets=<FLAVOR-SOCKETS> \
    --property hw:cpu_cores=<FLAVOR-CORES> \
    --property hw:cpu_threads=<FLAVOR-THREADS> \
    --property hw:cpu_max_sockets=<FLAVOR-SOCKETS> \
    --property hw:cpu_max_cores=<FLAVOR-CORES> \
    --property hw:cpu_max_threads=<FLAVOR-THREADS>

Where:

• FLAVOR-SOCKETS—(integer) The number of sockets for the guest VM. By default, this is set to the number of vCPUs requested.
• FLAVOR-CORES—(integer) The number of cores per socket for the guest VM. By default, this is set to 1.
• FLAVOR-THREADS—(integer) The number of threads per core for the guest VM. By default, this is set to 1.

Using the CPU Pinning Policy for the Libvirt Driver

You can use properties to pin the virtual CPUs (vCPUs) of instances to the host's physical CPU cores (pCPUs). You can further refine this by stating how hardware CPU threads in a simultaneous, multi-threading based (SMT) architecture be used. These configurations result in improved per-instance determinism and performance.

Note

SMT-based architectures include Intel processors with Hyper-threading technology. In these architectures, processor cores share a number of components with one or more other cores. Cores in such architectures are commonly referred to as hardware threads, while the cores that a given core share components with are known as thread siblings.

Note

Use host aggregates to separate these pinned instances from unpinned instances as the latter will not respect the resourcing requirements of the former.

$ openstack flavor set <FLAVOR-NAME> \
    --property hw:cpu_policy=<CPU-POLICY> \
    --property hw:cpu_thread_policy=<CPU-THREAD-POLICY>

Valid CPU-POLICY values are:

• shared—(default) Allows guest vCPUs to freely float across host pCPUs, albeit potentially constrained by NUMA policy.
• dedicated—Pins guest vCPUs to a set of host pCPUs. In the absence of an explicit vCPU topology request, the drivers typically expose all vCPUs as sockets with one core and one thread. When strict CPU pinning is in effect the guest CPU topology will be setup to match the topology of the CPUs to which it is pinned. This option implies an overcommit ratio of 1.0. For example, if a two vCPU guest is pinned to a single host core with two threads, then the guest will get a topology of one socket, one core, threads threads.

Valid CPU-THREAD-POLICY values are:

• prefer—(default) The host may or may not have an SMT architecture. Where an SMT architecture is present, thread siblings are preferred.
• isolate—The host must not have an SMT architecture or must emulate a non-SMT architecture. If the host does not have an SMT architecture, each vCPU is placed on a different core as expected. If the host does have an SMT architecture - that is, one or more cores have thread siblings - then each vCPU is placed on a different physical core. No vCPUs from other guests are placed on the same core. All but one thread sibling on each core is therefore guaranteed to be unusable.
• require—The host must have an SMT architecture. Each vCPU is allocated on thread siblings. If the host does not have an SMT architecture, then it is not used. If the host has an SMT architecture, but not enough cores with free thread siblings are available, then scheduling fails.

**Note**The hw:cpu_thread_policy option is only valid if hw:cpu_policy is set to dedicated.

Defining NUMA Topology for the Libvirt Driver

You can define the host NUMA placement for the instance vCPU threads as well as the allocation of instance vCPUs and memory from the host NUMA nodes. For flavors whose memory and vCPU allocations are larger than the size of NUMA nodes in the compute hosts, the definition of a NUMA topology allows hosts to better use NUMA and improve performance of the instance OS.

$ openstack flavor set <FLAVOR-NAME> \
    --property hw:numa_nodes=<FLAVOR-NODES> \
    --property hw:numa_cpus.N=<FLAVOR-CORES> \
    --property hw:numa_mem.N=<FLAVOR-MEMORY>

Where:

• FLAVOR-NODE (integer)—The number of host NUMA nodes to restrict execution of instance vCPU threads to. If not specified, the vCPU threads can run on any number of the host NUMA nodes available.
• N (integer)—The instance NUMA node to apply a given CPU or memory configuration to, where N is in the range 0 to 1.
• FLAVOR-CORES (comma-separated list of integers)—A list of instance vCPUs to map to instance NUMA node N. If not specified, vCPUs are evenly divided among available NUMA nodes.
• FLAVOR-MEMORY (integer)—The number of MB of instance memory to map to instance instance NUMA node N. If not specified, memory is evenly divided among available NUMA nodes.

Notehw:numa_cpus.N and hw:numa_mem.N are only valid if hw: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).

The N parameter is an index of guest NUMA nodes and may not correspond to host NUMA nodes. For example, on a platform with two NUMA nodes, the scheduler may opt to place guest NUMA node 0, as referenced in hw:numa_mem.0 on host NUMA node 1 and vice versa. Similarly, the integers used for FLAVOR-CORES are indexes of guest vCPUs and may not host CPUs or NUMA nodes.

If the combined values of hw:numa_cpus.N or hw:numa_mem.N are greater than the available number of CPUs or memory respectively, an exception is raised.

Allocating Large Pages

You can configure the size of large pages used to back the VMs.

$ openstack flavor set <FLAVOR-NAME> \
    --property hw:mem_page_size=<PAGE_SIZE>

Valid PAGE_SIZE values are:

• small(default)—The smallest page size is used. Example: 4 KB on x86.
• large—Only use larger page sizes for guest RAM. Example: either 2 MB or 1 GB on x86.
• any—It is left up to the compute driver to decide. In this case, the libvirt driver might try to find large pages, but fall back to small pages. Other drivers may choose alternate policies for any.
• pagesize (string)—An explicit page size can be set if the workload has specific requirements. This value can be an integer value for the page size in KB, or can use any standard suffix. Example: 4KB, 2MB, 2048, 1GB.

Note Large pages can be enabled for guest RAM without any regard to whether the guest OS will use them or not. If the guest OS chooses not to use huge pages, it will see small pages as before. Conversely, if a guest OS does intend to use huge pages, it is very important that the guest RAM be backed by huge pages. Otherwise, the guest OS will not be getting the expected performance benefit.