Iptables chain removed when detaching nic
|Assignee:||Jaime Melis||% Done:|
|Category:||Drivers - Network|
|Target version:||Release 4.14|
|Affected Versions:||OpenNebula 4.12|
To re-create the issue:
1. Instantiate a vm (1 NIC) => secgroup will be populated under iptables, the chains of one-<vmid>-0-i and one-<vmid>-0-o will be created.
2. Add a additional NIC to the vm => chains for the new NIC is created, one-<vmid>-1-i and one-<vmid>-1-o
3. Remove any single of those NIC => this is where the issue occur, both chains will be deleted.
#4 Updated by Sébastien LEFEUVRE about 6 years ago
Sébastien LEFEUVRE wrote:
I attach below the files updated that fix the bug of attach/detach NIC for each VMs using OpenVswitch Driver refer to https://forum.opennebula.org/t/how-to-manage-openvswitch-flows-with-opennebula/701.
#5 Updated by Jaime Melis about 6 years ago
- Status changed from Pending to Closed
- Resolution set to fixed
Hi Sebastian, thank you for your patch. We believe that it has been solved in a slighty less intrusive way in the commit dc318dd0. As far as I can tell the final behaviour would be the same both with your path and with the commit dc318dd0. The main difference is:
- [your patch] => the ruby driver (one_vmm_exec.rb) detects what the currently ATTACH=YES nic is, and passes it as an argument to the networking drivers (OpenvSwitch.rb)
- [dc318dd0] => as the VM XML is already available inside the networking drivers, we can directly check if ATTACH=YES is present in one interface. If it is, we just process that interface, otherwise, we process all. In addition this commit fixes all the other drivers besides OpenvSwitch.rb
We will keep patch dc318dd0 for simplicity (hope you agree), but thanks a lot for your contribution :)