Re: [libvirt] [PATCH] network: disallow <bandwidth>/<mac> for bridged/macvtap networks
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.