Bug 998431

Summary: The cpu_shares value of domain xml should be consistent with return value of schedinfo.
Product: Red Hat Enterprise Linux 6 Reporter: Hu Jianwei <jiahu>
Component: libvirtAssignee: Martin Kletzander <mkletzan>
Status: CLOSED WONTFIX QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.5CC: acathrow, ajia, codong, dallan, dyuan, gsun, mzhan
Target Milestone: rcKeywords: Upstream
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1007698 (view as bug list) Environment:
Last Closed: 2014-04-04 20:57:09 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:    
Bug Blocks: 1007698    

Description Hu Jianwei 2013-08-19 10:05:19 UTC
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 06:29:49 UTC
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 08:53:37 UTC
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 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 7 RHEL 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.