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.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org