Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
The cpu_shares value of domain xml should be consistent with return value of schedinfo.
Version-Release number of selected component (if applicable):
libvirt-0.10.2-22.el6.x86_64
qemu-kvm-0.12.1.2-2.393.el6.x86_64
How reproducible:
100%
Steps:
0. Define and start a domain r6.
1. Scenario 1, negative value(example: -1 and -76):
[root@test ~]# virsh schedinfo r6 --set cpu_shares=-1 --live
Scheduler : posix
cpu_shares : 262144
vcpu_period : 100000
vcpu_quota : -1
emulator_period: 100000
emulator_quota : -1
[root@test ~]# virsh dumpxml r6| grep -3 cputune
<memory unit='KiB'>1048576</memory>
<currentMemory unit='KiB'>1048576</currentMemory>
<vcpu placement='static'>4</vcpu>
<cputune>
<shares>18446744073709551615</shares> <==The value should be 262144, same as return of schedinfo.
</cputune>
[root@test ~]# virsh schedinfo r6 --set cpu_shares=-76 --live
Scheduler : posix
cpu_shares : 262144
vcpu_period : 100000
vcpu_quota : -1
emulator_period: 100000
emulator_quota : -1
[root@test ~]# virsh dumpxml r6| grep -3 cputune
<memory unit='KiB'>1048576</memory>
<currentMemory unit='KiB'>1048576</currentMemory>
<vcpu placement='static'>4</vcpu>
<cputune>
<shares>18446744073709551540</shares> <==The value should be 262144, same as return of schedinfo I think.
</cputune>
2. Scenario 2, boundary value（it's 0 ,1 and 262145).
[root@test ~]# virsh schedinfo r6 --set cpu_shares=0 --live
Scheduler : posix
cpu_shares : 2
vcpu_period : 100000
vcpu_quota : -1
emulator_period: 100000
emulator_quota : -1
[root@test ~]# virsh dumpxml r6| grep -3 cputune
[root@test ~]# <== No <cputune> element added, for 0 and 1, the minimal value of 2 should be added to domian xml.
[root@test ~]# virsh schedinfo r6 --set cpu_shares=1 --live
Scheduler : posix
cpu_shares : 2
vcpu_period : 100000
vcpu_quota : -1
emulator_period: 100000
emulator_quota : -1
[root@test ~]# virsh dumpxml r6| grep -3 cputune
<memory unit='KiB'>1048576</memory>
<currentMemory unit='KiB'>1048576</currentMemory>
<vcpu placement='static'>4</vcpu>
<cputune>
<shares>1</shares> <==Should be 2.
</cputune>
[root@test ~]# virsh schedinfo r6 --set cpu_shares=262145 --live
Scheduler : posix
cpu_shares : 262144
vcpu_period : 100000
vcpu_quota : -1
emulator_period: 100000
emulator_quota : -1
[root@test ~]# virsh dumpxml r6| grep -3 cputune
<memory unit='KiB'>1048576</memory>
<currentMemory unit='KiB'>1048576</currentMemory>
<vcpu placement='static'>4</vcpu>
<cputune>
<shares>262145</shares> <==This should be 262144, arger values are capped at the maximum.
</cputune>
Actual results:
As description above, also reproduced this issue with --config.
Such as:
[root@test ~]# virsh schedinfo r6 --set cpu_shares=1000000000 --config
Scheduler : posix
cpu_shares : 1000000000
vcpu_period : 0
vcpu_quota : 0
emulator_period: 0
emulator_quota : 0
[root@test ~]# virsh dumpxml r6 --inactive | grep -A5 cputune
<cputune>
<shares>1000000000</shares>
</cputune>
Expected results:
The cpu_shares value of domain xml should be consistent with return value of schedinfo, especially negative and boundary values. Perhaps virsh command should reply a warning/error message to block them.
Note: The cpu_shares parameter has a valid value range of 0-262144; Negative values are wrapped to positive, and larger values are capped at the maximum. Therefore, -1 is a useful shorthand for 262144. On the Linux kernel, the values 0 and 1 are automatically converted to a minimal value of 2. (From man virsh)
I can reproduce this with:
# rpm -qa libvirt kernel qemu-kvm
qemu-kvm-0.12.1.2-2.401.el6.x86_64
kernel-2.6.32-412.el6.x86_64
libvirt-0.10.2-23.el6.x86_64
Steps and results are same with the description.
It seems libvirt is using different value to stand for -1 between virsh command output(shorthand for 262144) and guest XML(shorthand for 18446744073709551615).
Comment 5Martin Kletzander
2014-04-01 09:36:40 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
Comment 7RHEL Program Management
2014-04-04 20:57:09 UTC
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.
Description of problem: The cpu_shares value of domain xml should be consistent with return value of schedinfo. Version-Release number of selected component (if applicable): libvirt-0.10.2-22.el6.x86_64 qemu-kvm-0.12.1.2-2.393.el6.x86_64 How reproducible: 100% Steps: 0. Define and start a domain r6. 1. Scenario 1, negative value(example: -1 and -76): [root@test ~]# virsh schedinfo r6 --set cpu_shares=-1 --live Scheduler : posix cpu_shares : 262144 vcpu_period : 100000 vcpu_quota : -1 emulator_period: 100000 emulator_quota : -1 [root@test ~]# virsh dumpxml r6| grep -3 cputune <memory unit='KiB'>1048576</memory> <currentMemory unit='KiB'>1048576</currentMemory> <vcpu placement='static'>4</vcpu> <cputune> <shares>18446744073709551615</shares> <==The value should be 262144, same as return of schedinfo. </cputune> [root@test ~]# virsh schedinfo r6 --set cpu_shares=-76 --live Scheduler : posix cpu_shares : 262144 vcpu_period : 100000 vcpu_quota : -1 emulator_period: 100000 emulator_quota : -1 [root@test ~]# virsh dumpxml r6| grep -3 cputune <memory unit='KiB'>1048576</memory> <currentMemory unit='KiB'>1048576</currentMemory> <vcpu placement='static'>4</vcpu> <cputune> <shares>18446744073709551540</shares> <==The value should be 262144, same as return of schedinfo I think. </cputune> 2. Scenario 2, boundary value（it's 0 ,1 and 262145). [root@test ~]# virsh schedinfo r6 --set cpu_shares=0 --live Scheduler : posix cpu_shares : 2 vcpu_period : 100000 vcpu_quota : -1 emulator_period: 100000 emulator_quota : -1 [root@test ~]# virsh dumpxml r6| grep -3 cputune [root@test ~]# <== No <cputune> element added, for 0 and 1, the minimal value of 2 should be added to domian xml. [root@test ~]# virsh schedinfo r6 --set cpu_shares=1 --live Scheduler : posix cpu_shares : 2 vcpu_period : 100000 vcpu_quota : -1 emulator_period: 100000 emulator_quota : -1 [root@test ~]# virsh dumpxml r6| grep -3 cputune <memory unit='KiB'>1048576</memory> <currentMemory unit='KiB'>1048576</currentMemory> <vcpu placement='static'>4</vcpu> <cputune> <shares>1</shares> <==Should be 2. </cputune> [root@test ~]# virsh schedinfo r6 --set cpu_shares=262145 --live Scheduler : posix cpu_shares : 262144 vcpu_period : 100000 vcpu_quota : -1 emulator_period: 100000 emulator_quota : -1 [root@test ~]# virsh dumpxml r6| grep -3 cputune <memory unit='KiB'>1048576</memory> <currentMemory unit='KiB'>1048576</currentMemory> <vcpu placement='static'>4</vcpu> <cputune> <shares>262145</shares> <==This should be 262144, arger values are capped at the maximum. </cputune> Actual results: As description above, also reproduced this issue with --config. Such as: [root@test ~]# virsh schedinfo r6 --set cpu_shares=1000000000 --config Scheduler : posix cpu_shares : 1000000000 vcpu_period : 0 vcpu_quota : 0 emulator_period: 0 emulator_quota : 0 [root@test ~]# virsh dumpxml r6 --inactive | grep -A5 cputune <cputune> <shares>1000000000</shares> </cputune> Expected results: The cpu_shares value of domain xml should be consistent with return value of schedinfo, especially negative and boundary values. Perhaps virsh command should reply a warning/error message to block them. Note: The cpu_shares parameter has a valid value range of 0-262144; Negative values are wrapped to positive, and larger values are capped at the maximum. Therefore, -1 is a useful shorthand for 262144. On the Linux kernel, the values 0 and 1 are automatically converted to a minimal value of 2. (From man virsh)