Re: [libvirt] [RFC] cgroups net_cls controller implementation
On Wed, Dec 08, 2010 at 01:08:36PM +0100, D. Herrendoerfer wrote:
I disagree. The concept of QoS is not pertinent to a single VM
description;
it is a constrainment of the Host. Libvirt vor example has no concept
of multiple VLAN distribution on a single machine and is dependent
on other tools to provide them.
True network QoS (802.1p) on the other hand is, in linux, bound to a
specific VLAN
interface, and having a single VM try to modify these settings will
affect all users of that VLAN.
Using cgroups in this context is a wonderful way of managing bandwidth
between groups of VMs, to make sure one cannot stave-out the other, but
again - this is a Host
Where the network settings need to be configured & applied can
vary depending on what network settings you're trying to manage.
There's been no description of what the design goals or required
network controls are, so it is impossible to say where they must
be configured in libvirt. Even if there are settings which are
not applicable for the VM configuration, there are other existing
areas of libvirt where they can be applied, and scope for adding
further APIs if no existing functionality is sufficient.
As an example, in VMWare they have a 'Virtual Switch' which then
has a number of 'Port Groups'. A VM NIC is associated with a
port group. Network QoS is configured against the port groups.
I could easily envisage such a model being something should have
in the libvirt API and build for QEMU, potentially backed up by
cgroups+tc. Cgroups could even be the wrong approach if we want
a VM to have multiple NICs, each with a different policy, since
cgroups control the VM as a whole, not individual VM NICs.
Starting from "We need to let admins set the 'tc' classid" is
wrong approach to dealing with this in libvirt. We need to
start from a consideration of what general capabilities &
concepts we want to represent & model in the XML/APIs. Then
consider how these concepts could be mapped to the platforms
or hypervisors libvirt wants to support. Directly exposing
'tc' as an implementation to the end administrator or app
developer is at odds with the libvirt goals.
Regards,
Daniel