From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id D1D7F1FF150 for ; Mon, 06 Jul 2026 16:08:25 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 00EFA2146E; Mon, 06 Jul 2026 16:08:24 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 06 Jul 2026 16:07:50 +0200 Message-Id: Subject: Re: [PATCH access-control/cluster/common/manager/network/proxmox-widget-toolkit/qemu-server v2 00/10] fix #7294: pool: add SDN VNets as pool members From: "Daniel Kral" To: "David Riley" , X-Mailer: aerc 0.21.0-147-g43ac7b685014-dirty References: <20260626131035.112374-1-d.riley@proxmox.com> In-Reply-To: <20260626131035.112374-1-d.riley@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1783346864332 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.016 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: NXTYAPWCSTZH5LG2RE2RSQJVJLRB7FMI X-Message-ID-Hash: NXTYAPWCSTZH5LG2RE2RSQJVJLRB7FMI X-MailFrom: d.kral@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Fri Jun 26, 2026 at 3:10 PM CEST, David Riley wrote: > This series implements support for adding SDN VNets to resource pools, > resolving #7294 [0]. This series depends on the v4 'fix #7520: sdn: > prune orphaned ACLs and handle VNet migrations' [1]. > > It does not, however, add zones as pool members as requested in #7294. > Zones currently share ACL paths for managing the zone itself and > allocating VNets within it. This makes self-service VNet management > without also granting zone management (and its associated=20 > side-effects) difficult. > > This patch series extends the pool section in the user.cfg and > introduces a new network property to the pool configuration which will > hold VNet entries: > * vnet// > * vnet/// > > The type prefix allows future extension to other network resource=20 > types. > > To prevent potential data loss from overwriting newly added VNets, a > cluster-version check is added which ensures all nodes are running a > version that supports this feature. Note: The hardcoded version guard > should be updated to match the final target release when being > applied. > > The existing version check helpers were moved from `qemu-server` to a > new module within `pve-cluster` to make them available for this > implementation, and any future developments that require gatekeeping. > Appropriate attribution has been included for the relocated code. > Please let me know if this organizational move aligns with current > design preferences or additional adjustments are needed. Nice work on this series! A nice addition could be to be able to display the changes done on SDN config commit with the 'dry-run' API endpoint, but that would only be a nice-to-have and definitely doesn't block this series in any way. The patches #4, #6, #9, and #10 don't really need the 'fix #7294' prefix as these are not really related to closing the bugzilla entry, but are only prepatory steps, but not the actual fix. Besides the comments inline, another quick thought is that if there is some propagation from VNets to VLAN tags, either with the explicit asterisk or not, it might be a good measure to check for duplicates, e.g., if vnet/zone1/vnet1/* exists, then vnet/zone1/vnet/2 would already include that and cannot be added. But this is more out of caution, so no hard feelings about this.