Description of problem: Error message need to improve for virsh schedinfo <domain> --set global_quota Version-Release number of selected component (if applicable): libvirt-5.6.0-3.module+el8.1.0+4110+a6d45c3d.x86_64 qemu-kvm-4.1.0-5.module+el8.1.0+4076+b5e41ebc.x86_64 How reproducible: 100% Steps to Reproduce: Get the schedule information from the command: # virsh schedinfo avocado-vt-vm1 Scheduler : posix cpu_shares : 1024 vcpu_period : 1000 vcpu_quota : 18446744073709550 emulator_period: 1000 emulator_quota : 1000 global_period : 100000 global_quota : -1 iothread_period: 100000 iothread_quota : -1 1. Get the value range for global_quota from the output of the command: # virsh schedinfo avocado-vt-vm1 --set global_quota=1 Scheduler : posix error: invalid argument: value of 'global_quota' is out of range [1000, 18446744073709551] 2. Tried to set the value to the max value 18446744073709551 #virsh schedinfo avocado-vt-vm1 --set global_quota=18446744073709551 Scheduler : posix error: Invalid value '18446744073709551' for 'cpu.cfs_quota_us': Invalid argument 3. Tried to set the value to a value between the max and min value #virsh schedinfo avocado-vt-vm1 --set global_quota=1844674407370 Scheduler : posix error: Invalid value '1844674407370' for 'cpu.cfs_quota_us': Invalid argument 4. Tried to set the value to the min value #virsh schedinfo avocado-vt-vm1 --set global_quota=1000 Scheduler : posix error: Invalid value '1000' for 'cpu.cfs_quota_us': Invalid argument Actual results: In the first command, we get the value is out of range of [1000,18446744073709551]. But in the following command lines, we can't set any value correctly. The error messages are confusing for a user who is not familar with cgroup internal logic. Expected results: Give a clear error message that the value is not valid according the cgroup intenal logic except the value need to be in the range of [1000,18446744073709551]. Additional information: When the vcpu_quota is changed from 18446744073709550 to a smaller value , such as 184467. The global_quota can be set successfully. # virsh schedinfo avocado-vt-vm1 --set global_quota=18446700 Scheduler : posix cpu_shares : 1024 vcpu_period : 1000 vcpu_quota : 184467 emulator_period: 1000 emulator_quota : -1 global_period : 100000 global_quota : 18446700 iothread_period: 100000 iothread_quota : 18446700
I was not able to reproduce this issue on the latest RHEL-8.2, Jing, can you please retest it and possibly close it? The error message is caused by kernel where they did not accept the value. The only thing we will get from kernel is -EINVAL.
I tested it with below version and the bug is not reproduced - libvirt-daemon-6.0.0-9.virtcov.el8.x86_64 qemu-kvm-common-4.2.0-10.module+el8.2.0+5740+c3dff59e.x86_64
Hi Pavel, I can reproduce the issue with libvirt-6.6.0-4.el8.x86_64 and systemd-239-40.el8.x86_64. It seems systemd and libvirt has different allowed value range. Would you help to check it please? Thanks. 1.# virsh schedinfo vm1 vcpu_quota=100 Scheduler : posix error: invalid argument: value of 'vcpu_quota' is out of range [1000, 18446744073709551] 2.# virsh schedinfo vm1 vcpu_quota=18446744073709551 Scheduler : posix error: Invalid value '18446744073709551' for 'cpu.cfs_quota_us': Invalid argument 3.# virsh schedinfo vm1 vcpu_quota=1844674407370955 Scheduler : posix error: Invalid value '1844674407370955' for 'cpu.cfs_quota_us': Invalid argument 4.# virsh schedinfo vm1 vcpu_quota=18446744073709 Scheduler : posix error: Invalid value '18446744073709' for 'cpu.cfs_quota_us': Invalid argument 5.# virsh schedinfo vm1 vcpu_quota=1844674407370 Scheduler : posix cpu_shares : 1024 vcpu_period : 100000 vcpu_quota : 1844674407370 emulator_period: 100000 emulator_quota : -1 global_period : 100000 global_quota : -1 iothread_period: 100000 iothread_quota : -1 6.Reproduce with pure cgroup cmd: #echo 18446744073709 > /sys/fs/cgroup/cpu\,cpuacct/machine.slice/machine-qemu\\x2d2\\x2dvm1.scope/cpu.cfs_quota_us; echo $? -bash: echo: write error: Invalid argument 1 # echo 1844674407370 > /sys/fs/cgroup/cpu\,cpuacct/machine.slice/machine-qemu\\x2d2\\x2dvm1.scope/cpu.cfs_quota_us; echo $? 0
Upstream commits: ed1ba69f5a vircgroup: fix cpu quota maximum limit 98a09ca48e vircgroupv2: use defines for cpu period and quota limits bc760f4d7c vircgroupv1: use defines for cpu period and quota limits a818e3f6f0 qemu: move cgroup cpu period and quota defines to vircgroup.h
Verified in versions: libvirt-daemon-7.0.0-1.module+el8.4.0+9464+3e71831a.x86_64 qemu-kvm-5.2.0-2.module+el8.4.0+9186+ec44380f.x86_64 S1. Use "virsh schedinfo" to set global_quota value 1. Display the current schedule info # virsh schedinfo vm1 Scheduler : posix cpu_shares : 1024 vcpu_period : 100000 vcpu_quota : -1 emulator_period: 100000 emulator_quota : -1 global_period : 100000 global_quota : -1 iothread_period: 100000 iothread_quota : -1 2. Try to set a value and get the value range. # virsh schedinfo vm1 --set global_quota=1 Scheduler : posix error: invalid argument: value of 'global_quota' is out of range [1000, 17592186044415] 3. Set the "global_quota" to the minimal value # virsh schedinfo vm1 --set global_quota=1000 Scheduler : posix cpu_shares : 1024 vcpu_period : 100000 vcpu_quota : -1 emulator_period: 100000 emulator_quota : -1 global_period : 100000 global_quota : 1000 iothread_period: 100000 iothread_quota : 1000 Result: The value is changed as expect. 4.Set the "global_quota" to the maximal value # virsh schedinfo vm1 --set global_quota=17592186044415 Scheduler : posix cpu_shares : 1024 vcpu_period : 100000 vcpu_quota : -1 emulator_period: 100000 emulator_quota : -1 global_period : 100000 global_quota : 17592186044415 iothread_period: 100000 iothread_quota : 17592186044415 Result: The value is changed as expect.
*** Bug 1915733 has been marked as a duplicate of this bug. ***
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 (virt:av 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-2021:2098