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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list