Admin users can use the nova flavor- commands to customize and manage flavors. To see the available flavor-related commands, run:
$ nova help | grep flavor- flavor-access-add Add flavor access for the given tenant. flavor-access-list Print access information about the given flavor. flavor-access-remove Remove flavor access for the given tenant. flavor-create Create a new flavor flavor-delete Delete a specific flavor flavor-key Set or unset extra_spec for a flavor. flavor-list Print a list of available 'flavors' (sizes of flavor-show Show details about the given flavor.
Note | |
---|---|
|
Flavors define these 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 |
Virtual machine 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. |
Swap |
Optional swap space allocation for the instance. |
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. |
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. |
Flavor customization can be 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.
- CPU limits
You can configure the CPU limits with control parameters with the nova client. For example, to configure the I/O limit, use:
$ nova flavor-key m1.small set quota:read_bytes_sec=10240000 $ nova flavor-key m1.small set quota:write_bytes_sec=10240000
There are optional CPU control parameters for weight shares, enforcement intervals for runtime quotas, and a quota for maximum allowed bandwidth:
cpu_shares
specifies 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_period
specifies 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_quota
specifies 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. For example:$ nova flavor-key m1.low_cpu set quota:cpu_quota=10000 $ nova flavor-key m1.low_cpu set quota:cpu_period=20000
In this example, the instance of
m1.low_cpu
can only consume a maximum of 50% CPU of a physical CPU computing capability.
- Disk tuning
Using disk I/O quotas, you can set maximum disk write to 10 MB per second for a VM user. For example:
$ nova flavor-key m1.medium set 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
The vif I/O options are:
vif_inbound_ average
vif_inbound_burst
vif_inbound_peak
vif_outbound_ average
vif_outbound_burst
vif_outbound_peak
- Bandwidth I/O
Incoming and outgoing traffic can be shaped independently. The bandwidth element can have at most one inbound and at most one outbound child element. If you leave any of these children element out, no quality of service (QoS) is applied on that traffic direction. So, if you want to shape only the network's incoming traffic, use inbound only (and vice versa). Each element has one mandatory attribute average, which specifies the average bit rate on the interface being shaped.
There are also two optional attributes (integer):
peak
, which specifies maximum rate at which bridge can send data (kilobytes/second), andburst
, the amount of bytes that can be burst at peak speed (kilobytes). The rate is shared equally within domains connected to the network.The following example configures a bandwidth limit for instance network traffic:
$ nova flavor-key m1.small set quota:inbound_average=10240 $ nova flavor-key m1.small set quota:outbound_average=10240
- 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). Ifhw_watchdog_action
is not specified, the watchdog is disabled.To set the behavior, use:
$ nova flavor-key
FLAVOR-NAME
set 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 a specific image's properties will override behavior set using flavors.
- 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:
$ nova flavor-key
FLAVOR-NAME
set hw_rng:allowed=True $ nova flavor-keyFLAVOR-NAME
set hw_rng:rate_bytes=RATE-BYTES
$ nova flavor-keyFLAVOR-NAME
set 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.
- Instance VIF traffic control
Flavors can also be assigned 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 these commands:
$ nova flavor-create --is-public false p1.medium auto 512 40 4 $ nova flavor-access-add 259d06a0-ba6d-4e60-b42d-ab3144411d58 86f94150ed744e08be565c2ff608eef9