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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list