Re: new cg-manager gui tool for managin cgroups

["Daniel P. Berrange" <berrange@redhat.com>]

On Thu, Jul 21, 2011 at 11:28:45AM -0400, Vivek Goyal wrote:
> On Thu, Jul 21, 2011 at 03:52:03PM +0100, Daniel P. Berrange wrote:
> > On Thu, Jul 21, 2011 at 10:36:23AM -0400, Jason Baron wrote:
> > > Hi,
> > > 
> > > On Wed, Jul 20, 2011 at 07:01:30PM -0400, Matthias Clasen wrote:
> > > > On Wed, 2011-07-20 at 15:20 -0400, Jason Baron wrote:
> > > > > Hi,
> > > > > 
> > > > > I've been working on a new gui tool for managing and monitoring cgroups, called
> > > > > 'cg-manager'. I'm hoping to get people interested in contributing to this
> > > > > project, as well as to add to the conversation about how cgroups should
> > > > > be configured and incorporated into distros.
> > > > > 
> > > > 
> > > > As a high-level comment, I don't think 'cgroup management' is a very
> > > > compelling rationale for an end-user graphical tool.
> > > > 
> > > > For most people it will be much better to expose cgroup information in
> > > > the normal process monitor. For people who want to use the specific
> > > > cgroup functionality of systemd, it will be better to have that
> > > > functionality available in a new service management frontend.
> > > 
> > > I've thought that displaying at least the cgroup that a process is part of would
> > > be nice in the system monitor as well.
> > > 
> > > 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.
> > 
> > If applications similarly take care to honour the location in
> > which they were started, rather than just creating stuff directly
> > in the root cgroup, they too will interoperate nicely.
> > 
> > This is one of the nice aspects to the cgroups hierarchy, and
> > why having tools/daemons which try to arbitrarily re-arrange
> > cgroups systemwide are not very desirable IMHO.
> 
> This will work as long as somebody has done the top level setup and
> planning. For example, if somebody is running bunch of virtual machines
> and hosting some native applications and services also on the machine,
> then he might decide that all the virt machines can only use 8 out of
> 10 cpus and keep 2 cpus free for native services.
> 
> In that case an admin ought to be able to do this top level planning
> before handing out control of sub-hierarchies to respective applications.
> Does systemd allow that as of today?

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.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel