We can close the discussion.  
The problem is in two active mounts cgroup v2. 
 

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

The problems seems to be in docker behaviour, when I try to bind /sys directory he creates additional mount 
cgroup /sys/fs/cgroup cgroup2 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 <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