From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 153351FF170 for ; Thu, 10 Jul 2025 16:52:38 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 02FFD3723F; Thu, 10 Jul 2025 16:53:21 +0200 (CEST) Date: Thu, 10 Jul 2025 16:53:18 +0200 From: Gabriel Goller To: Stefan Hanreich Message-ID: Mail-Followup-To: Stefan Hanreich , pve-devel@lists.proxmox.com References: <20250709194526.560709-1-s.hanreich@proxmox.com> <20250709194526.560709-8-s.hanreich@proxmox.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20250709194526.560709-8-s.hanreich@proxmox.com> User-Agent: NeoMutt/20241002-35-39f9a6 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.014 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. 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 pve-manager 1/1] cli: add pveeth 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: , Reply-To: Proxmox VE development discussion Cc: pve-devel@lists.proxmox.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" On 09.07.2025 21:45, Stefan Hanreich wrote: >> [snip] >Example invocations of pveeth: > >$ pveeth pin --nic enp1s0 --force 0 --dry_run 0 > >Generates a pinning for enp1s0 (if it doesn't exist already) and >updates the configuration file. > >$ pveeth pin --force 1 --dry_run 0 s/pin/unpin >Deletes all existing pins and re-generates them. > >For more information on the parameters see the API description. > >I've decided to let dry_run generate the configuration files in the >current working directory, since it is then easy to diff the generated >files with the existing configuration files using the diffviewer of >the users' choice. > >Additionally, when writing the configuration files, they get backed up >by creating a .bak at the location of the configuration file. > >Currently we only support a fixed prefix: 'nic'. This is because we >rely on PHYISCAL_NIC_RE for detecting physical network interfaces >across several places in our codebase. For now, nic has been added as >a valid prefix for NICs in pve-common, so we use that prefix here. This would be nice to have as a comment in the code, I can already see people that want to change the prefix and start editing the constant :) >In order to support custom prefixes, we would have to remove every >place in the code relying on PHYISCAL_NIC_RE (at least), in order to >avoid breakage. When pinning, could we add the previous old name as an altname? So tools that respect altnames could work transparently. This should be as simple as adding, e.g.: AlternativeName=ens18 to the link file. However, unpinning has a problem. Currently, we reset to the `ID_NET_NAME_PATH` name from `udevadm` and remove the link file, but we don't know the current systemd `NamePolicy`. For example, if the original interface was `ens18` using Slot policy, after pinning it becomes `nic0`. When unpinning, the interface becomes `ens18` again (because I'm using slot policy), but the config files reference `enp0s18` (because `pveeth` assumes we use path policy). This breaks the network configuration. I think the solution is to avoid deleting the link file during unpinning. Instead, we should just update the interface name. The problem is that we can't determine which policy was originally used, so pin-unpin cycles *don't* restore the original interface name. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel