[libvirt] [PATCH] network: disallow <bandwidth>/<mac> for bridged/macvtap networks

[Dan Kenigsberg]

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.