FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 07-20-2011, 09:41 PM
Lennart Poettering
 
Default new cg-manager gui tool for managin cgroups

On Wed, 20.07.11 17:26, Vivek Goyal (vgoyal@redhat.com) wrote:

> > /sys/fs/cgroup/cpu+cpuacct is the joint mount point.
> >
> > /sys/fs/cgroup/cpu → /sys/fs/cgroup/cpu+cpuacct is a symlink.
> >
> > /sys/fs/cgroup/cpuacct → /sys/fs/cgroup/cpu+cpuacct is a symlink.
> >
> > That way to most applications it will be very easy to support this: they
> > can simply assume that the controller "foobar" is available under
> > /sys/fs/cgroup/foobar, and that's it.
>
> I guess this will be reasonable. Just that application need to handle
> the case that directory they are about to create might already be present
> there.

systemd always uses to equivalent of "mkdir -p" to create its groups. So
at least systemd should be safe here.

> So down the we should be able to co-mount memory and IO together with
> additional symlinks?

Yes, if you wish.

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-20-2011, 09:41 PM
Lennart Poettering
 
Default new cg-manager gui tool for managin cgroups

On Wed, 20.07.11 17:26, Vivek Goyal (vgoyal@redhat.com) wrote:

> > /sys/fs/cgroup/cpu+cpuacct is the joint mount point.
> >
> > /sys/fs/cgroup/cpu → /sys/fs/cgroup/cpu+cpuacct is a symlink.
> >
> > /sys/fs/cgroup/cpuacct → /sys/fs/cgroup/cpu+cpuacct is a symlink.
> >
> > That way to most applications it will be very easy to support this: they
> > can simply assume that the controller "foobar" is available under
> > /sys/fs/cgroup/foobar, and that's it.
>
> I guess this will be reasonable. Just that application need to handle
> the case that directory they are about to create might already be present
> there.

systemd always uses to equivalent of "mkdir -p" to create its groups. So
at least systemd should be safe here.

> So down the we should be able to co-mount memory and IO together with
> additional symlinks?

Yes, if you wish.

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-20-2011, 11:01 PM
Matthias Clasen
 
Default new cg-manager gui tool for managin cgroups

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.

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 ?


Matthias


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-21-2011, 10:03 AM
"Daniel P. Berrange"
 
Default new cg-manager gui tool for managin cgroups

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.
>
> 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 ?

I tend to agree. CGroups is really just a low level piece of infrastructure
to be used as a building block by higher level services like systemd or
libvirt. End users shouldn't know or care about cgroups directly, but
instead work off higher level concepts like

"Allow this virtual machine a max 30% of total CPU time"

This kind of policy is best expressed in the virtualization management
tool, or in the system services configuration tool, or another high
level application.

An end user tool for directly managing low level cgroups is not only an
inappropriate level of abstraction for users, but it will make it trivial
for users to totally screw up the use cgroups by things like systemd /
libvirt by moving groups/processes to unexpected places.

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
 
Old 07-21-2011, 02:20 PM
Jason Baron
 
Default new cg-manager gui tool for managin cgroups

Hi,

On Wed, Jul 20, 2011 at 10:28:32PM +0200, Lennart Poettering wrote:
> On Wed, 20.07.11 15:20, Jason Baron (jbaron@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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-21-2011, 02:36 PM
Jason Baron
 
Default new cg-manager gui tool for managin cgroups

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-21-2011, 02:52 PM
"Daniel P. Berrange"
 
Default new cg-manager gui tool for managin cgroups

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.

> > 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.

My point is that 'configure cgroups' is not really a task users would
need to. Going to virt-manager GUI, then systemd GUI, and so on is not
likely to be a problem in the real world usage, because the users tasks
do not require that they go through touch every single cgroup on the
system at once.

People who are using virtualization, will already be using virt-manager
to configure their VMs, so of course they expect to be able to control
the VMs's resource utilization from there, rather than any external tool

People who are configuring system services and want to control the
resources of a service on their system, would expect todo so in the
same tool where they are enabling their service, along with changing
firewall rules for that service all in the same place. They again would
have no little to go off to separate tools for cgroups or firewalling
while enabling services.

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
 
Old 07-21-2011, 03:08 PM
Vivek Goyal
 
Default new cg-manager gui tool for managin cgroups

On Thu, Jul 21, 2011 at 10:20:54AM -0400, Jason Baron wrote:

[..]
> > 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...

Agreed that cgrulesd reacts after the event and can be racy. It is a
best effort kind of situation. A more fool proof way is to launch the
task in right cgroup to begin with and that can be done with various
other mechianisms available.

- pam plugin to put users in right cgroup upon login
- cgexec command line tool to launch tasks in right cgroup
- Applications make use of libcgroup API to launch/fork tasks in
desired cgroup.

If none of the above is being used, then cgrulesengd works in the
background as best effort to enforce the rules and can easily be turned
off, if need be.

Thanks
Vivek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-21-2011, 03:28 PM
Vivek Goyal
 
Default new cg-manager gui tool for managin cgroups

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?

Secondly not all applications are going to do the cgroup management. So
we still need a common system wide tool which can do the monitoring
to figure out the problems and also be able to do atlest top level
resource planning before it allows the applications to do their own
planning with-in their top level group.

To allow that I think systemd should either provide native configuration
capability or build on top of existing libcgroups constructs like
cgconfig, cgrules.conf to decide how an admin has planned the resource
management and in what cgroups services have to be launched, IMHO.

>
> > > 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.
>
> My point is that 'configure cgroups' is not really a task users would
> need to. Going to virt-manager GUI, then systemd GUI, and so on is not
> likely to be a problem in the real world usage, because the users tasks
> do not require that they go through touch every single cgroup on the
> system at once.
>
> People who are using virtualization, will already be using virt-manager
> to configure their VMs, so of course they expect to be able to control
> the VMs's resource utilization from there, rather than any external tool
>
> People who are configuring system services and want to control the
> resources of a service on their system, would expect todo so in the
> same tool where they are enabling their service,.

Same thing can be extended to user configuraiton and resources also. One
big difference here as compared to libvirt is that there is no wrapper
tool to manage everything. There needs to be a tool to be able to provide
a way so that admin can set reousources for users/services and then
systemd should be able to read those policies and execute it.

Thanks
Vivek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-21-2011, 03:30 PM
"Daniel P. Berrange"
 
Default new cg-manager gui tool for managin cgroups

On Wed, Jul 20, 2011 at 03:20:30PM -0400, Jason Baron wrote:
> 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).

One thing I should mention is that it is an explicit design goal of
libvirt, that the concept of "cgroups" is not exposed to users of
the libvirt API. This is because the libvirt goal is to provide an
API / XML format that is independent of the specific implementation
that a hypervisor uses. Cgroups is an implementation detail of the
libvirt KVM & LXC drivers. The libvirt VMWare, Hyper-V, VirtualBox
drivers use completely different mechanisms to provide resource
controls. Thus the guest resource controls are expressed with a
common vocabularly, which is then internally translated to changes
in cgroups or some other mechanism as appropriate for the driver.

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
 

Thread Tools




All times are GMT. The time now is 01:12 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org