Re: [libvirt] [PATCH v2 4/4] qemu: propagate bridge MTU into qemu "host_mtu" option

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.