public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
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 ;-)




  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 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