Hi all,


I am trying to run some performance tests using libvirt 1.2.17. For these tests it is necessary to set a specific affinity for the VCPUs of a running VM.

The problem is, that I noticed a significant performance drop in my metrics when using ‘vcpupin’ from the virsh console instead of running ‘taskset’ natively.


Specifically the methods I am comparing are


1.       Using native shell

taskset –a –cp $MY_CPUSET $MY_DOMAIN_PID


2.       Using virsh console (performance ~30% down)

for all $VCPUs

virsh vcpupin my_domain –cpulist $MY_CPUSET –vcpu $VCPU –live

                virsh emulatorpin my_domain –cpulist $MY_CPUSET –live


It seems that the usage of ‘vcpupin’ causes a performance drop even if it is run alongside ‘taskset’ on the same $CPU_SET


Functionally everything seems to be working when I check the ‘/proc/’ filesystem

                cat /proc/MY_DOMAIN_PID/*/status | grep Cpus_allowed_list


My questions are:

1.       Has anybody else noticed this?

2.       Is this expected based on the implementation details?

3.       Is this a bug that is fixed in a newer libvirt version?

4.       Is there a solution to this issue?





George Paraskevopoulos   


https://newoldstamp.com/editor/images/phone_g.png + 30 210 667 7689

https://newoldstamp.com/editor/images/email_g.png geopar@intracom-telecom.com

https://newoldstamp.com/editor/images/address_g.png 19.7 km Markopoulou Ave 19002 Peania, Athens, Greece


The information in this e-mail message and any attachments are intended only for the individual or entity to whom it is addressed and may be confidential. If you have received this transmission in error, and you are not an intended recipient, be aware that any copying, disclosure, distribution or use of this transmission or its contents is prohibited.  INTRACOM TELECOM and the sender accept no liability for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this email. Views or opinions expressed in this message may be those of the author and may not necessarily represent those of INTRACOM TELECOM.