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

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.