Bug 1007698
Summary: | The cpu_shares value of domain xml should be consistent with return value of schedinfo. | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | CongDong <codong> |
Component: | libvirt | Assignee: | Martin Kletzander <mkletzan> |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.0 | CC: | ajia, codong, dyuan, gsun, jiahu, mkletzan, mzhan, pzhang, rbalakri |
Target Milestone: | rc | Keywords: | Upstream |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | libvirt-1.2.7-1.el7 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | 998431 | Environment: | |
Last Closed: | 2015-03-05 07:24:46 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 998431 | ||
Bug Blocks: |
Comment 2
zhengqin
2013-11-19 09:29:14 UTC
Fixed upstream with v1.2.0-76-g231656b -- v1.2.0-79-gea130e3: commit ea130e3bf666397a05a674ffcf15b9ab170b2255 Author: Martin Kletzander <mkletzan> Date: Mon Dec 9 11:32:48 2013 +0100 conf: don't format memtune with unlimited values commit 8d7c668e64b5bcd2d08aa5057c9aff43d1f73dfd Author: Martin Kletzander <mkletzan> Date: Wed Dec 4 18:59:52 2013 +0100 qemu: Fix minor inconsistency in error message commit 0c2fdd7b14cbfc6ced77ed2a24f01f07a8a2f657 Author: Martin Kletzander <mkletzan> Date: Wed Dec 4 18:56:02 2013 +0100 qemu: Report VIR_DOMAIN_MEMORY_PARAM_UNLIMITED properly commit 231656bbeb9e4d3bedc44362784c35eee21cf0f4 Author: Martin Kletzander <mkletzan> 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. 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 |