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.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
