From: Stefan Hanreich <s.hanreich@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH docs/manager/qemu-server v2 0/3] Make VirtIO network devices always inherit MTU from bridge
Date: Wed, 23 Apr 2025 13:52:40 +0200 [thread overview]
Message-ID: <cb255f54-80b7-4149-80e9-9f633b18b353@proxmox.com> (raw)
In-Reply-To: <e12bc42b-892c-47e5-830b-c44aeb1817df@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
prev parent reply other threads:[~2025-04-23 11:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 10:48 Stefan Hanreich
2025-04-17 10:48 ` [pve-devel] [PATCH qemu-server v2 1/1] net: pass host_mtu parameter when mtu is unset in netdev config Stefan Hanreich
2025-04-17 10:48 ` [pve-devel] [PATCH pve-manager v2 1/1] qemu: network: adjust MTU emptyText to match new default behavior Stefan Hanreich
2025-04-17 10:48 ` [pve-devel] [PATCH pve-docs v2 1/1] qm: document new default behavior for mtu setting Stefan Hanreich
2025-04-18 7:46 ` [pve-devel] [PATCH docs/manager/qemu-server v2 0/3] Make VirtIO network devices always inherit MTU from bridge Thomas Lamprecht
2025-04-22 11:33 ` Stefan Hanreich
2025-04-22 14:48 ` Thomas Lamprecht
2025-04-23 11:52 ` Stefan Hanreich [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cb255f54-80b7-4149-80e9-9f633b18b353@proxmox.com \
--to=s.hanreich@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=t.lamprecht@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal