[libvirt] [PATCH 1/5] conf: allow different resource registration modes
Daniel P. Berrange
berrange at redhat.com
Thu Jan 11 12:17:11 UTC 2018
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
> > > 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
> * 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
> 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
|: 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 :|
More information about the libvir-list