Re: [libvirt] [PATCH 0 of 2] [RFC] Add cgroup manipulation and LXC driver support
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