[pve-devel] applied: [PATCH manager v2 1/2] fix #3719: gui: expose LXC MTU option in web UI

[Wolfgang Bumiller]

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