[Bug 1183247] starting lxc container failes with GDBus.Error:org.freedesktop.machine1.NoMachineForPID: PID 4370 does not belong to any known machine
https://bugzilla.suse.com/show_bug.cgi?id=1183247 https://bugzilla.suse.com/show_bug.cgi?id=1183247#c15 James Fehlig <jfehlig@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #15 from James Fehlig <jfehlig@suse.com> --- (In reply to Michal Koutn� from comment #14)
What I find interesting that libvirtd seems to be probing _its_ libvirtd.service cgroup but it should really be interested in the container .scope cgroup under machine.slice (to see what's was delegated to the container) or the root cgroup (to see what is available on the host (for further delegation)).
Ah, good point. Likely an upstream improvement that could be made to the lxc driver. I'm not familiar with the driver and don't have the motivation to learn it, particularly since there is no support on the enterprise side.
The reason might be that other distros enable DefaultMemoryAccounting=yes and in such a case even libvirtd.service would have memory controller enabled in itself which is likely enough to trick lxc.
Thanks for the hint! /usr/lib/systemd/system.conf.d/__20-defaults-SUSE.conf has # Memory accounting incurs performance penalties. Let's keep it # disabled by default since the actual use case for enabling it is not # clear (jsc#PM-2229). DefaultMemoryAccounting=no A local override of the setting allows me to start lxc domains with cgroups V2. But that's a separate doc bug IMO. The bug reported here against hybrid/V1 cgroups is now fixed and submitted to Factory. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@suse.com