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:
[cgroup][modular_deamon] Libvirt cannot operate vm control groups after restarting virtqemud
Versions:
libvirt-8.2.0-1.el9.x86_64
systemd-250-4.el9.x86_64
kernel-5.14.0-75.el9.x86_64
How reproducible:
100%
Steps:
1. Have a running vm
[root@dell-per730-61 guest_resource_control]# virsh start avocado-vt-vm1
Domain 'avocado-vt-vm1' started
2. Run some SET/GET cgroup related virsh cmd, and nothing run
[root@dell-per730-61 guest_resource_control]# virsh memtune avocado-vt-vm1 --hard-limit=222222222
[root@dell-per730-61 guest_resource_control]# virsh memtune avocado-vt-vm1
hard_limit : 222222220
soft_limit : unlimited
swap_hard_limit: unlimited
[root@dell-per730-61 guest_resource_control]# virsh blkiotune avocado-vt-vm1
weight : 100
device_weight :
device_read_iops_sec:
device_write_iops_sec:
device_read_bytes_sec:
device_write_bytes_sec:
[root@dell-per730-61 guest_resource_control]# virsh schedinfo avocado-vt-vm1
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
3. Restart virtqemud
[root@dell-per730-61 guest_resource_control]# systemctl restart virtqemud
4. Now the cgroup related virsh cmds will return errors
[root@dell-per730-61 guest_resource_control]# virsh memtune avocado-vt-vm1
error: Unable to get memory parameters
error: Requested operation is not valid: cgroup memory controller is not mounted
[root@dell-per730-61 guest_resource_control]# virsh memtune avocado-vt-vm1 --hard-limit=1111111
error: Unable to change memory parameters
error: Requested operation is not valid: cgroup memory controller is not mounted
[root@dell-per730-61 guest_resource_control]# virsh blkiotune avocado-vt-vm1
error: Unable to get blkio parameters
error: Requested operation is not valid: blkio cgroup isn't mounted
[root@dell-per730-61 guest_resource_control]# virsh schedinfo avocado-vt-vm1
Scheduler : Unknown
error: Requested operation is not valid: cgroup CPU controller is not mounted
5. The cgroup dirs/files are actually still OK now
[root@dell-per730-61 guest_resource_control]# mount |grep cgroup
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel,nsdelegate,memory_recursiveprot)
[root@dell-per730-61 guest_resource_control]# cat /sys/fs/cgroup/machine.slice/machine-qemu\\x2d2\\x2davocado\\x2dvt\\x2dvm1.scope/libvirt/memory.max
227555553280
Expected result:
Libvirt should be able to operate vm's cgroup params after restarting virtqemud
Merged upstream as:
commit eac8de54a68725402ec4785888dddad656db609d
Author: Michal Prívozník <mprivozn>
AuthorDate: Tue Apr 19 17:22:22 2022 +0200
Commit: Michal Prívozník <mprivozn>
CommitDate: Wed Apr 20 09:52:56 2022 +0200
domain_cgroup: Fix a condition in virDomainCgroupConnectCgroup()
While parts of QEMU's CGroup code were moved under hypervisor
agnostic location (src/hypervisor/) a typo sneaked in. The
inspiration for virDomainCgroupConnectCgroup() comes from
qemuConnectCgroup(). The former is called upon reconnecting to a
running domain (after daemon restart). While the latter returned
early if the daemon was running unprivileged, the former returns
early if the daemon runs privileged. This is obviously wrong,
because root can set up CGroups.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2075765
Fixes: 788e2b58cb1896f1c25ebbdbde4bafddc5ed4dc9
Signed-off-by: Michal Privoznik <mprivozn>
Reviewed-by: Ján Tomko <jtomko>
v8.2.0-193-geac8de54a6
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 (Low: libvirt security, 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/RHSA-2022:8003