Bug 2037998

Upstream issue referencing the same problem https://gitlab.com/libvirt/libvirt/-/issues/324

for visablity this is also breaking our openstack product
https://bugzilla.redhat.com/show_bug.cgi?id=2035518

The -1 issue with quota limits was fixed in upstream by commit

commit 9233f0fa8c8e031197c647f7bc980dee45283641
Author: antonios-f <anton.fadeev>
Date:   Thu Nov 17 09:53:23 2022 +0000

    src/util/vircgroupv2.c: interpret neg quota as "max"

Looking into the other part of the bug report.

The range check and documentation is fixed now as well in upstream.

commit ead6e1b00285cbd98e0f0727efb8adcb29ebc1ba
Author: Pavel Hrdina <phrdina>
Date:   Tue Jan 17 10:33:22 2023 +0100

    docs: document correct cpu shares limits with both cgroups v1 and v2

commit 38af6497610075e5fe386734b87186731d4c17ac
Author: Pavel Hrdina <phrdina>
Date:   Tue Jan 17 10:08:08 2023 +0100

    domain_validate: drop cpu.shares cgroup check

commit cf3414a85b8383d71d6ae2a53daf63c331cc2230
Author: Pavel Hrdina <phrdina>
Date:   Tue Jan 17 10:02:07 2023 +0100

    vircgroupv2: fix cpu.weight limits check

These will have to be backported but the fix mentioned in Comment 3 will be picked up by the latest rebase.

Preverified with:
libvirt-9.1.0-1.fc37.x86_64
libvirt-docs-9.1.0-1.fc37.x86_64

====================
Document check:
====================
[root@yisun-prevbug ~]# man virsh
...
   schedinfo
...
       Note: The cpu_shares parameter has a valid value range of 2-262144 with cgroups v1, 1-10000 with cgroups v2.


[root@yisun-prevbug ~]# cat libvirt/docs/formatdomain.rst | grep "using cgroups v2" -a5
   The optional ``shares`` element specifies the proportional weighted share for
   the domain. If this is omitted, it defaults to the OS provided defaults. NB,
   There is no unit for the value, it's a relative measure based on the setting
   of other VM, e.g. A VM configured with value 2048 will get twice as much CPU
   time as a VM configured with value 1024. The value should be in range
   [2, 262144] using cgroups v1, [1, 10000] using cgroups v2. :since:`Since 0.9.0`
