On Wed, May 31, 2017 at 09:30:43AM +0800, fukaige wrote: > Start a virtual machine with its backend tap device attached to a brought up > linux bridge. > If we delete the linux bridge when vm is still running, we'll get the > following error when > trying to create a ovs bridge with the same name. > > The reason is that ovs-router subsystem add the linux bridge into > netdev_shash, but does > not remove it when the bridge is deleted in the situation. When the bridge is > deleted, ovs > will receive a RTM_DELLINK msg, take this chance to remove the bridge in > netdev_shash. > > ovs-vsctl: Error detected while setting up 'br-eth'. See ovs-vswitchd log > for details. > > ovs-vswitchd log: > 2017-05-11T03:45:25.293Z|00026|ofproto_dpif|INFO|system@ovs-system: Datapath > supports recirculation > 2017-05-11T03:45:25.293Z|00027|ofproto_dpif|INFO|system@ovs-system: MPLS > label stack length probed as 1 > 2017-05-11T03:45:25.293Z|00028|ofproto_dpif|INFO|system@ovs-system: Datapath > supports unique flow ids > 2017-05-11T03:45:25.293Z|00029|ofproto_dpif|INFO|system@ovs-system: Datapath > supports ct_state > 2017-05-11T03:45:25.293Z|00030|ofproto_dpif|INFO|system@ovs-system: Datapath > supports ct_zone > 2017-05-11T03:45:25.293Z|00031|ofproto_dpif|INFO|system@ovs-system: Datapath > supports ct_mark > 2017-05-11T03:45:25.293Z|00032|ofproto_dpif|INFO|system@ovs-system: Datapath > supports ct_label > 2017-05-11T03:45:25.364Z|00001|ofproto_dpif_upcall(handler226)|INFO|received > packet on unassociated datapath port 0 > 2017-05-11T03:45:25.368Z|00033|netdev_linux|WARN|ethtool command > ETHTOOL_GFLAGS on network device br-eth failed: No such device > 2017-05-11T03:45:25.368Z|00034|dpif|WARN|system@ovs-system: failed to add > br-eth as port: No such device > 2017-05-11T03:45:25.368Z|00035|bridge|INFO|bridge br-eth: using datapath ID > 00002a51cf9f2841 > 2017-05-11T03:45:25.368Z|00036|connmgr|INFO|br-eth: added service controller > "punix:/var/run/openvswitch/br-eth.mgmt" > > Change-Id: Ib5ead59bc91453f83549da89937c0d3607e0385e > Signed-off-by: fukaige <fuka...@huawei.com>
Thanks for identifying the problem and coming up with a fix. The fix looks to me like it works at the wrong level of abstraction. netdev-linux and tnl-port-map are not directly related, and I believe that the same problem could arise with other kinds of netdevs and tnl-port-map. So, I think that it would be better if tnl-ports itself registered a callback upon device destruction, for example via a call to if_notifier_create() from tnl_port_map_init(). Thanks, Ben. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
