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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list