root@milan15:/# cat /proc/mounts | grep cgro
cgroup /sys/fs/cgroup cgroup2 rw,nosuid,nodev,noexec,relatime 0 0
cgroup2 /sys/fs/cgroup cgroup2 rw,nosuid,nodev,noexec,relatime 0 0
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
Четверг, 5 сентября 2024, 14:15 +03:00 от Dmitrii Abramov <a@mameluk.ru>:
Hello, Michal.We tested the same scheme with libvirtd version > 10.0We 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@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