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