consider this Reviewed-by: Fabian Grünbichler <f.gruenbich...@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
