[libvirt PATCH v3] cgroup/LXC: Do not condition availability of v2 by controllers

Michal Koutný mkoutny at suse.com
Tue Oct 25 16:12:09 UTC 2022

On Tue, Oct 25, 2022 at 02:49:35PM +0200, Pavel Hrdina <phrdina at 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
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.)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20221025/64eeb90a/attachment.sig>

More information about the libvir-list mailing list