From: Wolfgang Bumiller <w.bumiller@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Stefan Hanreich <s.hanreich@proxmox.com>,
Daniel Tschlatscher <d.tschlatscher@proxmox.com>
Subject: Re: [pve-devel] applied: [PATCH manager v2 1/2] fix #3719: gui: expose LXC MTU option in web UI
Date: Thu, 17 Nov 2022 13:52:32 +0100 [thread overview]
Message-ID: <20221117125232.lbexhh5ond4jbrim@casey.proxmox.com> (raw)
In-Reply-To: <dd47e35c-d607-782f-f32a-ca12f1e647b8@proxmox.com>
On Wed, Nov 16, 2022 at 08:11:22PM +0100, Thomas Lamprecht wrote:
> Am 11/11/2022 um 12:14 schrieb Stefan Hanreich:
> > Some Notes:
> > - Setting the MTU while the container is running, does not update the MTU of
> > the running container. If this is intended behavior it might be smart to
> > document it somewhere or throw a warning. This also doesn't
> > work for the VM patch. Not sure if this is even possible at runtime tbh.
^ This is the same for VMs and the MTU is *sort of* tied to the bridge's
mtu anyway. (Tbh I don't see the point in even having a setting for it
in the first place...)
> > - Adding a network device when the Container is running with a specific,
> > valid MTU (e.g. 1234) does add the network device to the container, BUT it
> > has a MTU of 1500. Upon reboot the correct MTU is set. Reloading the
^ not actually 1500, but whatever the *bridge* is configured to
> > Network config does not change anything. Maybe just an LXC limitation?
> >
>
> good notes which we should also improve (either implementing it or ensuring
> that the change stays pending if it cannot be hot-plugged), but both
> pre-existing behavior and so not a blocker for this.
MTUs are a bit of a beast.
I'm not sure we really need to change much here.
On the qemu side we only really check that it's valid, and pass it only
for virtio-net devices via the qemu command line, but do nothing when
changing running vms.
The thing is, when attaching a device to a bridge, it'll inherit the
bridge's mtu, so the host would usually see a different mtu there.
Not sure if - especially for containers - it makes much sense to have a
split view here, so unless someone really needs it, I'd say leave it ;-)
next prev parent reply other threads:[~2022-11-17 12:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-03 15:38 [pve-devel] " Daniel Tschlatscher
2022-11-03 15:38 ` [pve-devel] [PATCH manager v2 2/2] gui: move rate limit field to advanced section Daniel Tschlatscher
2022-11-03 15:38 ` [pve-devel] [PATCH container v2] better parsing for lxc networking mtu setting Daniel Tschlatscher
2022-11-11 11:14 ` [pve-devel] [PATCH manager v2 1/2] fix #3719: gui: expose LXC MTU option in web UI Stefan Hanreich
2022-11-16 19:11 ` [pve-devel] applied: " Thomas Lamprecht
2022-11-17 12:52 ` Wolfgang Bumiller [this message]
2022-11-17 13:13 ` DERUMIER, Alexandre
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=20221117125232.lbexhh5ond4jbrim@casey.proxmox.com \
--to=w.bumiller@proxmox.com \
--cc=d.tschlatscher@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=s.hanreich@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.