[libvirt] RFC: have libvirt track cgroup objects

[Daniel P. Berrange]

On Thu, Mar 31, 2011 at 11:09:33AM -0600, Eric Blake wrote:
> Currently, all qemu domains are created in their own cgroup, but that
> cgroup is a direct child of libvirt.  So cgroup tunings are all-or-one;
> there is no way to group multiple VMs to share a particular resource
> without infringing on other VMs.
> 
> Just as we can currently track interface, nwfilter, and storage pool
> objects as independent xml entities in parallel with domains, it would
> be nice to expose a new object, virCgroup.  All virCgroup and virDomain
> objects would have an optional parent virCgroup object, and anything
> without such a parent defaults to the global libvirt cgroup as the
> parent.  Recent tuning parameters like <memtune>, <blkiotune> that apply
> to domains would also apply to a virCgroup XML representation.
> 
> That way, you can create a hierarchy of cgroups, such as:
> 
> libvirt
> |+cgroup1
> | |+vm1
> | \+vm2
> \+vm3
> 
> where a <memtune> of cgroup1 is memory that is shared between vm1 and
> vm2 (possibly with overcommit, if it is anticipated that both vms will
> not simultaneously be using the max memory), which maps nicely to the
> fact that cgroups are already hierarchical to the kernel.
> 
> I'm not quite sure how this would affect migration, but it would
> probably be similar to how <interface> or <nwfilter> setups affect
> migration (that is, if a domain refers to a particular host <interface>,
> then that interface object better be present with similar
> characteristics on both source and destination of the migration).
> 
> I'm throwing this out for general thoughts, based on an IRC conversation
> (and not necessarily because I plan on implementing it any time soon).

CGroups are a Linux specific implementation detail that we
don't really want to expose in the public API. Your proposal,
however, would make sense if we were to just expose an object
'virDomainGroupPtr' as a way to group domains. The idea being
that virDomainGroupPtr would map to CGroups with QEMU/LXC, or
another hypervisor's own grouping concept.

Aside from performance tunables, domain grouping could also be
useful in the context of shared disks. Currently a disk marked
'shared' is potentially accessible across every single guest
on a host. If we had domain groups, we could restrict the
disk access to a subset of guests.

The fun part is that you might want different groups for perf
tunables vs disk sharing.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|