yahoo-eng-team team mailing list archive

[OpenStack Infra <1414559@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/246898
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=b7c303ee0a16a05c1fdb476dc7f4c7ca623a3f58
Submitter: Jenkins
Branch:    master

commit b7c303ee0a16a05c1fdb476dc7f4c7ca623a3f58
Author: Oleg Bondarev <obondarev@xxxxxxxxxxxx>
Date:   Wed Nov 18 12:15:09 2015 +0300

    Notify nova with network-vif-plugged in case of live migration
    
     - during live migration on pre migration step nova plugs instance
       vif device on the destination compute node;
     - L2 agent on destination host detects new device and requests device
       info from server;
     - server does not change port status since port is bound to another
       host (source host);
     - L2 agent processes device and sends update_device_up to server;
     - again server does not update status as port is bound to another host;
    
    Nova notifications are sent only in case port status change so in this case
    no notifications are sent.
    
    The fix is to explicitly notify nova if agent reports device up from a host
    other than port's current host.
    
    This is the fix on neutron side, the actual fix of the bug is on nova side:
    change-id Ib1cb9c2f6eb2f5ce6280c685ae44a691665b4e98
    
    Closes-Bug: #1414559
    Change-Id: Ifa919a9076a3cc2696688af3feadf8d7fa9e6fc2


** Changed in: neutron
       Status: In Progress => Fix Released

-- 
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 neutron:
  Fix Released
Status in OpenStack Compute (nova):
  In Progress

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