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(a)redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org