# secgroup.commit dispatches update\_sg network driver twice for a single call — second dispatch crashes with "Chain already exists" (7.2.0) **URL:** \ **Category:** Operations\ **Created:** [September 23, 2026, 11:50am UTC](https://forum.opennebula.io/t/secgroup-commit-dispatches-update-sg-network-driver-twice-for-a-single-call-second-dispatch-crashes-with-chain-already-exists-7-2-0/14586 "2026-09-23T11:50:03Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Mukul\_Patel](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.opennebula.io/mukul_patel/32/9057_2.png) [@Mukul\_Patel](https://forum.opennebula.io/u/Mukul_Patel)\ **Post date:** [September 23, 2026, 11:50am UTC](https://forum.opennebula.io/t/secgroup-commit-dispatches-update-sg-network-driver-twice-for-a-single-call-second-dispatch-crashes-with-chain-already-exists-7-2-0/14586/1 "2026-09-23T11:50:03Z")
**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. ---
**Author:** ![fpolanco-one](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.opennebula.io/fpolanco-one/32/8963_2.png) [@fpolanco-one](https://forum.opennebula.io/u/fpolanco-one)\ **Post date:** [September 25, 2026, 3:09pm UTC](https://forum.opennebula.io/t/secgroup-commit-dispatches-update-sg-network-driver-twice-for-a-single-call-second-dispatch-crashes-with-chain-already-exists-7-2-0/14586/2 "2026-09-25T15:09:52Z")
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. ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex031/uploads/opennebula/original/2X/1/14d66f1130b9cd292905f575da9b68a9f574dd03.png) [@system](https://forum.opennebula.io/u/system)\ **Post date:** [October 25, 2026, 3:10pm UTC](https://forum.opennebula.io/t/secgroup-commit-dispatches-update-sg-network-driver-twice-for-a-single-call-second-dispatch-crashes-with-chain-already-exists-7-2-0/14586/3 "2026-10-25T15:10:08Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.