mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2025-02-28 22:32:19 +00:00
eafb53fec2
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 libvirt doesn't have enough information to know where to set such limits. We are working on a method of supporting network bandwidths for some specific cases of <forward mode='bridge'/>, but currently libvirt doesn't support it. So the proper thing to do now is just log an error when someone tries to put a <bandwidth> element in that type of network. (It's unclear if we will be able to do proper bandwidth limiting for macvtap networks, and most definitely we will not be able to support it for hostdev 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 in the same cases, rather than failing so that the user will understand that their desired action has not been taken. 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.