From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 1C8E1917B for ; Thu, 17 Nov 2022 13:53:05 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id F17C82C7DD for ; Thu, 17 Nov 2022 13:52:34 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Thu, 17 Nov 2022 13:52:33 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 7616D40967 for ; Thu, 17 Nov 2022 13:52:33 +0100 (CET) Date: Thu, 17 Nov 2022 13:52:32 +0100 From: Wolfgang Bumiller To: Thomas Lamprecht Cc: Proxmox VE development discussion , Stefan Hanreich , Daniel Tschlatscher Message-ID: <20221117125232.lbexhh5ond4jbrim@casey.proxmox.com> References: <20221103153810.690086-1-d.tschlatscher@proxmox.com> <5fd1a4f0-8afc-ad12-db52-6a19d42ffced@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-SPAM-LEVEL: Spam detection results: =?UTF-8?Q?0=0A=09?=AWL 0.229 Adjusted score from AWL reputation of From: =?UTF-8?Q?address=0A=09?=BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict =?UTF-8?Q?Alignment=0A=09?=SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF =?UTF-8?Q?Record=0A=09?=SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] applied: [PATCH manager v2 1/2] fix #3719: gui: expose LXC MTU option in web UI X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2022 12:53:05 -0000 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 ;-)