[pve-devel] [PATCH-SERIES qemu-server v3 0/8] virtio-net: fix migration between default/non-default MTUs
Fabian Grünbichler
f.gruenbichler at proxmox.com
Thu Sep 4 15:06:02 CEST 2025
consider this
Reviewed-by: Fabian Grünbichler <f.gruenbichler at proxmox.com>
haven't had time yet for in-depth tests.
the 'nets-host-mtu' name reads a bit strange, but there is precedent for
similarly named stuff in the code already, and the parameter is really
for internal use only anyway, so..
On September 4, 2025 2:40 pm, Fiona Ebner wrote:
> Changes in v3:
> * add part three - snapshot handling
> * backport full migration+start handling
> * schema description: explicitly mention that a value of 0 means to
> not use host_mtu
> * die when host_mtu > bridge MTU also upon migration and expand error
> message
> * less bloaty code by always mentioning migrated host_mtu value
> * move get_nets_host_mtu to network module for re-use with snapshots
> * avoid overly long line in tests
>
> Changes in v2:
> * push make tidy change already to master
> * add part two - migration
> * move version_guard() call to outside of print_netdevice_full() call
> * add comment about why host_mtu is always set in source code
>
> The virtual hardware is generated differently (at least for i440fx
> machines) when host_mtu is set or not set on the netdev command line
> [0]. When the MTU is the same value as the default 1500, Proxmox VE
> did not add a host_mtu parameter. This is problematic for migration
> where host_mtu is present on one end of the migration, but not on the
> other [1].
>
> Always set the host_mtu parameter starting with machine version
> 10.0+pve1 to avoid this issue going forward. For snapshots, the
> nets-host-mtu information is recorded in the snapshot config. When the
> information is not present, this series keeps the behavior on Proxmox
> VE 8 and Proxmox VE 9 as-is, i.e. loading a Proxmox VE 8 snapshot on
> Proxmox VE 9 when the bridge MTU has a mismatch can still be
> problematic. Loading snapshots made on the same major version works.
> The VM start parameter already provides an escape hatch. We could also
> think about doing a follow-up and automatically try to fallback to
> Proxmox VE 8 default behavior when loading the snapshot fails (for
> machine verison < 10.0+pve1).
>
> Moreover, the effective setting in the guest (state) will
> still be the host_mtu from the source side, even if a different value
> is used for host_mtu on the target instance's commandline. This will
> not lead to an error loading the migration stream in QEMU, but having
> a larger host_mtu than the bridge MTU is still problematic for certain
> network traffic like
>> iperf3 -c 10.10.10.11 -u -l 2k
> when host_mtu=9000 and bridge MTU=1500.
>
> Add the necessary parameter for VM start and pass the values along for
> migration to preserve the values going forward.
>
> For Proxmox VE 8, the migration handling fixes are backported.
>
> stable-bookworm
>
> Fiona Ebner (2):
> api: vm start: introduce nets-host-mtu parameter for migration compat
> migration: preserve host_mtu for virtio-net devices
>
>
> master:
>
> Fiona Ebner (6):
> virtio-net: fix migration between default/non-default MTUs starting
> with machine version 10.0+pve1
> api: vm start: introduce nets-host-mtu parameter for migration compat
> migration: preserve host_mtu for virtio-net devices
> snapshot: save vmstate: avoid using deprecated check_running()
> function
> snapshot: save vmstate: die when PID cannot be obtained
> snapshot: introduce running-nets-host-mtu property
>
> src/PVE/API2/Qemu.pm | 13 ++++
> src/PVE/QemuConfig.pm | 13 ++--
> src/PVE/QemuMigrate.pm | 8 +++
> src/PVE/QemuServer.pm | 62 +++++++++++++++++--
> src/PVE/QemuServer/Machine.pm | 6 ++
> src/PVE/QemuServer/Network.pm | 29 +++++++++
> src/PVE/QemuServer/RunState.pm | 3 +-
> src/test/MigrationTest/QemuMigrateMock.pm | 15 +++++
> src/test/cfg2cmd/bootorder-empty.conf.cmd | 4 +-
> src/test/cfg2cmd/bootorder-legacy.conf.cmd | 4 +-
> src/test/cfg2cmd/bootorder.conf.cmd | 4 +-
> src/test/cfg2cmd/efidisk-on-rbd.conf.cmd | 4 +-
> src/test/cfg2cmd/ide.conf.cmd | 4 +-
> .../cfg2cmd/netdev-7.1-multiqueues.conf.cmd | 2 +-
> src/test/cfg2cmd/netdev-7.1.conf.cmd | 2 +-
> src/test/cfg2cmd/netdev_vxlan.conf.cmd | 2 +-
> src/test/cfg2cmd/q35-ide.conf.cmd | 4 +-
> .../q35-linux-hostpci-mapping.conf.cmd | 4 +-
> .../q35-linux-hostpci-multifunction.conf.cmd | 4 +-
> ...q35-linux-hostpci-x-pci-overrides.conf.cmd | 4 +-
> src/test/cfg2cmd/q35-linux-hostpci.conf.cmd | 4 +-
> src/test/cfg2cmd/q35-simple.conf.cmd | 4 +-
> src/test/cfg2cmd/seabios_serial.conf.cmd | 4 +-
> src/test/cfg2cmd/simple-btrfs.conf.cmd | 4 +-
> .../cfg2cmd/simple-disk-passthrough.conf.cmd | 4 +-
> src/test/cfg2cmd/simple-rbd.conf.cmd | 4 +-
> src/test/cfg2cmd/simple-virtio-blk.conf.cmd | 4 +-
> .../cfg2cmd/simple-zfs-over-iscsi.conf.cmd | 4 +-
> src/test/cfg2cmd/simple1.conf.cmd | 4 +-
> 29 files changed, 177 insertions(+), 50 deletions(-)
>
> --
> 2.47.2
>
>
>
> _______________________________________________
> pve-devel mailing list
> pve-devel at lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
>
>
More information about the pve-devel
mailing list