[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
	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

-------------- 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