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

[Daniel P. Berrange]

On Thu, Jan 11, 2018 at 12:14:21PM +0000, Daniel P. Berrange wrote:
> 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.

Oh, I also meant to say that I would expect us to update this in the live
XML, if the user/app left it unspecified. This would allow the app to
determine whether libvirt has actually activated cgroup support or not,
and thus whether resource mgmt apis/config will work

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|