Re: [libvirt PATCH v3] cgroup/LXC: Do not condition availability of v2 by controllers
On Tue, Oct 25, 2022 at 02:49:35PM +0200, Pavel Hrdina <phrdina(a)redhat.com> wrote:
Exactly, there is the same ordering issue, if cgroup v2 backend is
enabled it is the only one used for cpuacct and devices within libvirt
code.
Aha, I see what's the issue with the approach now.
> BTW do you have any pointers (a commit) when the hybrid mode
could have
> become broken for libvirt/lxc? (I estimate from the (lack of) user
> reports that it must have worked at the time of libvirt 4.0.)
Only this specific hybrid mode of systemd which is cgroup v1 for
everything and unified for process tracking.
I mean we've had the hybrid mode since Leap 15.0 and apparently there
were no (reported) issues of this kind (libvirt/lxc) until Leap 15.3
(which roughly translates to libvirt >= 7.1.0).
So it must have worked somehow and something changed meanwhile (move to
use the systemd API partially to manage cgroups?).
As I've already mentioned in previous reply, to fix the process
tracking
we should ideally use
org.freedesktop.systemd1.Manager.AttachProcessesToUnit
dbus call to add the process into the cgroup
This is a rather low-level (and as you mentioned internal purposes) API.
It should primarily use
org.freedesktop.machine1.Manager.CreateMachine()
or
org.freedesktop.systemd1.Manager.StartTransientUnit()
if machined is unwanted.
These calls would ensure that processes are migrated in all hierarchies
there are (i.e. v2 and all v1s in hybrid mode) by systemd.
I thought that recent libvirt (8.7.0 manifests the bug on hybrid too)
would only use the systemd API.
Do I get it correctly that it only applies to the libvirt "core" and
then libvirt/lxc needs to place some more processes together with the
leader process?
(Which currently works only with full v1 or full v2 mode by direct
cgroupfs manipulation.)
Thanks,
Michal
Attachments:
- signature.asc (application/pgp-signature — 228 bytes)