On Fri, Jan 24, 2014 at 02:18:27PM +0200, Laine Stump wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1057321 pointed out that > we weren't honoring the <bandwidth> element in libvirt networks using > <forward mode='bridge'/>. In fact, these networks are just a method of > giving a libvirt network name to an existing Linux host bridge on the > system, and even if it were technically possible for us to set > network-wide bandwidth limits for all the taps on a bridge, it's > probably not a polite thing to do since libvirt is just using a bridge > that was created by someone else for other purposes. Since QoS is not something that libvirt applies based on an explicit request by the admin, I am not sure that this is a convincing argument: if the admin does not want something to be done, they would not request libvirt to do it. > So the proper > thing is to just log an error when someone tries to put a <bandwidth> > element in that type of network. Would you explain why the QoS cannot be applied to the bridge interface itself? The fact that it would limit in-host traffic too? Would you update the docs, to expose the non-support of QoS on these networks? > > While looking through the network XML documentation and comparing it > to the networkValidate function, I noticed that we also ignore the > presence of a mac address in the config, even though we do nothing > with it in this case either. > > This patch updates networkValidate() (which is called any time a > persistent network is defined, or a transient network created) to log > an error and fail if it finds either a <bandwidth> or <mac> element > and the network forward mode is anything except 'route'. 'nat', or > nothing. (Yes, neither of those elements is acceptable for any macvtap > mode, nor for a hostdev network). > > NB: This does *not* cause failure to start any existing network that > contains one of those elements, so someone might have erroneously > defined such a network in the past, and that network will continue to > function unmodified. I considered it too disruptive to suddenly break > working configs on the next reboot after a libvirt upgrade. BTW, is there other means to re-use libvirt's handling of tc in order to apply QoS on the physical-facing leg of the forwarded bridge (in case that we end up going that way). Regards, Dan. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list