Re: SPAM: [PATCH container/firewall/manager/network/qemu-server v3 00/16] handle dangling references when firewall objects go away

["Thomas Ellmenreich" <t.ellmenreich@proxmox.com>]

Thanks for sending in this series!

I ran some basic tests on the renaming and dropping functionality and found
that everything worked well.

Looking at the different operations that now have a new option to deal with
references, 'disable' is always possible, why is that not the case for rename.
There might be a technical reason that I'm currently not thinking of, but I
can see 'disabling' the referencing rules being a worthwhile option when
performing a rename.

The tests I performed were:

Renaming of aliases and ipsets:
    For this, I created aliases both at the cluster and vm level. I then
    referenced these aliases in the firewall rules of the cluster, node and vm.
    The aliases and ipsets defined at the vm level were only referenced in vm
    level rules. Performing some renames with the different settings acted
    exactly as expected. I also used an alias in one of the ip sets and the
    rename worked perfectly in that case as well.

Simple benchmark for rename:
    By creating 500 guests and then defining a firewall rule on each guest
    referencing a cluster level alias, I could then benchmark the renaming of
    the alias. On average it took ~2,5 seconds which I find reasonable.

Deletion of vms:
    When deleting a vm, one has the option to keep/disable/delete the
    referencing rules. After creating the 500 vms for the benchmark, I added
    some more rules that reference the IPAM aliases. Using keep/disable/delete
    all worked exactly as expected.

So, aside from the question mentioned at the very beginning, consider this:

Tested-by: Thomas Ellmenreich <t.ellmenreich@proxmox.com>

On Fri Sep 25, 2026 at 11:42 AM CEST, Arthur Bied-Charreton wrote:
> Renaming or deleting a firewall object (an IPSet or an alias) that rules
> still reference leaves those references dangling. The firewall fails to
> parse the affected rules and drops them from the generated ruleset, so
> an edit in one place can disable a whole set of rules somewhere. This
> is especially bad in the rename case, where one might reasonably expect
> the references to follow the new object name.
>
> This series makes the affected operations offer to deal with the
> references instead of leaving them behind.
>
> pve-firewall gains a shared helper, update_refs(), whcih finds
> references in rules, security groups and IPset members and applies one
> of three actions: 'rename' points them at the new name, 'disable'
> disables the referencing rules, and 'drop' removes them. An IPSet member
> has no disabled state, so 'disable' removes members as well. For a
> cluster object, the helper also walks every downstream config in the
> cluster (guest, host and vnet), locking and saving each one.
>
> On top of this, three wrappers cover the SDN-generated IPSets that no
> caller can delete directly.
>
> These options are added to the API as follows:
>
> POST .../firewall/ipset               update-references no|yes|force
> PUT  .../firewall/aliases/{name}      update-references no|yes|force
> DELETE .../ipset/{name}               dangling-references keep|disable|drop
> DELETE .../aliases/{name}             dangling-references keep|disable|drop
> PUT  /cluster/sdn                     dangling-ipset-references keep|disable|drop
> DELETE /nodes/{node}/qemu/{vmid}      dangling-ipset-references keep|disable|drop
> DELETE /nodes/{node}/lxc/{vmid}       dangling-ipset-references keep|disable|drop
>
> On a rename, the new object is persisted before its references are
> rewritten, so a concurrent compilation does not observe a reference to
> an object that does not exist yet. If a cluster-wide rewrite is
> interrupted part way, passing 'force' resumes it (without this, the
> next attempt would fail due to the target name already existing in the
> config).
>
> While these options allow to trigger changes to the firewall
> configurations from other endpoints requiring different permissions,
> like guest destroy and SDN apply, they do not require any additional
> permissions, see full explanation here [0].
>
> Changes since [v2]:
> - Handle references to SDN-generated IPSets in SDN apply and guest
>   destroy
> - Support disabling rules referencing a deleted object instead of only
>   deleting them
>
> [v2] https://lore.proxmox.com/pve-devel/20260818133413.450776-1-a.bied-charreton@proxmox.com/
> [v1] https://lore.proxmox.com/pve-devel/20260407073658.90818-1-a.bied-charreton@proxmox.com/
>
> [0] https://lore.proxmox.com/pve-devel/awaoshjzbr7adisjngsrcts4zs3hxgoxw2lgcoq66gtiap3al2@mpxrbmtyfcwj/

[snip]