Re: new cg-manager gui tool for managin cgroups
by Jason Baron
On Thu, Jul 21, 2011 at 05:53:13PM +0200, Lennart Poettering wrote:
> On Thu, 21.07.11 16:36, Daniel P. Berrange (berrange(a)redhat.com) 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.
thanks,
-Jason
12 years, 2 months
Re: new cg-manager gui tool for managin cgroups
by Jason Baron
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.
>
> The only role I could see for this kind of dedicated cgroup UI would be
> as a cgroup debugging aid, but is that really worth the effort,
> considering most cgroup developers probably prefer to use cmdline tools
> for the that purpose ?
>
>
The reason I started looking at this was b/c there were requests to be
able to use a GUI to configure cgroups. Correct me if I'm wrong, but the answer
is go to the virt-manager gui, then the systemd front end, and then hand edit
cgrules.conf for custom rules. And then hope you don't start services in
the wrong order.
thanks,
-Jason
12 years, 2 months
Re: new cg-manager gui tool for managin cgroups
by Jason Baron
Hi,
On Wed, Jul 20, 2011 at 10:28:32PM +0200, Lennart Poettering wrote:
> On Wed, 20.07.11 15:20, Jason Baron (jbaron(a)redhat.com) wrote:
>
> Heya,
>
> > The memory and cpu share controllers are currently supported (I simply haven't
> > gotten to supporting other controllers yet). One can add/delete cgroups, change
> > configuration parameters, and see which processes are currently associated
> > with each cgroup. There is also a 'usage' view, which displays graphically the
> > real-time usage statistics. The cgroup configuration can then be saved
> > into /etc/cgconfig.conf using the 'save' menubar button.
>
> How does it write that file? Does the UI run as root? That's not really
> desirable. It's not secure and it is cumbersome to mix applications
> running as differnt users on the same session and one the same X
> screen (since they cannot communicate with dbus, and so on).
Right, as Dan Walsh, mentioned I need to separate this into two parts -
the front end UI and a backend communicating via DBUS. This is had been
a todo item.
>
> > Right now, the gui assumes that the various hierarchies are mounted separately,
> > but that the cpu and cpuacct are co-mounted. Its my understanding that this
> > is consistent with how systemd is doing things. So that's great.
>
> In F15 we mount all controllers enabled in the kernel separately. In F16
> we'll optionally mount some of them together, and we'll probably ship a
> default of mounting cpu and cpuacct together if they are both enabled.
>
> > Currently, the gui saves its state using cgconfig.conf, and cgrules.conf. It
> > will display what libvirtd and systemd are doing, but will not save the state
> > for any of the cgroups that are created by libvirt or systemd. So, it
> > basically ignores these directories as far as persistent configuration. Thus,
> > it should not conflict with what systemd or libvirtd are doing.
>
> Quite frankly, I think cgrulesd is a really bad idea, since it applies
> control group limits after a process is already running. This is
> necessarily racy (and adds quite a burden too, since you ask for
> notifications on each exec()). I'd claim that cgrulesd is broken by
> design and cannot be fixed.
I'm not going to claim that cgrulesd is perfect, but in the case where
you have untrusted users, you can start their login session in a
cgroup, and they can't break out of it. I agree it can be racy in the
case where you want to then further limit that user at run-time (fork
vs. re-assignment race). Another point, is that the current situation
can be no worse then the current unconstrained (no cgroup) case,
especially when you take into account the fact that system services or
'trusted services' are going to be properly assigned. Perhaps, the
authors of cgrulesd can further comment on this issue...
>
> > Thus, various privaleged consumers could make 'configuration requests' to a
> > common API, basically asking what's my configuration data. If there is already
> > data the consumer can proceed assigning tasks to those cgroups. Otherwise, it
> > can create a new request, which may or may not be allowed based upon the
> > available resources on the system. And each consumer can handle what it wants
> > to do in this case, which could potentially include tweaking the global
> > configuration.
>
> systemd is the first process of the OS after the initrd finished. At
> that time no other process is running, and that means it is not
> practical to have systemd talk to any other daemon to get the most basic
> of its functionality working.
>
> systemd is and will always have to maintain its own hierarchy
> independently of everybody else.
My suggestion here was that systemd starts its own hierarchy in some
default way, and then once configuration info is available it can move
processes around as required (in most cases there would probably be no
movement since we don't expect most users to override the defaults).
Doesn't it have to do this now, if the user requests some sort of
customized cgroup configuration?
>
> In fact I think running som arbitration daemon which clients talk to to
> get a group created is a bad idea anyway: this makes things needless
> complex and fragile. If the main reason to do such a thing is to get
> events when the cgroup configuration changes then I'd much rather see
> changes made to the kernel so that we can get notifications when groups
> are created or removed. That could be done via netlink. Another option
> would be to hook cgroupfs up with fanotify.
>
The main point of the arbitration daemon is to help users configure
their system in a consistent way. For example, if systemd wants to
use cpuset to assign certain service to say cpu 1, and libvirtd also
wants to assign a virtual machine to cpu 1, it would be nice to allow
the user to know there might be a conflict and either adjust his
settings or continue anyway. I think it would also be nice to see the
overall system configuration and performance in a single place - hence
this tool. I'm interested in an integrated administration experience. If
I can only go to #n separate tools to configure things, to understand
how they interact, I think we're adding complexity on the administrator.
>
> One of the nicer things of cgroups is that an "mkdir" is sufficient to
> create a group and an "echo $PID > $GROUP/tasks" to add a process to
> it. If you add complex systems on top of that which you need to talk to
> instead of trivial "mkdirs" and "open()+write()" you make cgroups much
> less attractive.
>
The arbitration daemon tells you abut cgroup assignments, it doesn't
necessarily carry out the assignments. So I'm not suggesting that we
take away any of the above trivial operations.
thanks,
-Jason
12 years, 2 months
new cg-manager gui tool for managin cgroups
by Jason Baron
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.
* Intro
I've created a Fedora hosted page for the project, including a screen shot at:
https://fedorahosted.org/cg-manager/
To build and run, it's:
$ git clone git://git.fedorahosted.org/cg-manager.git
$ make
$ sudo ./cg-gui
I've also setup a mailing list to discuss the gui at:
https://fedorahosted.org/mailman/listinfo/cg-manager-developers
Currently, I assume the root user, but I hope to relax that assumption in
future versions. The program is still quite rough, but its been fairly stable
for me. Its a GTK 2.0 based application, written in C (to interface with
libcgroup as much as possible).
* Brief summary of current functionality:
There are two top-level panes (which can be switched b/w using toggle buttons).
The first one centers around cgroup controllers, and the second one is about
configuring cgroup rules.
The memory and cpu share controllers are currently supported (I simply haven't
gotten to supporting other controllers yet). One can add/delete cgroups, change
configuration parameters, and see which processes are currently associated
with each cgroup. There is also a 'usage' view, which displays graphically the
real-time usage statistics. The cgroup configuration can then be saved
into /etc/cgconfig.conf using the 'save' menubar button.
The rules view allows for the creation of rules, such as this process for this
user goes into this cgroup. One can view rules by user and by process name. One
can also save the rules configuration into /etc/cgrules.conf.
I've also introduced the concept of a 'logical' cgroup, which is incorporated
into the cgroup pane and the rules pane. Basically, it allows you to group at
most one cgroup from each hierarchy into a logical group. And then you can
create rules that assign processes to that logical group.
* Future direction:
I've been working Mairin Duffy on what the UI look and feel should eventually
look like...Right now, I have a lot of the elements from Mairin's mockups in
my UI, but its certainly not quite as polished. Mock-ups can be found at:
http://mairin.wordpress.com/2011/05/13/ideas-for-a-cgroups-ui/
* Integration with Fedora/systemd:
Right now, the gui assumes that the various hierarchies are mounted separately,
but that the cpu and cpuacct are co-mounted. Its my understanding that this
is consistent with how systemd is doing things. So that's great.
Currently, the gui saves its state using cgconfig.conf, and cgrules.conf. It
will display what libvirtd and systemd are doing, but will not save the state
for any of the cgroups that are created by libvirt or systemd. So, it
basically ignores these directories as far as persistent configuration. Thus,
it should not conflict with what systemd or libvirtd are doing.
However, I think we need to discuss how we envision cgroup configuration
working longer term. The current consumers out of the box, that I'm aware of
are libvirt and systemd. Currently, these consumers manage cgroups as they see
fit. However, since they are managing shared resources, I think there probably
is an argument to be made that its useful, to have some sort of global view
of things, to understand how resources are being allocated, and thus a global
way of configuring cgroups (as opposed to each new consumer doing its own
thing).
Thus, various privaleged consumers could make 'configuration requests' to a
common API, basically asking what's my configuration data. If there is already
data the consumer can proceed assigning tasks to those cgroups. Otherwise, it
can create a new request, which may or may not be allowed based upon the
available resources on the system. And each consumer can handle what it wants
to do in this case, which could potentially include tweaking the global
configuration.
So for example, in the case of systemd, it continues to have the default
configuration that it currently has, but if the user has gone in and tweaked
the global configuration, that configuration may be re-assigned once we're far
enough along in the boot process to read what that configuration is.
Thanks,
-Jason
12 years, 2 months