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.
I think it would be better to query for mount points as to where the controller
is currently mounted and use that information.
>> - 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?
We have a configuration parser in libcgroup, called cgconfigparser, that can
parse a configuration file and automatically setup groups and mount points. We
also have a PAM plugin (pam_cgroup) and other methods to classify the task to
the correct group and an API to query where the task is currently classified.
The administrator can setup simple rules to move tasks to the correct group
(depending on what sort of resources need to be provided to the task).
--
Balbir