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