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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 02/03/2017 12:41 PM, Dr. David Alan Gilbert wrote:
* Laine Stump (laine@xxxxxxxxx) wrote:
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 :-/)
Or what happens if I migrate between hosts where the host network
hardware has different MTU?

Right! I think that may be problematic even without any support for host_mtu (the guest will at least be the same, but the host side of the tap device will have a different MTU; I haven't even tried to think about what problems that might cause - e.g. guest migrates and tap device now has a 9000 MTU (as does everything else connected to the same bridge), but the guest interface still thinks the MTU is 1500. Does this make anything go screwy? Or does everything correct itself around the difference? Probably someone needs to try it... (/averts gaze, avoids eye contact)

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux