Dear Friends, in this tutorial we will see how to set Extra Specs in openstack flavor using CLI. We will also know what is Extra Specs in openstack flavor? So, let’s start and see step by step these process. First of all, we should know, what is Extra Specs in openstack flavor?
What is Extra Specs in openstack flavor?
Flavor extra specs are specific to the cloud and how it is organized for capabilities and should be abstracted from the end user. Extra specs are tied to host aggregates and a lot of them also define how a guest is created in the hypervisor. For example, what the watchdog action is for a VM.
For more details about Extra Specs you can Click-Here
These are some optional parameters which can be use in openstack flavor
CPU limits
CPU_limit: – We can configure the CPU limits with control parameters. This parameter ensures that a virtual server will never uses more than the defined amount of CPU time. It can be used to enforce a limit on the server’s CPU performance. For example, to configure the I/O limit, use below commands.
[stack@undercloud (urcloudsrc) ~]$ openstack flavor set Test \ --property quota:read_bytes_sec=10240000 \ --property quota:write_bytes_sec=10240000 [stack@undercloud (urcloudsrc) ~]$
After this we can verify our flavor property has been set or not? so let’s verify with (openstack flavor show Test) command. Like below: –
You can see in above output we have successfully set the flavor property.
If we need to remove these property value, then we can unset this value with below commands: –
[stack@undercloud (urcloudsrc) ~]$ openstack flavor unset Test --property quota:read_bytes_sec --property quota:write_bytes_sec [stack@undercloud (urcloudsrc) ~]$
CPU_quota: – We can set 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.
This value should be in range [1000, 18446744073709551] or less than 0. A quota with value 0 means no value. We can use this feature to ensure that all vCPUs run at the same speed. For example: –
[stack@undercloud (urcloudsrc) ~]$ openstack flavor set Test \ --property quota:cpu_quota=10000 \ --property quota:cpu_period=20000
Verify this property value with (openstack flavor show Test) like below: –
[stack@undercloud (urcloudsrc) ~]$ openstack flavor show Test +----------------------------+---------------------------------------------------+ | Field | Value | +----------------------------+---------------------------------------------------+ | OS-FLV-DISABLED:disabled | False | | OS-FLV-EXT-DATA:ephemeral | 0 | | access_project_ids | None | | disk | 0 | | id | 1415c9b5-2dcf-4641-8f79-e03e075e1490 | | name | Test | | os-flavor-access:is_public | True | | properties | quota:cpu_period='20000', quota:cpu_quota='10000' | | ram | 1024 | | rxtx_factor | 1.0 | | swap | | | vcpus | 2 | +----------------------------+---------------------------------------------------+ [stack@undercloud (urcloudsrc) ~]$
Memory limits
We can use these below optional parameters to limit the memory allocation, guarantee minimum memory reservation, and to specify shares used in case of resource contention.
Memory_limit: – We can specify the upper limit for virtual machine memory allocation in MB. The utilization of a virtual machine will not exceed this limit, even if there are available resources.
Memory_shares_share: – Specifies the number of shares allocated if custom is used. There is no unit for this value. It is a relative measure based on the settings for other VMs. For example: –
[stack@undercloud (urcloudsrc) ~]$ openstack flavor set Test \ --property quota:memory_shares_level=custom \ --property quota:memory_shares_share=10
Memory_shares_level: – On the virtual machine, we can specify the allocation level. This can be custom, high, normal or low. If you choose custom, set the number of shares using memory_shares_share.
Memory_reservation: – Specifies the guaranteed minimum memory reservation in MB for virtual machine. It means the specified amount of memory will be allocated to the virtual machine.
Disk I/O limits
We can use these optional parameters to set the limit of disk utilization.
Disk_io_limit: – Specifies the upper limit for disk utilization in I/O per second. The utilization of a virtual machine will not exceed this limit, even if there are available resources. The default value is -1 which indicates unlimited usage.
Disk_io_reservation: – Specifies the guaranteed minimum disk allocation in terms of Input/output Operations Per Second.
Disk_io_shares_level: – Specifies the allocation level. This can be custom, high, normal or low. If you choose custom, set the number of shares using disk_io_shares_share.
Disk_io_shares_share: – Specifies the number of shares allocated if custom is used. When there is resource contention, this value is used to determine the resource allocation.
Now I am going to sets the disk_io_reservation to 3000 IOPS.
[stack@undercloud (urcloudsrc) ~]$ openstack flavor set Test \ --property quota:disk_io_reservation=3000
Disk tuning
Using disk, I/O quotas, we can set maximum disk write to 10 MB per second for the VM user. You can see in below commands: –
[stack@undercloud (urcloudsrc) ~]$ openstack flavor set Test \ --property quota:disk_write_bytes_sec=10485760
Watchdog behavior
For the libvirt driver, we can enable and set the behavior of a virtual hardware watchdog device for each flavor. Watchdog devices keep an eye on the virtual server, and carry out the configured action, if the server hangs.
We can use below commands to set the behavior of watchdog action.
[stack@undercloud (urcloudsrc) ~]$ openstack flavor set Test \ --property hw:watchdog_action=poweroff
Valid Watchdog ACTION values are these: –
- disabled: – (default) The device is not attached.
- reset: – Forcefully reset the Virtual Machine.
- poweroff: – Forcefully power off the Virtual Machine.
- pause: – Pause the Virtual Machine.
- none: – Only enable the watchdog; nothing can be performed if the server hangs.
Performance Monitoring Unit (vPMU)
If nova is deployed with the libvirt virt driver and libvirt.virt_type is set to qemu or kvm, a vPMU can be enabled or disabled for an instance using the hw:pmu extra_spec or the hw_pmu image property.
The supported values are True or False. If the vPMU is not explicitly enabled or disabled via the flavor or image, its presence is left to QEMU to decide.
[stack@undercloud (urcloudsrc) ~]$ openstack flavor set Test \
--property hw:pmu=True|False
CPU topology
For the libvirt driver, we can define the topology of the processors in the virtual machine using properties. The properties with max limit the number that can be selected by the user with image properties.
We can use below syntax to set CPU property: –
[stack@undercloud (urcloudsrc) ~]$ openstack flavor set Test \ --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 virtual machine. By default, this is set to the number of vCPUs requested.
- FLAVOR-CORES: – (integer) The number of cores per socket for the virtual machine. By default, this is set to 1.
- FLAVOR-THREADS: – (integer) The number of threads per core for the virtual machine. By default, this is set to 1.
CPU pinning policy
We can pin the virtual CPUs (vCPUs) of instances to the host’s physical CPU cores (pCPUs) using properties. We can further refine this by stating how hardware CPU threads in a simultaneous multithreading based (SMT) architecture be used. These configurations will result in improved per-instance determinism and performance.
CPU pining syntax will be this: –
[stack@undercloud (urcloudsrc) ~]$ openstack flavor set Test \
--property hw:cpu_policy=CPU-POLICY \
--property hw:cpu_thread_policy=CPU-THREAD-POLICY
These are valid CPU-POLICY values: –
- shared: – (default) The virtual machine vCPUs will be allowed to freely float across host pCPUs, albeit potentially constrained by NUMA policy.
- dedicated: – The virtual machine virtual CPUs will be strictly pinned to a set of host physical CPUs. In the absence of an explicit virtual CPU topology request, the drivers typically expose all virtual CPUs 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 over commit ratio of 1.0. For example, if two virtual CPU guest is pinned to a single host core with two threads, then the guest will get a topology of one socket, one core, two threads.
These are valid CPU-THREAD-POLICY values: –
- 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.
- 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.
NUMA topology
We can define the host NUMA placement for the instance virtual CPU threads as well as the allocation of instance virtual CPUs and memory from the host NUMA nodes.
For flavors whose memory and virtual CPU allocations are larger than the size of NUMA nodes in the compute hosts, the definition of a NUMA topology allows hosts to better utilize NUMA and improve performance of the instance operating system.
We can use below syntax to set NUMA property in flavor.
[stack@undercloud (urcloudsrc) ~]$ openstack flavor set Test \ --property hw:numa_nodes=FLAVOR-NODES \ --property hw:numa_cpus.N=FLAVOR-CORES \ --property hw:numa_mem.N=FLAVOR-MEMORY
Where: –
- FLAVOR-NODES: – (integer) The number of host NUMA nodes to restrict execution of instance virtual CPU threads to. If not specified, then the virtual CPU 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 FLAVOR-NODES – 1.
- FLAVOR-CORES: – (comma-separated list of integers) A list of instance virtual CPUs to map to instance NUMA node N. If not specified, then virtual CPUs are evenly divided among available NUMA nodes.
- FLAVOR-MEMORY: – (integer) The number of MB of instance memory to map to instance NUMA node N. If not specified, then memory is evenly divided among available NUMA nodes.
Keep working ,great job!