Performance Tuning of VM by CPU Pinning

Published Date

February 28, 2017


4 minutes

Written By

Sharanappa Banakara

Many VM operating parameters can be set to get maximum system performance for single or multiple VMs running on a KVM Host. Some VM operating parameters are configured on the KVM Host and can be modified at any time when the VM instance is running, while others are set on the VM and are only configured when the VM Instance is shut down. CPU pinning is one of the best solution to gain VM’s performance. Real-time applications have stringent requirements with respect to jitter, latency, quality of service and packet loss. The migration of real-time applications to an all-software environment requires a deterministic response to failures and performance in the scheduler of the hypervisor and the host Operating System (OS).

The following sections contain some VM performance tuning recommendations to improve system performance. These recommendations are considered as general guidelines and are not exhaustive. Please refer to the tech-pubs provided by your Linux OS & KVM Host vendors. For example, Redhat provides documentation on using virt-manager and optimizing VM performance.

CPU pinning:

To determine the host system’s processor and CPU details, perform the following steps:
Execute the following command to know how many vCPUs are assigned to host CPUs:
# lscpu -p
# The following is the parsable format, which can be fed to other
# programs. Each different item in every column has an unique ID
# starting from zero.
# CPU,Core,Socket,Node,,L1d,L1i,L2,L3
The first column shows the logical CPU number of a CPU as used by the Linux kernel, the second column shows the logical core number, so this information can be used for cpu pinning. CPU pinning makes a VM only get a CPU time from a specific CPU or a set of CPUs. Pinning is performed on each logical CPU of guest VM against each core ID in the host system. The CPU pinning information will be lost every time VM instance is shutdown and restarted. So to avoid entering the pinning information again, you must update KVM configuration XML file on the host system.

To update the pinning information in the KVM configuration XML file:
Ensure that no two VM instances are allocated with the same physical cores on host system
Shutdown the VM instance.
Enter the following command.
The command executes with the following output:
# virsh
Welcome to virsh, the virtualization interactive terminal.
Type: ‘help’ for help with commands
‘quit’ to quit
virsh #
Enter the following command to edit the VM instance:
virsh # edit
Search for vcpu placementattribute.14680064

Enter CPU pinning information as shown:

/machinePS: Ensure that no two VM instances have same physical core affinity. For example, no VM should be pinned to 0,1,2,3, 8,9,10, or 11 as these CPUs belong to physical core assigned to instance VM1 if instance VM1 has affinity of 0,1,2,3 . Also, all remaining VM instances running on the same host must be assigned with affinity, otherwise the VMs without the affinity might impact the performance of VMs having affinity.
Save and exit the XML file.

CPU Configuration for VM Instance:

If the Copy host CPU configuration was considered while creating a VM instance, the host configuration may not be copied on the VM instance. To resolve this issue, you should edit the cpu mode to “host-passthrough” using a “virsh” command in the host system.
So to edit VM’s CPU mode, follow below steps:
Shutdown the VM instance.
Enter the following command.
virsh edit tweet

Intel tweet

Replace the cpu mode attribute with the following:

PS: the topology details entered should be same as the topology details while creating the VM instance.
For example, if the guest topology was set to 1 socket, 4 cores & 1 thread the same should be entered in this XML file.
save the xml file and start vm using ‘start ’
Enter the following command to verify the host CPU configuration on the VM instance:
cat /proc/cpuinfo and verify the cpu conf tweet
processor : 15
vendor_id : GenuineIntel
cpu family : 6
model : 45
model name : Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz
stepping : 7
microcode : 0x710
cpu MHz : 2900.000
cache size : 20480 KB
physical id : 0
siblings : 16
core id : 7
cpu cores : 8
apicid : 15
initial apicid : 15
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips : 5786.15
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual tweet

About the Author

Sharanappa Banakara

Related Posts

No content available.