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.