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