Security Group update followed by commit causes duplicate update_sg execution and removes VM firewall chains #8143

Description

A user reported on the OpenNebula forum that calling one.secgroup.commit immediately after updating a Security Group results in duplicate update_sg operations for the same VM. The first operation succeeds, but the second fails when attempting to recreate existing iptables chains.
The user also reported that the failed operation removes the VM's firewall chains, leaving the VM without its expected Security Group enforcement.
This was independently reproduced on both behaviors on OpenNebula 7.4.1.
The finding indicates two related problems:

Calling one.secgroup.update followed immediately by one.secgroup.commit can trigger overlapping Security Group update processing for the same VM.
When the second execution fails because an iptables chain already exists, the networking driver's exception handler removes the VM-specific firewall chains instead of preserving the previously applied rules.
Although calling commit immediately after update is unnecessary under normal circumstances, the resulting failure should not remove existing firewall enforcement.

Steps to reproduce

1. Create a Security Group
   Create /tmp/sg-repro-22.txt:

NAME = "sg-repro-741"

RULE = [
    PROTOCOL = TCP,
    RULE_TYPE = inbound,
    RANGE = 22
]

RULE = [
    PROTOCOL = ALL,
    RULE_TYPE = outbound
]

Create the Security Group:

onesecgroup create /tmp/sg-repro-22.txtIn the environment, the Security Group was assigned ID 100.

2. Attach the Security Group to a running VM

onevm sg-attach 22 0 100Wait until the Security Group update completes.

3. Prepare an updated Security Group template
   Create /tmp/sg-repro-22-80.txt:

NAME = "sg-repro-741"

RULE = [
    PROTOCOL = TCP,
    RULE_TYPE = inbound,
    RANGE = 22
]

RULE = [
    PROTOCOL = TCP,
    RULE_TYPE = inbound,
    RANGE = 80
]

RULE = [
    PROTOCOL = ALL,
    RULE_TYPE = outbound
]

4. Execute update followed immediately by commit

onesecgroup update 100 /tmp/sg-repro-22-80.txt
onesecgroup commit 100

No delay was introduced between the commands.
Actual results
Both API operations return successfully:

Fri Sep 25 14:56:01 2026 [Z0][ReM][D]:
Req:5723 UID:0 IP:127.0.0.1 one.secgroup.update invoked 100, NAME = "sg-r...

Fri Sep 25 14:56:01 2026 [Z0][ReM][D]:
Req:5723 UID:0 one.secgroup.update result SUCCESS, 100

Fri Sep 25 14:56:02 2026 [Z0][ReM][D]:
Req:5576 UID:0 IP:127.0.0.1 one.secgroup.commit invoked 100, 0

Fri Sep 25 14:56:02 2026 [Z0][ReM][D]:
Req:5576 UID:0 one.secgroup.commit result SUCCESS, 100However, the VMM subsequently reports two update results for the same VM and Security Group.
First execution succeeds:
Fri Sep 25 14:56:05 2026 [Z0][VMM][D]:
Message received: UPDATESG SUCCESS 22 100 fw: -Second execution fails:
Fri Sep 25 14:56:06 2026 [Z0][VMM][E]:
update_sg: Command Error: sudo -n iptables -w 3 -N one-22-0-i

Fri Sep 25 14:56:06 2026 [Z0][VMM][E]:
update_sg: /var/tmp/one/vnm/command.rb:110:in `block in run!'

Fri Sep 25 14:56:06 2026 [Z0][VMM][E]:
update_sg: /var/tmp/one/vnm/security_groups_iptables.rb:561:in `nic_pre'

Fri Sep 25 14:56:06 2026 [Z0][VMM][E]:
update_sg: /var/tmp/one/vnm/sg_driver.rb:115:in `block in activate'

Fri Sep 25 14:56:06 2026 [Z0][VMM][D]:
Message received: UPDATESG FAILURE 22 100 fw:
iptables: Chain already exists.ExitCode: 1The second operation attempts to create an iptables chain that already exists:

iptables -w 3 -N one-22-0-iThe operation fails with exit code 1.

Previous Firewall chains disappear following the failed operation
Before reproducing the failure, the VM had the following iptables chains:

:one-22-0-i - [0:0]
:one-22-0-o - [0:0]

-A opennebula -m physdev --physdev-in one-22-0 --physdev-is-bridged -j one-22-0-o
-A opennebula -m physdev --physdev-out one-22-0 --physdev-is-bridged -j one-22-0-i

After reproducing the issue again, without performing any recovery, I checked the firewall:

iptables -S one-22-0-iOutput:
iptables: No chain/target/match by that name.The outbound chain was also missing:

iptables -S one-22-0-oOutput:
iptables: No chain/target/match by that name.

A complete iptables-save confirmed that the VM-specific chains and their corresponding jump rules had been removed.
Other VMs' firewall chains remained present.
This confirms that the failed update can remove the affected VM's Security Group enforcement.

Expected behavior

Security Group updates should not produce overlapping networking-driver operations for the same VM/NIC.
If an update is already in progress, an additional commit request should be handled without conflicting with that operation.
A failed Security Group update must not leave the VM without its previously applied firewall rules.
If a new ruleset cannot be applied successfully, the networking driver should preserve or restore the last successfully applied ruleset.
The final Security Group status should reflect the actual enforcement state on the hypervisor.

Progress Status

• Code committed
• Testing - QA
• Documentation (Release notes - resolved issues, compatibility, known issues)