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

["Daniel Kral" <d.kral@proxmox.com>]

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 
> 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/<zone>/<vnet>
> * vnet/<zone>/<vnet>/<vlan>
>
> The type prefix allows future extension to other network resource 
> 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.