yahoo-eng-team team mailing list archive

[Liaz Kamper <liaz@xxxxxxxxxxxxxxx>]

Public bug reported:

When live-migrating a VM the QEMU send 5 RARP packets in order to allow re-learning of the new location of the VM's MAC address.
However the VIF creation scheme between nova-compute and neutron-ovs-agent drops these RARPs:
1. nova creates a port on OVS but without the internal tagging. 
2. At this stage all the packets that come out from the VM, or QEMU process it runs in, will be dropped.
3. The QEMU sends five RARP packets in order to allow MAC learning. These packets are dropped as described in #2.
4. In the meanwhile neutron-ovs-agent loops every POLLING_INTERVAL and scans for new ports. Once it detects a new port is added. it will read the properties of the new port, and assign the correct internal tag, that will allow connection of the VM.

The flow above suggests that:
1. RARP packets are dropped, so MAC learning takes much longer and depends on internal traffic and advertising by the VM.
2. VM is disconnected from the network for a mean period of POLLING_INTERVAL/2

Seems like this could be solved by direct messages between nova vif
driver and neutron-ovs-agent

** Affects: neutron
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1414559

Title:
  OVS drops RARP packets by QEMU upon live-migration - VM temporarily
  disconnected

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  When live-migrating a VM the QEMU send 5 RARP packets in order to allow re-learning of the new location of the VM's MAC address.
  However the VIF creation scheme between nova-compute and neutron-ovs-agent drops these RARPs:
  1. nova creates a port on OVS but without the internal tagging. 
  2. At this stage all the packets that come out from the VM, or QEMU process it runs in, will be dropped.
  3. The QEMU sends five RARP packets in order to allow MAC learning. These packets are dropped as described in #2.
  4. In the meanwhile neutron-ovs-agent loops every POLLING_INTERVAL and scans for new ports. Once it detects a new port is added. it will read the properties of the new port, and assign the correct internal tag, that will allow connection of the VM.

  The flow above suggests that:
  1. RARP packets are dropped, so MAC learning takes much longer and depends on internal traffic and advertising by the VM.
  2. VM is disconnected from the network for a mean period of POLLING_INTERVAL/2

  Seems like this could be solved by direct messages between nova vif
  driver and neutron-ovs-agent

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1414559/+subscriptions