``period``
   The optional ``period`` element specifies the enforcement interval (unit:
   microseconds). Within ``period``, each vCPU of the domain will not be allowed
   to consume more than ``quota`` worth of runtime. The value should be in range
   [1000, 1000000]. A period with value 0 means no value. :since:`Only QEMU


====================
Feature check:
====================

**** check cfs_quota can be set as negative values ****
https://gitlab.com/libvirt/libvirt/-/merge_requests/206

1. prepare a running vm with iothread enabled
# virsh dumpxml w10 | grep iothread -a
  <name>w10</name>
  <uuid>4f6fd482-438a-4af2-9965-d1bb4451ed29</uuid>
  <memory unit='KiB'>2097152</memory>
  <currentMemory unit='KiB'>2097152</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <iothreads>2</iothreads>
  <iothreadids>
    <iothread id='2'/>
    <iothread id='1'/>
  </iothreadids>

2. set its cpu quota related parameteres to 9999 and check cgroup parameters are actually changed
# virsh schedinfo w10 --set vcpu_quota=9999 emulator_quota=9999 global_quota=9999 iothread_quota=9999
Scheduler      : posix
cpu_shares     : 100
vcpu_period    : 100000
vcpu_quota     : 9999
emulator_period: 100000
emulator_quota : 9999
global_period  : 100000
global_quota   : 9999
iothread_period: 100000
iothread_quota : 9999

# pwd
/sys/fs/cgroup/machine.slice/machine-qemu\x2d6\x2dw10.scope

[root@yisun-prevbug machine-qemu\x2d6\x2dw10.scope]# cat libvirt/cpu.max
9999 100000
[root@yisun-prevbug machine-qemu\x2d6\x2dw10.scope]# cat libvirt/emulator/cpu.max
9999 100000
[root@yisun-prevbug machine-qemu\x2d6\x2dw10.scope]# cat libvirt/vcpu0/cpu.max
9999 100000
[root@yisun-prevbug machine-qemu\x2d6\x2dw10.scope]# cat libvirt/iothread2/cpu.max
9999 100000
[root@yisun-prevbug machine-qemu\x2d6\x2dw10.scope]# cat libvirt/iothread1/cpu.max
9999 100000
[root@yisun-prevbug machine-qemu\x2d6\x2dw10.scope]# cat libvirt/vcpu1/cpu.max
9999 100000

3. set these parameters again with negative values
# virsh schedinfo w10 --set vcpu_quota=-1 emulator_quota=-22 global_quota=-333 iothread_quota=-4444
Scheduler      : posix
cpu_shares     : 100
vcpu_period    : 100000
vcpu_quota     : 17592186044415
emulator_period: 100000
emulator_quota : 17592186044415
global_period  : 100000
global_quota   : 17592186044415
iothread_period: 100000
iothread_quota : 17592186044415

4. check the cgroup parameters are actually changed back to 'max'
[root@yisun-prevbug machine-qemu\x2d6\x2dw10.scope]# cat libvirt/cpu.max
max 100000
[root@yisun-prevbug machine-qemu\x2d6\x2dw10.scope]# cat libvirt/emulator/cpu.max
max 100000
[root@yisun-prevbug machine-qemu\x2d6\x2dw10.scope]# cat libvirt/vcpu0/cpu.max
max 100000
[root@yisun-prevbug machine-qemu\x2d6\x2dw10.scope]# cat libvirt/iothread2/cpu.max
max 100000
[root@yisun-prevbug machine-qemu\x2d6\x2dw10.scope]# cat libvirt/iothread1/cpu.max
max 100000
[root@yisun-prevbug machine-qemu\x2d6\x2dw10.scope]# cat libvirt/vcpu1/cpu.max
max 100000



**** check cpu shares error message is correct for cgroup2 ****
https://gitlab.com/redhat/rhel/src/libvirt/-/merge_requests/73

postive tests:
[root@yisun-prevbug ~]# virsh schedinfo w10 --set cpu_shares=1
Scheduler      : posix
cpu_shares     : 1
vcpu_period    : 100000
vcpu_quota     : 17592186044415
emulator_period: 100000
emulator_quota : 17592186044415
global_period  : 100000
global_quota   : 17592186044415
iothread_period: 100000
iothread_quota : 17592186044415

[root@yisun-prevbug ~]# virsh schedinfo w10 --set cpu_shares=10000
Scheduler      : posix
cpu_shares     : 10000
vcpu_period    : 100000
vcpu_quota     : 17592186044415
emulator_period: 100000
emulator_quota : 17592186044415
global_period  : 100000
global_quota   : 17592186044415
iothread_period: 100000
iothread_quota : 17592186044415

negative tests:
[root@yisun-prevbug ~]# virsh schedinfo w10 --set cpu_shares=10001
Scheduler      : posix
error: invalid argument: shares '10001' must be in range [1, 10000]

[root@yisun-prevbug ~]# virsh schedinfo w10 --set cpu_shares=0
Scheduler      : posix
error: invalid argument: shares '0' must be in range [1, 10000]

[root@yisun-prevbug ~]# virsh schedinfo w10 --set cpu_shares=a
Scheduler      : posix
error: invalid argument: Invalid value for field 'cpu_shares': expected unsigned long long

[root@yisun-prevbug ~]# virsh schedinfo w10 --set cpu_shares=-1
Scheduler      : posix
error: invalid argument: shares '18446744073709551615' must be in range [1, 10000]

====================
QE follow-up tasks:
====================
1. modify cgorup2 polarion cases and corresponding auto scripts about **** check cfs_quota can be set as negative values **** 
2. for document modification, no need to add cases
3. for **** check cpu shares error message is correct for cgroup2 ****, no need to add or modify cases for now, cgroup2's range check is not all covered by libvirt, in other situations a dbus error will be reported and is clear enough
[root@yisun-prevbug ~]# virsh blkiotune w10 --weight 1234321421
error: Unable to change blkio parameters
error: error from service: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Value specified in IOWeight is out of range

Verified with:
libvirt-9.0.0-2.el9.x86_64
libvirt-docs-9.0.0-2.el9.x86_64

Resutl is passed, steps are same as comment6

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 (libvirt bug fix and enhancement update), 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://access.redhat.com/errata/RHBA-2023:2171