On Tue, Sep 30, 2008 at 11:11:57AM -0700, Dan Smith wrote:
BS> For all practical purposes, it is not possible to mount all
BS> controllers at the same place. Consider a simple case of "ns", if
BS> the ns controller is mounted, you need root permissions to create
BS> new groups, which defeats the whole purpose of the cgroup
BS> filesystem and assigning permissions, so that an application can
BS> create groups on it own.
I don't think I'd go so far as saying that it "defeats the whole
purpose", but I understand your point.
After just a small amount of playing around, it seems like it might be
reasonable to just mount the controllers we care about somewhere just
for libvirt.
>> - What to do if memory and device controllers aren't present
>> - What to do if the root group is set for exclusive cpuset behavior
BS> These need to be fixed as well.
...that's why I pointed them out :)
I'm thinking that mounting the controllers we care about at daemon
startup (as mentioned above) would solve both of these issues as well.
Does anyone have an opinion on taking that approach?
The trouble is then libvirt would be dictating policy to the host
admin, because once you mount a particular controller, you can't
change the wayu its mounted. So if libvirt mounted each controller
separately, then the admin couldn't have a mount with multiple
controllers active, and vica-verca. The kernel cgroups interface
really sucks in this regard :-(
At the same time having the controllers mounted is mandatory for libvirt
to work and asking the admin to set things up manually also sucks. So
perhaps we'll need to mount them automatically, but make this behaviuour
configurable in some way, so admin can override it
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://ovirt.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|