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 <[email protected]> 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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
