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