Red Hat Bugzilla – Bug 1007698
The cpu_shares value of domain xml should be consistent with return value of schedinfo.
Last modified: 2016-04-26 12:22:46 EDT
Can reproduce on RHEL7: # rpm -qa libvirt qemu-kvm libvirt-1.1.1-4.el7.x86_64 qemu-kvm-1.5.3-3.el7.x86_64
Fixed upstream with v1.2.0-76-g231656b -- v1.2.0-79-gea130e3: commit ea130e3bf666397a05a674ffcf15b9ab170b2255 Author: Martin Kletzander <mkletzan@redhat.com> Date: Mon Dec 9 11:32:48 2013 +0100 conf: don't format memtune with unlimited values commit 8d7c668e64b5bcd2d08aa5057c9aff43d1f73dfd Author: Martin Kletzander <mkletzan@redhat.com> Date: Wed Dec 4 18:59:52 2013 +0100 qemu: Fix minor inconsistency in error message commit 0c2fdd7b14cbfc6ced77ed2a24f01f07a8a2f657 Author: Martin Kletzander <mkletzan@redhat.com> Date: Wed Dec 4 18:56:02 2013 +0100 qemu: Report VIR_DOMAIN_MEMORY_PARAM_UNLIMITED properly commit 231656bbeb9e4d3bedc44362784c35eee21cf0f4 Author: Martin Kletzander <mkletzan@redhat.com> Date: Wed Dec 4 16:54:29 2013 +0100 cgroups: Redefine what "unlimited" means wrt memory limits
1> for patches in comment 3 , it seems like that is unrelated to this bug . and i found the following patch , but i am not sure if it is the correct one : https://www.redhat.com/archives/libvir-list/2014-March/msg00921.html 2> for this bug , according to the description verify it via following steps: version: kernel-3.10.0-203.el7.x86_64 qemu-kvm-rhev-2.1.2-8.el7.x86_64 libvirt-1.2.8-6.el7.x86_64 steps to verify : 1. negative value # virsh schedinfo r7 Scheduler : posix cpu_shares : 1024 vcpu_period : 100000 vcpu_quota : -1 emulator_period: 100000 emulator_quota : -1 1.1 set value as -1 : # virsh schedinfo r7 --set cpu_shares=-1 --live Scheduler : posix cpu_shares : 262144 vcpu_period : 100000 vcpu_quota : -1 emulator_period: 100000 emulator_quota : -1 # virsh dumpxml r7 | grep cputune -A 5 <cputune> <shares>262144</shares> <=== the value is 262114 , same as return of schedinfo </cputune> 1.2 set value as -100 : # virsh schedinfo r7 --set cpu_shares=-100 --live Scheduler : posix cpu_shares : 262144 vcpu_period : 100000 vcpu_quota : -1 emulator_period: 100000 emulator_quota : -1 # virsh dumpxml r7 | grep cputune -A 5 <cputune> <shares>262144</shares> <=== the value is 262114 , same as return of schedinfo </cputune> <resource> 1.3 set large value , larger values are capped at the maximum. # virsh schedinfo r7 --set cpu_shares=18446744073709551615 --live Scheduler : posix cpu_shares : 262144 vcpu_period : 100000 vcpu_quota : -1 emulator_period: 100000 emulator_quota : -1 # virsh dumpxml r7 | grep cputune -A 3 <cputune> <shares>262144</shares> </cputune> 2. for set value 0 and 1, the minimal value of 2 will be added to domian xml. # virsh schedinfo r7 --set cpu_shares=0 --live Scheduler : posix cpu_shares : 2 vcpu_period : 100000 vcpu_quota : -1 emulator_period: 100000 emulator_quota : -1 # virsh dumpxml r7 | grep cputune -A 3 <cputune> <shares>2</shares> <=====the minimal value of 2 was added , and same as return schedinfo </cputune> # virsh schedinfo r7 --set cpu_shares=1 --live Scheduler : posix cpu_shares : 2 vcpu_period : 100000 vcpu_quota : -1 emulator_period: 100000 emulator_quota : -1 # virsh dumpxml r7 | grep cputune -A 3 <cputune> <shares>2</shares> <=====the minimal value of 2 was added , and same as return schedinfo </cputune> 3. boundary value , larger values are capped at the maximum.: # virsh schedinfo r7 --set cpu_shares=262145 --live Scheduler : posix cpu_shares : 262144 vcpu_period : 100000 vcpu_quota : -1 emulator_period: 100000 emulator_quota : -1 # virsh dumpxml r7 | grep cputune -A 3 <cputune> <shares>262144</shares> <=== the value is 262114 , same as return of schedinfo </cputune> 4. set value as -1 with --config # virsh schedinfo r7 --set cpu_shares=-1 --config Scheduler : posix cpu_shares : 18446744073709551615 vcpu_period : 0 vcpu_quota : 0 emulator_period: 0 emulator_quota : 0 check in domain xml , the value will not be changed. # virsh dumpxml r7 | grep cputune -A 3 <cputune> <shares>2</shares> </cputune> restart domain , check the value which will be capped at the maximum. # virsh destroy r7 ; virsh start r7 Domain r7 destroyed Domain r7 started # virsh schedinfo r7 Scheduler : posix cpu_shares : 262144 vcpu_period : 100000 vcpu_quota : -1 emulator_period: 100000 emulator_quota : -1 # virsh dumpxml r7 | grep cputune -A 5 <cputune> <shares>262144</shares> <=====the value was capped as maximum </cputune> 5.for a shut off domain: # virsh list --all Id Name State ---------------------------------------------------- - r7 shut off 5.1 set value -1 with --config # virsh schedinfo r7 --set cpu_shares=-1 --config Scheduler : posix cpu_shares : 18446744073709551615 vcpu_period : 0 vcpu_quota : 0 emulator_period: 0 emulator_quota : 0 # virsh dumpxml r7 | grep cputune -A 5 <cputune> <shares>18446744073709551615</shares> </cputune> start the domain , the value is capped at the maximum : # virsh start r7 Domain r7 started # virsh dumpxml r7 | grep cputune -A 5 <cputune> <shares>262144</shares> </cputune> # virsh schedinfo r7 Scheduler : posix cpu_shares : 262144 vcpu_period : 100000 vcpu_quota : -1 emulator_period: 100000 emulator_quota : -1 5.2 for a shut off domain , set value 0 # virsh schedinfo r7 --set cpu_shares=0 --config Scheduler : posix cpu_shares : 0 vcpu_period : 0 vcpu_quota : 0 emulator_period: 0 emulator_quota : 0 start to check , the minimal value of 2 will be added to domain. # virsh start r7 Domain r7 started # virsh schedinfo r7 Scheduler : posix cpu_shares : 2 vcpu_period : 100000 vcpu_quota : -1 emulator_period: 100000 emulator_quota : -1 # virsh dumpxml r7 | grep cputune -A 3 <cputune> <shares>2</shares> </cputune> According to bug description , now the cpu_shares value of domain xml are consistent with return value of schedinfo . 3> note : for --config option , a small question i am not sure if it is expected result . # virsh schedinfo r7 --set cpu_shares=-1 --config Scheduler : posix cpu_shares : 18446744073709551615 <==== return a large value vcpu_period : 0 vcpu_quota : 0 emulator_period: 0 emulator_quota : 0 but it has no effect on domain , the value is capped at the maximum (262144) after restart domain . details like above steps 4 and step 5 .
That is actually the desired output. For values 0 and 1 the output is 2 because that's what you'll get from cgroups when you set 0 or 1 there. This was intentionally done so that the output of virsh matches the data kernel operates with. Different kernels might have different boundaries, so we cannot say/enforce any real limits. However, lower or higher values are kept in the XML as specified. So if you get the info from running domain (dumpxml without '--inactive' or schedinfo, while running) you'll get the capped value according to kernel. If, however you get the info when the domain is not running (or use '--inactive' for dumpxml or'--config' for schedinfo), the value is taken right from the XML and it shows the exact data you specified there. And -1 wraps to maximum we can use. All this is in the manual already, and makes sense for me. If there is a bit you want to adjust, I can have a look at it, but it makes sense from my point of view.
Thanks for the info . According to comment 7 and comment 8 , move the bug to verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0323.html