From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <s.hanreich@proxmox.com>
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))
 (No client certificate requested)
 by lists.proxmox.com (Postfix) with ESMTPS id D9D4F8E4AD
 for <pve-devel@lists.proxmox.com>; Fri, 11 Nov 2022 12:24:08 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with ESMTP id B63002CDA
 for <pve-devel@lists.proxmox.com>; Fri, 11 Nov 2022 12:24:08 +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 <pve-devel@lists.proxmox.com>; Fri, 11 Nov 2022 12:24:07 +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 47DE443987
 for <pve-devel@lists.proxmox.com>; Fri, 11 Nov 2022 12:14:31 +0100 (CET)
Message-ID: <5fd1a4f0-8afc-ad12-db52-6a19d42ffced@proxmox.com>
Date: Fri, 11 Nov 2022 12:14:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.0
Content-Language: en-US
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
 Daniel Tschlatscher <d.tschlatscher@proxmox.com>
References: <20221103153810.690086-1-d.tschlatscher@proxmox.com>
From: Stefan Hanreich <s.hanreich@proxmox.com>
In-Reply-To: <20221103153810.690086-1-d.tschlatscher@proxmox.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results:  0
 AWL 0.597 Adjusted score from AWL reputation of From: address
 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 Alignment
 NICE_REPLY_A           -0.001 Looks like a legit reply (A)
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
Subject: Re: [pve-devel] [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 <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Fri, 11 Nov 2022 11:24:08 -0000

Tested on an Alpine Linux Container (3.16):

- setting MTU > 65535 or < 576 via UI (doesn't work)
- setting MTU to several values >= 576 and <= 65535 via UI (works)
- setting MTU to >= 64 and < 576 via config then starting (works, but 
this is apparently intended otherwise it would be a backwards breaking 
change)
- setting MTU >= 576 and <= 65535 via Config and then starting the 
container (works)
- setting MTU > 65535 or < 64 via Config and then starting the container 
(doesn't work)

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.
- 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 
Network config does not change anything. Maybe just an LXC limitation?

Code LGTM - small nit: there is still a gettext('MTU') left in the 
NetworkView, but it has been changed in the NetworkInputPanel.

Reviewed-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Stefan Hanreich <s.hanreich@proxmox.com>

On 11/3/22 16:38, Daniel Tschlatscher wrote:
> The option to set the mtu parameter for lxc containers already exists
> in the backend. It just has to be exposed in the web UI as well.
>
> Signed-off-by: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
> ---
> Changes from v1:
> * fieldLabel for MTU textfield no longer uses gettext()
> * text field has an emptyText now
> * the minimum value for the MTU is 576 in the frontend now
>
>   www/manager6/lxc/Network.js | 18 ++++++++++++++++++
>   1 file changed, 18 insertions(+)
>
> diff --git a/www/manager6/lxc/Network.js b/www/manager6/lxc/Network.js
> index 7b6437c5..c6c40934 100644
> --- a/www/manager6/lxc/Network.js
> +++ b/www/manager6/lxc/Network.js
> @@ -282,6 +282,18 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
>   	    },
>   	];
>   
> +	me.advancedColumn1 = [
> +	    {
> +		xtype: 'proxmoxintegerfield',
> +		fieldLabel: 'MTU',
> +		emptyText: gettext('Same as bridge'),
> +		name: 'mtu',
> +		value: cdata.mtu,
> +		minValue: 576,
> +		maxValue: 65535,
> +	    },
> +	];
> +
>   	me.callParent();
>       },
>   });
> @@ -519,6 +531,11 @@ Ext.define('PVE.lxc.NetworkView', {
>   			}
>   		    },
>   		},
> +		{
> +		    header: gettext('MTU'),
> +		    width: 80,
> +		    dataIndex: 'mtu',
> +		},
>   	    ],
>   	    listeners: {
>   		activate: me.load,
> @@ -543,6 +560,7 @@ Ext.define('PVE.lxc.NetworkView', {
>   	    'gw6',
>   	    'tag',
>   	    'firewall',
> +	    'mtu',
>   	],
>       });
>   });