[libvirt] [RFC] cgroups net_cls controller implementation

[D. Herrendoerfer]

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 feature.

Apart from the above, I don't see great potential for regressions by  
simply
introducing a sensible default behavior, it is still possible to  
simply leave
zero in the classid file, and all is back to normal.

D.Herrendoerfer

On Dec 8, 2010, at 11:43 AM, Daniel P. Berrange wrote:

> On Thu, Dec 02, 2010 at 02:47:15PM +0100, D. Herrendoerfer wrote:
>> This a basic implemantation to support the net_cls feature of
>> cgroups. It adds the setting of a net_cls.classid value to the
>> existing cgroups setup in the qemu driver.
>> The classid is specified in the qemu.conf file.
>>
>> This enables the use of the tc utility to manage traffic from/to
>> vitual machines
>> based on the setting combination of classid and network interface.
>
> I don't think this patch is a good approach. The goal of libvirt is
> that you can configure & control guests using terminology & APIs
> that are platform & hypervisor independent. This precludes exposing
> classid as a direct concept. Requiring the half the configuration
> job to be performed via the tc command line utility is also not a
> viable solution for apps that are communicating with libvirt over
> a remote connection.
>
> If we were to support this patch in libvirt, then it would make it
> harder for us to incorporate a alternative solution for networking
> traffic controls without causing behavioural regressions for anyone
> who had started depending on this patch.
>
>
> Regards,
> Daniel