Customizing flavors for VM performance
The custom settings described below are supported by OpenStack but considered experimental in Virtuozzo Hybrid Infrastructure. It is recommended to test these configurations before using them in a production environment.
To improve virtual machine performance, stability, or enable additional capabilities, you can customize your VM flavors using various OpenStack flavor properties (extra specs). These properties let you fine-tune how compute, memory, and I/O resources are allocated to your VMs.
For a full list of supported settings, refer to the OpenStack documentation on flavor extra specifications.
Prerequisites
- To authorize further OpenStack commands, the OpenStack command-line client must be configured, as outlined in Connecting to OpenStack command-line interface.
NUMA node pinning
Non-Uniform Memory Access (NUMA) is a computer memory design used in multiprocessor systems, where memory access time depends on the memory location relative to a processor.
Modern servers typically have multiple NUMA nodes (for example, one per CPU socket). You can view the NUMA configuration of your host by using the numactl command. For example:
# numactl --hardware available: 2 nodes (0-1) node 0 cpus: 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64 66 68 70 72 74 76 78 80 82 84 86 88 90 92 94 node 0 size: 515135 MB node 0 free: 89297 MB node 1 cpus: 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 73 75 77 79 81 83 85 87 89 91 93 95 node 1 size: 516047 MB node 1 free: 99918 MB node distances: node 0 1 0: 10 21 1: 21 10
To achieve better performance, a virtual machine should ideally run within a single NUMA node, meaning all its virtual CPUs are pinned to CPUs on that node.
In the example above, a single NUMA node has approximately 512 GB of memory, so a VM cannot exceed that limit. In practice, you should allocate less than the full node capacity (not be more than 256 GB) to leave room for other workloads and overhead.
You may want to pin a virtual machine to a specific NUMA node in these cases:
- To achieve maximum performance per instance
- To run large instances (with memory comparable to a NUMA node's size)
- To attach GPU or other NUMA-sensitive devices
To pin a VM to a single NUMA node, set the flavor property hw:numa_nodes=1, where 1 is the number of NUMA nodes. For example:
# openstack --insecure flavor create --public single-numa-node --ram 16384 --disk 0 --vcpus 4 --property hw:numa_nodes=1
Then, use this flavor when creating new virtual machines.
Virtual CPU pinning
vCPU pinning (or CPU affinity) ensures that each vCPU of a VM is bound to a dedicated physical CPU thread. This prevents context switching between VMs and improves their performance.
To enable vCPU pinning, set the flavor property hw:cpu_policy=dedicated. For example:
# openstack --insecure flavor create --public dedicated-cpu --ram 16384 --disk 0 --vcpus 4 --property hw:cpu_policy=dedicated
Virtual machines created from this flavor will have dedicated CPU threads on the host.
CPU shares
You can assign CPU priority to virtual machines by configuring CPU shares. CPU scheduling priority depends on the number of vCPUs allocated to a VM.
If a VM does not have a custom CPU share value set, it uses the default share value of 19 per vCPU. For example, a VM with 4 vCPUs will have a default total share value of 76.
To adjust CPU priority:
- For higher priority, set a value greater than the default total (for example, 100)
- For lower priority, set a value lower than the default total (for example, 50)
To define CPU shares, set the flavor property quota:cpu_shares=<share>. For example:
# openstack --insecure flavor create --public high-priority --ram 16384 --disk 0 --vcpus 4 --property quota:cpu_shares=100 # openstack --insecure flavor create --public low-priority --ram 16384 --disk 0 --vcpus 4 --property quota:cpu_shares=50
If CPU contention occurs, a VM created from the high-priority flavor will receive more CPU time than one using the low-priority flavor.
Using vhost-blk
Currently, the feature does not work with Acronis Disaster Recovery or Acronis Backup.
You can improve VM I/O performance by enabling vhost-blk, which lets the host kernel handle block I/O operations instead of QEMU running them in user space. This reduces context switches and data copying between user and kernel space, resulting in lower latency and higher throughput.
To enable vhost-blk, set the flavor property hw:use_vhostblk='yes'. For example:
# openstack --insecure flavor create --public vhostblk-enabled --ram 16384 --disk 0 --vcpus 4 --property hw:use_vhostblk='yes'
Virtual machines created from this flavor will use the kernel's vhost-blk backend for improved disk performance.