Re: [libvirt] [PATCH 1/5] conf: allow different resource registration modes

On Tue, Jan 09, 2018 at 01:43:39PM +0100, Martin Kletzander wrote: > I'm so sorry for not getting to this earlier. I though I'll get to this over > the holidays, but they were very busy with no free time for me. > > On Wed, Dec 20, 2017 at 04:47:46PM +0000, Daniel P. Berrange wrote: > > Currently the QEMU driver has three ways of setting up cgroups. It either > > skips them entirely (if non-root), or uses systemd-machined, or uses > > cgroups directly. > > > > So what we are trying to fix here is that all of the variations don't create the > same structure. So it needs to be clear for the mgmt app to guess^Wknow > correctly where the domain is in the cgroup hierarchy. > > > It is further possible to register directly with systemd and bypass > > machined. We don't support this by systemd-nsspawn does and we ought > > to. > > But what's the benefit of that? Systemd recommends that you only register with machined, if you are running a full OS install in the machine. IOW, if you are using LXC / QEMU for sandboxing individual applications, instead of full OS, then you should not register with machined. So this is something libvirt sandbox ought to be able to request, for exmaple. > > > This change adds ability to configure the mechanism for registering > > resources between all these options explicitly. via > > > > <resource register="none|direct|machined|systemd"/> > > > > I understand what you are trying to fix, but I don't quite follow why we should > expose that. Can't we guess some of them easily? Or are you making this part > of the PoC, but then removing it later? No, I intend this bit to be fully supported long term. * none - use this to just inherit current placement of the caller. This is akin to turning off all use of cgroups in qemu.conf if launching from libvirtd, causing currently placement of libvirtd in cgroups to be inherited by VMs. This is what we'll also need with the shim for KubeVirt's needs * machined - register with machined - this is what we do today, if we detect that machined is available * direct - create cgroups directly - this is what we do if machined is not installed, or we have no dbus connection available. * systemd - register with systemd only, not with machined - see above rationale It is unlikely that apps would use 'direct' if running on a systemd based host. Likewise using machined/systemd on a non-systemd host is not possible. But that still leaves a choice of 2/3 options that are viable and cannot be automatically determined, and are reasonable to vary per-VM.