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...@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 <
>>mpriv...@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
>
