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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
