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