Re: new cg-manager gui tool for managin cgroups

[Lennart Poettering <mzerqung@0pointer.de>]

On Thu, 21.07.11 15:52, Daniel P. Berrange (berrange@redhat.com) 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.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel