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

[Arthur Bied-Charreton <a.bied-charreton@proxmox.com>]

On Wed, Sep 30, 2026 at 09:44:25AM +0200, Thomas Ellmenreich wrote:
> Thanks for sending in this series!
> 
thanks for having a look :)
> 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.
> 
good point, I had not considered that. it could be useful when the old
name is going to be reused afterwards. I am not sure how common this
would be in practice, but the helper already implements 'disable', so
wiring it up for rename is cheap. 

I will look into this!

> 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.
> 
thanks a lot for the extensive testing!
> 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:
> 
> > [...]
> 
> [snip]