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