Bug 998431 - The cpu_shares value of domain xml should be consistent with return value of schedinfo.
The cpu_shares value of domain xml should be consistent with return value of ...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.5
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Martin Kletzander
Virtualization Bugs
: Upstream
Depends On:
Blocks: 1007698
  Show dependency treegraph
 
Reported: 2013-08-19 06:05 EDT by Hu Jianwei
Modified: 2014-04-04 16:57 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1007698 (view as bug list)
Environment:
Last Closed: 2014-04-04 16:57:09 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hu Jianwei 2013-08-19 06:05:19 EDT
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)
Comment 2 CongDong 2013-09-11 02:29:49 EDT
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.
Comment 3 Alex Jia 2013-09-29 04:53:37 EDT
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 5 Martin Kletzander 2014-04-01 05:36:40 EDT
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
Comment 7 RHEL Product and Program Management 2014-04-04 16:57:09 EDT
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Note You need to log in before you can comment on or make changes to this bug.