new cg-manager gui tool for managin cgroups

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/21/2011 12:36 PM, Lennart Poettering wrote:
> On Thu, 21.07.11 11:28, Vivek Goyal (vgoyal at redhat.com) wrote:
> 
>>> 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?
> 
> Right now, systemd only offers you to place services in the cgroups
> of your choice, it will not configure any settings on those cgroups.
> (This is very likely to change soon though as there is a patch
> pending that makes a number of popular controls available as native
> config options in systemd.)
> 
> For the controllers like "cpuset" or the RT part of "cpu" where you 
> assign resources from a limited pool we currently have no solution
> at all to deal with conflicts. Neither in libcgroup and friends, not
> in systemd, not in libvirt.
> 
> However, I do think that figuring out the conflicts here is something
> to fix at the UI level -- and systemd itself (or libvirt) should not
> have to deal with this at all. The UIs should figure that out
> between themselves. I think it should be possible to come up with
> really simple schemes to deal with this however. For example, have
> every UI drop in some dir /var/lib or so a file encoding which
> resources have been taken and should not available in the other UIs
> anymore, maybe with a descriptive stirng, so that those UIs can show
> who took it away.
> 
> However, I believe that adding something like that should be the
> last step to care for in a UI. So far systemd doesn't have any
> comprehensive UI. How to deal with conflicts between resource
> assignments is not a central problem that would justify moving all
> the consumers of cgroups on some additional middleware.
> 
>> 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.
> 
> For the systemd case I'd assume that a UI which wants to enable the 
> admin to control cgroup limits would just place a unit file for the 
> respective service in /etc/systemd/system, use ".include" to pull in
> the original unit file, and set the setting it wants to set.
> 
> Lennart
> 


One goal I have for sandbox would be to allow it to plug into the
cgroups hiearchy also.  So a user could say I want to run all my
sandboxes in such a way that they can only use X% of my CPU and Y% of
memory.  Allowing a user to always be able to kill the sandbox.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4ohGwACgkQrlYvE4MpobONCQCfSX64iqXWKCokiuG8/ehxfl3L
pTsAn3iRyJJNADkeY9O/osOrqcdPRL96
=aq0Q
-----END PGP SIGNATURE-----