[libvirt] RFC: have libvirt track cgroup objects

[Eric Blake]

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).

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110331/f0871f83/attachment-0001.sig>