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

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.