Bug #5010

network traffic leaks during VM live-migration when using openvswitch driver

Added by Stefan Kooman over 4 years ago. Updated over 3 years ago.

Status:PendingStart date:02/07/2017
Priority:NormalDue date:
Assignee:-% Done:


Target version:-
Resolution: Pull request:
Affected Versions:OpenNebula 4.10, OpenNebula 4.12, OpenNebula 4.14, OpenNebula 5.0, OpenNebula 5.2


OpenNebula handles the tagging of network adapters of virtual machines. This tagging is done through the drivers. Depending on settings in the OpenNebulaNetwork.conf / VNET options some openflows are added as well (arp cache poisoning prevention). When a VM gets migrated there are seperate scripts for doing the live-migrate and the tagging of the ports. When a VM goes from "paused" to running state the live-migrate is finished and the network port is active. At that point in time the vnet is untagged. By default any openvswitch port which is added to a bridge will receive all traffic. The now untagged port receives traffic from all other vlans on this bridge. A few moments later (~ seconds) the port gets tagged by the "post" operation of the ovswitch driver. In this (brief) moment in between, traffic leaks to this untagged vnet which is highly undesirable. For example IPv6 router advertisements have been applied by VM's in a complete different network bricking their IPv6 configuration. Sensitive payloads may be sniffed, etc.


#1 Updated by Stefan Kooman over 4 years ago

One possible way to fix this would be to apply the tagging of the vnets in the XML that gets used by libvirt (virsh), i.e.

instead of this operation by ovswitch driver:

ovs-vsctl set Port vnet15 tag=143

this XML in the VM template:

<interface type='bridge'>
<virtualport type='openvswitch'/>
<source bridge='uplink'/>
<tag id='143'/>
<mac address='de:ad:be:ee:ee:ff'/>
<model type='virtio'/>

When the VM gets live-migrated, the ports is automatically tagged on the right bridge, and vnet port would never be untagged.

#2 Updated by Stefan Kooman over 3 years ago

OpenNebula 5.6 is about improving "Quality of life" ... in that case, I would like to bump this issue as candidate :-). I've talked about this with Javi Fontan during EU conf 2017. He explained me that ONE tries to split actions into seperate drivers (storage, network, etc.). Sometimes howerver (for example with Ceph / rbd) this is not possible. The info needs to be in the libvirt XML itself. For (openvswitch) networking this also seems to be the case.

Relates to #5503 and #5504

Also available in: Atom PDF