On 02/06/2017 01:57 PM, Michal Privoznik wrote:
On 03.02.2017 18:35, Laine Stump wrote:
libvirt was able to set the host_mtu option when an MTU was explicitly given in the interface config (with <mtu size='n'/>), set the MTU of a libvirt network in the network config (with the same named subelement), and would automatically set the MTU of any tap device to the MTU of the network.
This patch ties that all together (for networks based on tap devices and either Linux host bridges or OVS bridges) by learning the MTU of the network (i.e. the bridge) during qemuInterfaceBridgeConnect(), and returning that value so that it can be passed to qemuBuildNicDevStr(); qemuBuildNicDevStr() then sets host_mtu in the interface's commandline options.
The result is that a higher MTU for all guests connecting to a particular network will be plumbed top to bottom by simply changing the MTU of the network (in libvirt's config for libvirt-managed networks, or directly on the bridge device for simple host bridges or OVS bridges managed outside of libvirt).
One question I have about this - it occurred to me that in the case of migrating a guest from a host with an older libvirt to one with a newer libvirt, the guest may have *not* had the host_mtu option on the older machine, but *will* have it on the newer machine. I'm curious if this could lead to incompatibilities between source and destination (I guess it all depends on whether or not the setting of host_mtu has a practical effect on a guest that is already running - Maxime?) (I hope we don't have to add a "<mtu auto='yes'/>" and only set host_mtu when that is present :-/)
This is a question for qemu folks. I know nothing about qemu internals.
Sorry for the late reply. Setting host_mtu on a guest that is already running will have no effect. Indeed, the VIRTIO_NET_F_MTU feature flag will be set at device negotiation time if host_mtu is set. So, if guest started without this host_mtu parameter, this flag won't be set and the value won't be taken into account.