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 70A841FF16B for ; Tue, 9 Sep 2025 10:02:19 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id C4C84159E; Tue, 9 Sep 2025 10:02:20 +0200 (CEST) Message-ID: <06234aa5-c0b9-4f61-9b43-afb71771862d@proxmox.com> Date: Tue, 9 Sep 2025 10:01:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Thomas Lamprecht , Proxmox VE development discussion References: <20250908134813.110243-1-f.ebner@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1757404884374 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.024 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 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [qemumigrate.pm] Subject: Re: [pve-devel] [PATCH qemu-server master+stable-bookworm] migration: check if target supports nets-host-mtu parameter up front 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 08.09.25 um 4:49 PM schrieb Thomas Lamprecht: > Am 08.09.25 um 15:48 schrieb Fiona Ebner: >> Avoid blocking backwards migration to nodes that do not support the >> new 'nets-host-mtu' parameter yet for local cluster migrations.0 > > Please add a short rationale about the approach used to detect that. > > Further, for 8.X <-> 8.Y this is now fine, but for 8.X to 9.Y (with 9.Y > being to old to know about the new parameter) it still can cause a VM > crash, or? Yeah. So for a 9.x source or 9.x target, we might not even want to avoid the parameter at all, but just match the error for the real command and tell users to upgrade like you initially suggested. Because most migrations will have a NIC with MTU set to "inherit from bridge" and thus be potentially problematic if not passing 'nets-host-mtu'. I mean, we could still avoid setting the parameter if all MTUs are set explicitly to a value, but it doesn't seem worth checking for that, as it would reduce friction only in a very small number of cases. In case it's a 8.x source to 8.x target migration, we could check if any MTU is set to "inherit from bridge" and set and require the presence of the parameter only in that case, because there, it is not the (vast) majority of migrations. > >> Suggested-by: Thomas Lamprecht >> Signed-off-by: Fiona Ebner >> --- >> src/PVE/QemuMigrate.pm | 14 +++++++++++++- >> 1 file changed, 13 insertions(+), 1 deletion(-) >> >> diff --git a/src/PVE/QemuMigrate.pm b/src/PVE/QemuMigrate.pm >> index 4381b542..f01c7907 100644 >> --- a/src/PVE/QemuMigrate.pm >> +++ b/src/PVE/QemuMigrate.pm >> @@ -958,6 +958,18 @@ sub phase1_cleanup { >> } >> } >> >> +my sub target_supports_nets_host_mtu { >> + my ($self, $forcemachine) = @_; >> + >> + return 1 if PVE::QemuServer::Machine::is_machine_version_at_least($forcemachine, 10, 0, 1); >> + >> + my $cmd = [$self->{rem_ssh}->@*, 'qm', 'start', 0, '--nets-host-mtu']; > > Could be nice to have a comment that this depends on the unknown parameter > error getting checked earlier compared to the fixed 0 parameter not being a > valid VMID. > >> + >> + my $err = ''; >> + eval { PVE::Tools::run_command($cmd, outfunc => sub { }, errfunc => sub { $err .= shift }) }; >> + return $err =~ m/^Unknown option: nets-host-mtu/ ? 0 : 1; >> +} >> + >> sub phase2_start_local_cluster { >> my ($self, $vmid, $params) = @_; >> >> @@ -998,7 +1010,7 @@ sub phase2_start_local_cluster { >> push @$cmd, '--force-cpu', $start->{forcecpu}; >> } >> >> - if ($start->{'nets-host-mtu'}) { >> + if ($start->{'nets-host-mtu'} && target_supports_nets_host_mtu($self, $start->{forcemachine})) { >> push @$cmd, '--nets-host-mtu', $start->{'nets-host-mtu'}; >> } >> > _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel