On Thu, Jul 21, 2011 at 06:17:03PM +0200, Lennart Poettering wrote: > On Thu, 21.07.11 15:52, Daniel P. Berrange (berrange@xxxxxxxxxx) wrote: > > > > I think its a question of do we want to make users go to a bunch of > > > different front end tools, which don't communicate with each other to > > > configure the system? I think it makes sense to have libvirt or > > > virt-manager and systemd front-end be able to configure cgroups, but I > > > think it would be also nice if they could know when the step on each > > > other. I think it would also be nice if there was a way to help better > > > understand how the various system components are making use of cgroups > > > and interacting. I liked to see an integrated desktop approach - not one > > > where separate components aren't communicating with each other. > > > > It is already possible for different applications to use cgroups > > without stepping on each other, and without requiring every app > > to communicate with each other. > > > > As an example, when it starts libvirt will look at what cgroup > > it has been placed in, and create the VM cgroups below this point. > > So systemd can put libvirtd in an arbitrary location and set an > > overall limits for the virtualization service, and it will cap > > all VMs. No direct communication between systemd & libvirt is > > required. > > systemd (when run as the user) does exactly the same thing btw. It will > discover the group it is urnning in, and will create all its groups > beneath that. > > In fact, right now the cgroup hierarchy is not virtualized. To make sure > systemd works fine in a container we employ the very same logic here: if > the container manager started systemd in specific cgroup, then system > will do all its stuff below that, even if it is PID 1. How does the cgroup hierarchy look like in case of containers? I thought libvirtd will do all container management and libvirtd is one of the services started by systemd. Thanks Vivek -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
