[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] RFC: APIs for managing resource groups



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

Attachment: signature.asc
Description: OpenPGP digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]