On Thu, Jul 21, 2011 at 04:15:46PM -0400, Jason Baron wrote: > On Thu, Jul 21, 2011 at 05:53:13PM +0200, Lennart Poettering wrote: > > On Thu, 21.07.11 16:36, Daniel P. Berrange (berrange@xxxxxxxxxx) wrote: > > > > > IIRC, you can already set cgroups configuration in the service's > > > systemd unit file, using something like: > > > > > > ControlGroup="cpu:/foo/bar mem:/wizz" > > > > > > though I can't find the manpage right now. > > > > Yes, this is supported in systemd (though without the ""). > > > > It's (tersely) documented in systemd.exec(5). > > > > My guess is that we'll cover about 90% or so of the usecases of cgroups > > if we make it easy to assign cgroup-based limits to VMs, to system > > services and to users, like we can do with libvirt and systemd. There's > > still a big chunk of the 10% who want more complex setups with more > > arbitrary groupings, but I have my doubts the folks doing that are the > > ones who need a UI for that. > > > > Ok, if systemd is planning to add all these knobs and buttons to cover all of > these cgroups use cases, then yes, we probably don't need another management > layer nor the UI. I guess we could worry about the more complex setups when > we better understand what they are, once systemd has added more cgroup > support. (I only recently understood that systemd was adding all this > cgroups support). In fact, at that point we probably don't need > libcgroup either. So the model seems to be that there are various components which control their own children. So at top level is systemd which controls users, services and libvirtd and will provide interfaces/options to be able to configure cgroups and resources for its children. Similarly libvirtd will provide interfaces/options to be able to configure cgroups/resources for its children (primary VMs and possibly containers at some point of time). And down the line if there is another significant component comes along it does the same thing. So every component defines its own sytax and interfaces to configure cgroups and there is no global control. If somebody wants to mangage the system remotely, it got to decide what it wants to control and then use the API offered by respective manager (systemd, libvirt, xyz)? Thanks Vivek -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
