From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <pve-devel-bounces@lists.proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id F014A1FF172 for <inbox@lore.proxmox.com>; Wed, 23 Apr 2025 13:53:22 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id C001D1932E; Wed, 23 Apr 2025 13:53:18 +0200 (CEST) Message-ID: <cb255f54-80b7-4149-80e9-9f633b18b353@proxmox.com> Date: Wed, 23 Apr 2025 13:52:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Stefan Hanreich <s.hanreich@proxmox.com> To: Thomas Lamprecht <t.lamprecht@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com> References: <20250417104855.144882-1-s.hanreich@proxmox.com> <9ecdfff3-7458-4c37-a153-dce43a9ff93e@proxmox.com> <0d965cab-3962-475a-b285-e75d86fe1183@proxmox.com> <e12bc42b-892c-47e5-830b-c44aeb1817df@proxmox.com> Content-Language: en-US In-Reply-To: <e12bc42b-892c-47e5-830b-c44aeb1817df@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.665 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 Subject: Re: [pve-devel] [PATCH docs/manager/qemu-server v2 0/3] Make VirtIO network devices always inherit MTU from bridge X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com> On 4/22/25 16:48, Thomas Lamprecht wrote: > Am 22.04.25 um 13:33 schrieb Stefan Hanreich: >> A possible regression I can think of is: If the bridge was set to the >> wrong MTU (e.g. 9000) at some point, but external devices in the same >> LAN are still set to use a lower MTU (e.g. 1500). If users never >> configured the larger MTU anywhere else besides the bridge, then this >> would break. > > Above is basically what I meant. For that case I think just the notice in the check script is sufficient. IMO this should be rather rare in practice. But, thinking more about potential regressions / issues: I'll double-check this series w.r.t the bridge inheriting MTU from bridge ports just to make sure we won't run into any funky business there. IIRC there is some unintuitive behavior on how the MTU on bridges gets set, when adding ports with mismatched MTU. I'll try to torture test this a bit more this or next week. >>> FWIW, we could also tie this behavior to a machine version to avoid changing >>> the behavior for any existing VM. But I would be fine with applying this only >>> for PVE 9 then and add a notice to the pve8to9 checker script that lists all >>> VMs that will change their MTU including the respective value. >> >> I think it would be a good idea to include this in pve8to9 with warnings >> at least and mention it in the release notes. It might make for some >> noise and unsettle some users though. Since we cannot really tell what >> MTU is set inside the VM, we'd have to show warnings for basically every >> network device on a bridge with MTU != 1500. > > Well, yes, but I used "notice" over "warning" for a reason, as we have > that level in the checker script, and it fits this change well IMO. I agree. Fits better than warning since it will usually work just fine. I'll send a new version with an additional patch for pve8to9 as soon as that's available in pve-manager. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel