[libvirt] [PATCH 0 of 2] [RFC] Add cgroup manipulation and LXC driver support

Balbir Singh balbir at linux.vnet.ibm.com
Wed Oct 1 03:11:19 UTC 2008


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




More information about the libvir-list mailing list