From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id D45471FF170 for ; Thu, 10 Jul 2025 18:24:35 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E1099387E2; Thu, 10 Jul 2025 18:25:19 +0200 (CEST) Date: Thu, 10 Jul 2025 18:25:15 +0200 From: Gabriel Goller To: Thomas Lamprecht Message-ID: Mail-Followup-To: Thomas Lamprecht , 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: User-Agent: NeoMutt/20241002-35-39f9a6 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.015 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 10.07.2025 17:08, Thomas Lamprecht wrote: >Am 10.07.25 um 16:53 schrieb Gabriel Goller: >> 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. > >This can interfere with automatic naming of unpinned/new interfaces and can >get really confusing if the automatic derived name changes due to replugging >the NIC to another slot and then the pinned alt name is wrong, as it suggest >that the NIC is in a different slot. Or if the layout changes otherwise and >another NIC would get this alt name, so there might be different NICs then >with very similar names. Ah true, didn't think of this. Yeah this would create a mess, nevermind. >> >> 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. >> > >This I'd need to think through, just wanted to comment on above before >I forget. If we really want to make pin and unpin involutive, we would need to store somewhere the interface names or store the interface naming policy. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel