Comment 5 for bug 1670628

Not sure if this is the same issue but you can reproduce this by simply restarting nova-compute. With a DevStack-based deployment, run:

  $ sudo service <email address hidden> restart

This will result in the following ovs-related logs in journalctl:

  $ journalctl -a /usr/sbin/ovs-vswitchd /usr/bin/ovs-vsctl -a --follow
  Mar 05 14:01:12 localhost.localdomain ovs-vsctl[11616]: ovs|00001|vsctl|INFO|Called as ovs-vsctl -- --may-exist add-br br-int -- set Bridge br-int datapath_type=netdev
  Mar 05 14:01:12 localhost.localdomain ovs-vsctl[11617]: ovs|00001|vsctl|INFO|Called as ovs-vsctl --timeout=120 -- --if-exists del-port vhu81f803a2-ac -- add-port br-int vhu81f803a2-ac -- set Interface vhu81f803a2-ac external-ids:iface-id=81f803a2-ac81-4ee8-ba72-93f1e45a546c external-ids:iface-status=active external-ids:attached-mac=fa:16:3e:a8:08:98 external-ids:vm-uuid=67bb2da9-5e5d-48c5-9e98-84fb26bfb362 type=dpdkvhostuserclient options:vhost-server-path=/var/run/openvswitch/vhu81f803a2-ac

IIRC, with dpdkvhostuser interfaces (as opposed to dpdkvhostuserclient), the OVS instance acts as the server. As a result, removing and re-adding the instance results in a loss of connectivity. This doesn't happen with dpdkvhostuserclient because QEMU is the server. As a result, this seems like something we should not be doing.

*However*, there is another issue: we do things this way because of bug #1270973 (and related bug #1268762). This behavior was introduced in https://github.com/openstack/nova/commit/33cc64fb817. I'm not entirely sure that the issue that describes is valid one as it seems like a bug with OVS (otherwise what's the point of the '--may-exist' flag?). However, I need to examine this to figure out what's happening.