We can close the discussion.
The problem is in two active mounts cgroup v2.
root@milan15:/# cat /proc/mounts | grep cgro
cgro up /sys/fs/ cgro up cgro up2 rw,nosuid,nodev,noexec,relatime 0 0
cgro up2 /sys/fs/ cgro up cgro up2 rw,nosuid,nodev,noexec,relatime 0 0
The problems seems to be in docker behaviour, when I try to bind /sys directory he creates
additional mount
cgro up /sys/fs/ cgro up cgro up2 rw,nosuid,nodev,noexec,relatime 0 0
Or maybe the problem is in distributive of OS.
I’m not able to umout cgroup.
But If I mount cgroup2(working variant) then I’m not able to get information about cgroup
controllers.
root@milan15:/# umount cgroup
umount: cgroup: umount failed: Invalid argument.
root@milan15:/# umount cgroup2
root@milan15:/#
root@milan15:/# cat /sys/fs/cgroup/cgroup.controllers
cat: /sys/fs/cgroup/cgroup.controllers: No such file or directory
If understand right the code of function virCgroupDetectMounts
it takes the first matched line from /proc/mount, that’s it takes non-working mount(Just
Quick Look to the code)
I solved the problem deleted bind sysfs and added option cgroup=host.
In this case I have only one cgroup mounts and every libvirtd process can freely access to
cgroup fs.
Thank you for your help!
--
Best Regards,
Dmitrii Abramov
Четверг, 5 сентября 2024, 14:15 +03:00 от Dmitrii Abramov
<a(a)mameluk.ru>:
Hello, Michal.
We tested the same scheme with libvirtd version > 10.0
We had the same problems.
As explained Peter the process of choosing the path the problem seems to be with cgroup
v2.
--
Best Regards,
Dmitrii Abramov
>Четверг, 5 сентября 2024, 12:42 +03:00 от Michal Prívozník < mprivozn(a)redhat.com
>:
>
>On 9/5/24 10:10, Peter Krempa wrote:
>> On Wed, Sep 04, 2024 at 23:47:12 +0300, Dmitrii Abramov wrote:
>>>
>>>
>>> Hello, Libvirt community.
>>> We have one strange issue with libivrtd.
>
>>> We’ve been using Libvirtd in docker for several years. This year we switched
to the new generation of processes AMD 7663 and we started to use the new version(for
us) of libviirtd 8.0.0. Before this we used Libvirt 6.0
>>>
>
>>>
>>> System: Ubuntu 22.04
>>> core: Linux milan15 6.5.0-35-generic #35~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC
Tue May 7 09:00:52 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
>>>
>>>
>>> Can anyone help us to solve this problem
>>
>> Please note that upstream libvirt doesn't really provide support for
>> containered deployments as nobody really tests them upstream. Said that
>> there are users who do use libvirt this way but it has many intricacies
>> that can be easily messed up.
>>
>
>I'll go one step further and ask you to test with a more recent version
>of libvirt. Since libvirt-8.0.0 there were numerous fixes to CGroup
>handling code and it's likely this bug has been fixed.
>
>Michal