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.
For now I am OK with that, but I would rather see that as a part of
qemu.conf
(or libvirtd.conf), not really in the XML. OK for the PoC, though.
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 :|