Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security groups not updated after VM powered off #6299

Closed
2 of 3 tasks
brodriguez-opennebula opened this issue Aug 17, 2023 · 1 comment
Closed
2 of 3 tasks

Security groups not updated after VM powered off #6299

brodriguez-opennebula opened this issue Aug 17, 2023 · 1 comment

Comments

@brodriguez-opennebula
Copy link
Contributor

brodriguez-opennebula commented Aug 17, 2023

Description
There is a race condition where, if a VM is powered off, its SG rules may not be flushed in time. This may lead to the following type of errors

sudo -n ipset destroy one-VM_ID-NIC_ID-SG_NAME

To Reproduce

The following procedure is not deterministic, relies on the poweroff time of the VM

  • Create a VM with at least a NIC
  • Set up a SG in the VM NIC
  • Power off the VM

Expected behavior

  • The VM should be turned off
  • The Security group should be disabled

Details

  • Affected Component: Security Groups (networking)
  • Hypervisor: KVM
  • Version: 6.6.3

Additional context
Add any other context about the problem here.

Progress Status

  • Code committed
  • Testing - QA
  • Documentation (Release notes - resolved issues, compatibility, known issues)
@tinova tinova modified the milestones: Release 6.6.4, Release 6.8 Aug 17, 2023
brodriguez-opennebula added a commit that referenced this issue Aug 17, 2023
There is a race condition where, if a VM is powered off, its SG rules may not
be flushed in time. This may lead to the following type of errors

```
sudo -n ipset destroy one-VM_ID-NIC_ID-SG_NAME
```

The timeout to flush the security group iptables has been increased to 500 ms
to prevent this problem
rsmontero pushed a commit to OpenNebula/docs that referenced this issue Sep 21, 2023
rsmontero pushed a commit that referenced this issue Sep 21, 2023
This will give kernel some more time to clean up before attemting to
destroy the associated ipsets. Otherwise it may fail with: "Set cannot be
destroyed: it is in use by a kernel component"
@rsmontero
Copy link
Member

The timeout before attempting to delete the ipset has been increased the kernel has some more margin to cleanup iptable references under heavy load

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

When branches are created from issues, their pull requests are automatically linked.

4 participants