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

[libvirt] RFC: have libvirt track cgroup objects



Currently, all qemu domains are created in their own cgroup, but that
cgroup is a direct child of libvirt.  So cgroup tunings are all-or-one;
there is no way to group multiple VMs to share a particular resource
without infringing on other VMs.

Just as we can currently track interface, nwfilter, and storage pool
objects as independent xml entities in parallel with domains, it would
be nice to expose a new object, virCgroup.  All virCgroup and virDomain
objects would have an optional parent virCgroup object, and anything
without such a parent defaults to the global libvirt cgroup as the
parent.  Recent tuning parameters like <memtune>, <blkiotune> that apply
to domains would also apply to a virCgroup XML representation.

That way, you can create a hierarchy of cgroups, such as:

libvirt
|+cgroup1
| |+vm1
| \+vm2
\+vm3

where a <memtune> of cgroup1 is memory that is shared between vm1 and
vm2 (possibly with overcommit, if it is anticipated that both vms will
not simultaneously be using the max memory), which maps nicely to the
fact that cgroups are already hierarchical to the kernel.

I'm not quite sure how this would affect migration, but it would
probably be similar to how <interface> or <nwfilter> setups affect
migration (that is, if a domain refers to a particular host <interface>,
then that interface object better be present with similar
characteristics on both source and destination of the migration).

I'm throwing this out for general thoughts, based on an IRC conversation
(and not necessarily because I plan on implementing it any time soon).

-- 
Eric Blake   eblake redhat com    +1-801-349-2682
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]