Dan Smith wrote:
DB> The trouble is then libvirt would be dictating policy to the host DB> admin, because once you mount a particular controller, you can't DB> change the wayu its mounted. So if libvirt mounted each controller DB> separately, then the admin couldn't have a mount with multiple DB> controllers active, and vica-verca.
Oh, I see. I had left that out of my quick test. I had assumed that it would behave as you would expect.
DB> The kernel cgroups interface really sucks in this regard :-(
I was going to go with "surprisingly unideal" ...but yeah.
The interface, when it was designed was designed to allow flexibility of separating controllers. One might need different resources for tasks, they should not be forced to share the same set of controllers. Cgroups has the notion of busy (as in no new groups are created underneath), so it needs to be not busy for changing the way it is mounted. This has made our life while working on libcgroup very hard. The other thing that gets hard is controller interplay and rules. CPUsets for example has rules about not allowing tasks to attach without adding cpus and mems and other rules about exclusivity and having certain files just in the root.
DB> At the same time having the controllers mounted is mandatory for DB> libvirt to work and asking the admin to set things up manually DB> also sucks. So perhaps we'll need to mount them automatically, but DB> make this behaviuour configurable in some way, so admin can DB> override it
Perhaps we can:
- Have a list of controllers we use (memory and devices so far) - Create each group in all mounts required to satisfy our necessary controllers - Select the appropriate mount when setting a cont.key value
I am not sure how libvirt provides thread safety, but I did not see any explicit coding for that?
It will muck things up a bit, but I think it might be doable.
I would really recommend looking at libcgroup in the long run and using it. -- Balbir