Re: [libvirt] [RFC] cgroup settings and systemd daemon-reload conflict

On Tue, Jan 30, 2018 at 10:34:14AM +0300, Nikolay Shirokovskiy wrote: > Hi, all. > > It turns out that systemd daemon-reload reset settings that are managable > thru 'systemctl set-property' interface. > >> virsh schedinfo tst3 | grep global_quota > global_quota : -1 >> virsh schedinfo tst3 --set global_quota=50000 | grep global_quota > global_quota : 50000 >> systemctl daemon-reload >> virsh schedinfo tst3 | grep global_quota > global_quota : -1 > > This behaviour does not limited to cpu controller, same for blkio for example. > I checked different versions of systemd (219 - Feb 15, and quite recent 236 - Dec 17) > to make sure it is not kind of bug of old version. So systemd does not play well > with direct writes to cgroup parameters that managable thru systemd. Looks like > libvirtd needs to use systemd's dbus interface to change all such parameters. > > I only wonder how this can be unnoticed for such long time (creating cgroup for domain > thru systemd - Jul 2013) as daemon-reload is called upon libvirtd package update. May > be I miss something? I guess the reasons its unnoticed is that using global_* constants is relatively uncommon. Traditionally we had the per-vCPU tunables for quota and the global stuff was a newer addition. Also for a long time I didn't think systemd even supported the quota+period settings in unit files at all. It is incredibly frustrating that systemd would just reset th cgroups settings on daemon reload - something which ostensibly is supposed to be used to reload config files on disk. Since this behaviour has existed a long time though, I guess we have little choice but to cope with it now. We kind of need to use the systemd dbus API more in order to support cgroups v2 properly too. None of this will be pleasant changes to make though as this area of code is fairly complex. Also I don't think there's any nice way to introspect what properties a given version of systemd supports, which makes it hard to know when to set direct vs when to set via dbus. I think we would have to create the machine via dbus, then read back the auto-generated unit file for the machine to see what properties are listed as existing, then we can see which we now need to set via dbus.