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.
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 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 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-93f1e45a54 6c external- ids:iface- status= active external- ids:attached- mac=fa: 16:3e:a8: 08:98 external- ids:vm- uuid=67bb2da9- 5e5d-48c5- 9e98-84fb26bfb3 62 type=dpdkvhostu serclient options: vhost-server- path=/var/ run/openvswitch /vhu81f803a2- ac
Mar 05 14:01:12 localhost.
Mar 05 14:01:12 localhost.
IIRC, with dpdkvhostuser interfaces (as opposed to dpdkvhostusercl ient), 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.