Re: [libvirt] [PATCH] Revert "qemu: propagate bridge MTU into qemu "host_mtu" option"

This reverts commit 2841e675. It turns out that adding the host_mtu field to the PCI capabilities in the guest bumps the length of PCI capabilities beyond the 32 byte boundary, so the virtio-net device gets 64 bytes of ioport space instead of 32, which offsets the address of all the other following devices. Migration doesn't work very well when the location and length of PCI capabilities of devices is changed between source and destination. This means that we need to make sure that the absence/presence of host_mtu on the qemu commandline always matches between source and destination, which means that we need to make setting of host_mtu an opt-in thing (it can't happen automatically when the bridge being used has a non-default MTU, which is what commit 2841e675 implemented). I do want to re-implement this feature with an <mtu auto='on'/> setting, but probably won't backport that to any stable branches, so I'm first reverting the original commit, and that revert can be pushed to the few releases that have been made since the original (3.1.0 - 3.3.0) Resolves: https://bugzilla.redhat.com/1449346 --- src/qemu/qemu_command.c | 32 ++++++++++---------------------- src/qemu/qemu_command.h | 3 +-- src/qemu/qemu_hotplug.c | 5 ++--- src/qemu/qemu_interface.c | 5 ++--- src/qemu/qemu_interface.h | 3 +-- 5 files changed, 16 insertions(+), 32 deletions(-)