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