[libvirt] RFC: APIs for managing resource groups

[Daniel P. Berrange]

On Mon, Feb 25, 2013 at 09:48:16AM -0700, Eric Blake wrote:
> On 02/25/2013 05:41 AM, Daniel P. Berrange wrote:
> > Historically for the QEMU/LXC drivers we've simply put each virtual
> > instance in a dedicated cgroup, under the path
> > 
> 
> > We need to simplify our layout and also introduce some APIs for the
> > grouping of VMs. I won't go into specifics of a new cgroups layout
> > here, just focus on the question of defining a set of APIs that are
> > generic to any hypervisor, for the purpose of setting up VM resource
> > groups.
> 
> I'm very much in favor of VM resource groups.  In fact, this RFC has
> come up in the past, if it gives you any ideas of what you replied back
> then:
> https://www.redhat.com/archives/libvir-list/2011-March/msg01546.html
> 
> > 
> > I'm calling the resource cgroup a "partition", since this is all about
> > partitioning workloads.
> 
> Yes, that naming is workable, and a bit better than what I tried last time.
> 
> > 
> > I anticipate a new top level object and APIs for creating/defining it
> > in the usual manner:
> 
> <snip good API>
> 
> > 
> > There'd also likely be a new VM XML element
> > 
> >    <partition name="..partition name..."/>
> > 
> > which is what the Get/SetPartition methods would be touching.
> 
> Earlier, you pointed out that it might make sense to have multiple
> partitions per domain - that is, have one partitioning that controls
> only memory usage, and another partitioning that controls only cpu
> usage, then have a domain that belongs to two orthogonal partitions to
> cap both memory and cpu.  Your proposal today doesn't seem to deal with
> the idea of having multiple partitions per domain.  Also, while you
> proposed having a domain belong to a partition, you didn't cover whether
> it makes sense to have a hierarchy of partitions, where one partition
> can provide further constraints on top of a parent partition.

While cgroups currently allows you to setup different hiearchies
for memory, cpu, blockio, etc controls, these days it is agreed
that this is an anti-feature causing no end of trouble for all
involved. In the future I expect the kernel will enforce that we
use the same hierarchy for all cgroup controllers. In other words,
we only want a single partition for all resources.

I do anticipate that we'll be able to create partition hierarchies,
though it may be discouraged since it has performance implications
for the kernel that are currently somewhat unacceptable.


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