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 :|