Currently when using neutron we don't update the binding:host_id during the evacuate code path.
This can cause the evacuation to fail if we go to sleep waiting for events in virt.libvirt.driver.LibvirtDriver._create_domain_and_network(). Since the binding:host_id in neutron is still pointing to the old host, neutron will never send us any events and we will eventually time out.
I was able to get the evacuation to update the binding by modifying compute.manager.ComputeManager.rebuild_instance() to add a call to self.network_api.setup_instance_network_on_host() right below the existing call to self.network_api.setup_networks_on_host().
I'm suspicious that this might break nova-network though. It's a bit confusing, currently the networking API has three routines that seem to overlap:
setup_networks_on_host() -- this actually does setup or teardown for nova-network, and is empty for neutron
setup_instance_network_on_host() -- this maps to self._update_port_binding_for_instance() for neutron. For nova-network it maps to self.migrate_instance_finish() which is provided by FloatingIP for FlatDHCPManager and VlanManager.
cleanup_instance_network_on_host() -- this is empty for neutron. For nova-network it maps to self.migrate_instance_start which is provided by FloatingIP for FlatDHCPManager and VlanManager.
I think alex_xu added some of the migration-related network APIs in kilo so he might know more about intended usage.