secgroup.commit dispatches update_sg network driver twice for a single call — second dispatch crashes with "Chain already exists" (7.2.0)

Product Support Operations
1

Please, describe the problem here and provide additional information below (if applicable):

We have VMs each with their own individual security group attached. Adding the first firewall rule to a VM works correctly — the security group updates and applies cleanly. From the second rule onward, adding any further rule fails: OpenNebula’s oned.log shows the network driver (update_sg) being called twice for the same VM in quick succession (about 1 second apart) from what we’ve confirmed is a single secgroup.commit call. The first call succeeds, the second fails with iptables: Chain already exists, and after this failure the VM is left with no firewall enforcement at all — the iptables chain never gets rebuilt, so the VM ends up fully open rather than just missing the new rule.
Important: when we perform the equivalent operation manually through Sunstone (detaching/attaching or editing the security group’s rules directly in the UI, with the natural pause between clicks that comes from doing it by hand), it works correctly every time — no crash, no double dispatch. The failure only shows up when the same operation is triggered via the API in quick succession (our application calling secgroup.update immediately followed by secgroup.commit). This suggests the issue is specifically related to how fast these two API calls happen one after another, rather than a problem with the underlying security group mechanism itself.

We’re also unsure whether we’re using secgroup.update and secgroup.commit correctly. The API docs describe commit as “intended for retrying updates of VMs or reinitializing” — we’re calling update followed by commit on every rule change, and want to confirm whether that’s the right pattern, or whether there’s a different/lighter call meant for applying a live rule change (with commit reserved only for retries/reinit).

Versions of the related components and OS (frontend, hypervisors, VMs):

  • OpenNebula 7.2.0 (frontend and hypervisor)
  • KVM, bare-metal hypervisor
  • Host iptables v1.8.7 (nf_tables backend), iptables-legacy tables also present

Steps to reproduce:

  1. Create a VM with its own individual security group, add one inbound rule (e.g. port 22) — works fine.
  2. Add a second inbound rule (e.g. port 80) to the same security group, using secgroup.update followed by secgroup.commit.
  3. Check oned.log and the VM’s driver log during this second addition.

Current results:
Adding the first rule works. Adding any rule after that fails — oned.log shows one secgroup.update + one secgroup.commit call, but the driver gets dispatched twice, and the second dispatch crashes with Chain already exists. After this, the VM has no active iptables chain at all and is fully open, even though the API reports success.

Expected results:
Adding a rule after the first one should behave the same as adding the first rule — a single clean driver dispatch, with the VM’s firewall correctly updated to reflect all current rules. We’d also appreciate clarification on whether update + commit is the correct call pattern for applying a live rule change, versus using commit only for retry/reinit scenarios.

2

Hello,

Thank you for reporting this issue. We have reproduced the behavior and forwarded our findings to the development team for investigation and a fix.

In the meantime, please avoid calling one.secgroup.commit immediately after one.secgroup.update, as the update operation already propagates the Security Group changes to the associated VMs.