Daniel P. Berrange wrote:
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
As I mentioned in my previous email, one could use the cgconfigparser to
automatically mount the controllers at initscripts time and then also use a
policy to automatically classify tasks.
--
Balbir