Re: [pve-devel] [PATCH-SERIES qemu-server v3 0/8] virtio-net: fix migration between default/non-default MTUs

["Fabian Grünbichler" <f.gruenbichler@proxmox.com>]

consider this

Reviewed-by: Fabian Grünbichler <f.gruenbichler@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@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> 
> 
> 


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel