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

[Maxime Coquelin]

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.