From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 4A2341FF189 for ; Thu, 4 Sep 2025 20:17:02 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 7072635F26; Thu, 4 Sep 2025 20:17:16 +0200 (CEST) Message-ID: <9016bae5-c60b-4851-94db-7d3d0c56bcd0@proxmox.com> Date: Thu, 4 Sep 2025 20:16:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta To: Proxmox VE development discussion , Fiona Ebner References: <20250904124113.81772-1-f.ebner@proxmox.com> Content-Language: en-US From: Thomas Lamprecht In-Reply-To: <20250904124113.81772-1-f.ebner@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1757009785586 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.029 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: [pve-devel] applied: [PATCH-SERIES qemu-server v3 0/8] virtio-net: fix migration between default/non-default MTUs X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" 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