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

[Balbir Singh]

Daniel P. Berrange wrote:
> On Wed, Oct 01, 2008 at 08:41:19AM +0530, Balbir Singh wrote:
>> Dan Smith wrote:
>>> 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?
> 
> The thread safety model for libvirt has two levels
> 
>  - A single virConnectPtr object must only be used by one thread. 
>    If you have multiple threads, you must provide each with its
>    own conenct object
> 
>  - Within a stateless driver (Xen, OpenVZ, Test), there is no shared
>    state between virConnectPtr objects, so there are no thread issues
>    in this respect
> 
>  - With a stateful driver, the libvirtd daemon ensures that only a
>    single thread is active at once, so against there are no thread
>    issues there either.
> 
> Now, in a short while I will be making the daemon fully-multithreaded. When
> this happens, the stateful drivers will be required to maintain mutexes for
> locking. The locking model wil have 2 levels, one lock over the driver as
> a whole. This is held only while acquiring a lock against the object being
> modified (eg the virtual domain object).
> 
> Each virtual domain, lives in one cgroup, so there is a single virCGroup
> object associated with each domain. the virCGroup object state is seflf
> contained, so independant virCGroup objects can be accessed concurrently
> from multiple threads, without any threads safety issues.

Thanks, that was quite insightful.

-- 
	Balbir