Am 04.09.25 um 11:11 AM schrieb Fabian Grünbichler: > On September 3, 2025 4:22 pm, Fiona Ebner wrote: >> 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]. 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. > > since the effective actual MTU value is determined by the migration > state, this means 8->8 migrations potentially also break traffic: > > VM config: mtu=1 (use bridge MTU) > source node: bridge MTU 9000 > host_mtu for starting source VM: 9000 > > target node: bridge MTU 1500 > host_mtu for starting target VM: 1500 > effective MTU of the vNIC: 9000, because that's what the source VM's > migration stream tells the target OS? > > right? so it might make sense to still detect and handle this also on > 8.x? can be done as a follow-up of course..
Yes, we can also backport "api: vm start: introduce nets-host-mtu parameter for migration compat" too :) _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
