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

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

Am 04.09.25 um 14:41 schrieb Fiona Ebner:
> 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.
even though I think that breaking new to old here might be avoidable
without to bending much backward I still applied the series now, a
annoying up front error (even if potentially not required) is better
than crashing VM and can still be improved later on.


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