Description of problem: When adding an invalid port "ovs-vsctl add-port" didn't return an error. Instead the error was found in ovs-vswitchd.log --- see below. [root@intel-s3eb1-01 openvswitch]# grep -w ovsport_3 ovs-vswitchd.log|more 2012-10-02T14:20:02Z|00117|netdev_linux|WARN|ethtool command ETHTOOL_GFLAGS on network device ovsport_3 failed: No such device 2012-10-02T14:20:02Z|00118|dpif|WARN|system@ovsbr: failed to add ovsport_3 as port: No such device 2012-10-02T14:20:02Z|00126|netdev_linux|WARN|ethtool command ETHTOOL_GFLAGS on network device ovsport_3 failed: No such device 2012-10-02T14:20:02Z|00127|dpif|WARN|system@ovsbr: failed to add ovsport_3 as port: No such device 2012-10-02T14:20:02Z|00132|netdev_linux|WARN|ethtool command ETHTOOL_GFLAGS on network device ovsport_3 failed: No such device 2012-10-02T14:26:24Z|00144|netdev_linux|WARN|ethtool command ETHTOOL_GFLAGS on network device ovsport_3 failed: No such device 2012-10-02T14:26:24Z|00145|dpif|WARN|system@ovsbr: failed to add ovsport_3 as port: No such device 2012-10-02T14:26:24Z|00154|netdev_linux|WARN|ethtool command ETHTOOL_GFLAGS on network device ovsport_3 failed: No such device 2012-10-02T14:26:24Z|00165|netdev_linux|WARN|ethtool command ETHTOOL_GFLAGS on network device ovsport_3 failed: No such device 2012-10-02T14:26:24Z|00174|netdev_linux|WARN|ethtool command ETHTOOL_GFLAGS on network device ovsport_3 failed: No such device 2012-10-02T14:26:45Z|00226|dpif|WARN|system@ovsbr: failed to add ovsport_3 as port: No such device 2012-10-02T14:29:34Z|00598|dpif|WARN|system@ovsbr: failed to add ovsport_3 as port: No such device 2012-10-02T14:33:13Z|01082|dpif|WARN|system@ovsbr: failed to add ovsport_3 as port: No such device 2012-10-02T14:33:15Z|01086|dpif|WARN|system@ovsbr: failed to add ovsport_3 as port: No such device 2012-10-02T14:37:04Z|01590|dpif|WARN|system@ovsbr: failed to add ovsport_3 as port: No such device 2012-10-02T14:52:32Z|03630|dpif|WARN|system@ovsbr: failed to add ovsport_3 as port: No such device 2012-10-02T15:07:55Z|05660|dpif|WARN|system@ovsbr: failed to add ovsport_3 as port: No such device 2012-10-02T15:21:21Z|07434|dpif|WARN|system@ovsbr: failed to add ovsport_3 as port: No such device 2012-10-02T17:01:46Z|20688|dpif|WARN|system@ovsbr: failed to add ovsport_3 as port: No such device 2012-10-02T17:07:00Z|21380|dpif|WARN|system@ovsbr: failed to add ovsport_3 as port: No such device Version-Release number of selected component (if applicable): 1.17.1 How reproducible: very re-producible Steps to Reproduce: 1.ovs-vsctl add-port ovsbridge ovsport_3, where ovsport_3 is undefined. 2.The command will not return error. 3.But, the error will be seen in /var/log/openvswitch/ovs-vswitchd.log Actual results: The "ovs-vsctl add-port" command line didn't return error Expected results: ovs-vsctl should return error. Additional info:
A similar issue was found when more than 1024 ports were added. "ovsctl add-port" didn't respond with warning or error. But, the failure messages were found in ovs-vswitchd.log: 2012-10-05T15:49:15Z|18689|dpif|WARN|system@ovsbr: failed to add ovsbrT1017 as port: Device or resource busy 2012-10-05T15:49:15Z|18690|dpif|WARN|system@ovsbr: failed to add ovsbrT1017 as port: Device or resource busy 2012-10-05T15:49:15Z|18691|dpif|WARN|system@ovsbr: failed to add ovsbrT1018 as port: Device or resource busy 2012-10-05T15:49:15Z|18692|dpif|WARN|system@ovsbr: failed to add ovsbrT1017 as port: Device or resource busy 2012-10-05T15:49:15Z|18693|dpif|WARN|system@ovsbr: failed to add ovsbrT1019 as port: Device or resource busy 2012-10-05T15:49:15Z|18694|dpif|WARN|Dropped 1 log messages in last 1 seconds (most recently, 1 seconds ago) due to excessive rate 2012-10-05T15:49:15Z|18695|dpif|WARN|system@ovsbr: failed to add ovsbrT1020 as port: Device or resource busy
I think this is not a bug. Take the example from Thomas' tutorial: ovs-vsctl -- add-port ovsbr0 vlan10 \ tag=10 -- set Interface vlan10 \ type=internal in this case, vlan10 doesn't exist before this command. And the above command equals to: ovs-vsctl add-port ovsbr0 vlan10 tag=10 ovs-vsctl set Interface vlan10 type=internal so after the first one executed, vlan10 is already added to the ovs bridge, but not to the kernel, because its type is incomplete currently: # ovs-vsctl get Interface non-exist type "" The second command just sets its type to be internal and commits it to the kernel finally. Therefore, ovs-vsctl doesn't consider this as an error, just shows some warning in the log.
^^^ should be: ovs-vsctl get Interface vlan10 type Anyway, its type is still incomplete after "ovs-vsctl add-port ovsbr0 vlan10 tag=10".
Thomas points out that when the name of the interface is invalid, for example too long, ovs-vsctl should return some error before passing it to the kernel. This makes sense.
Created attachment 632673 [details] Proposed patch After this patch: # ovs-vsctl add-port ovsbr0 12345678901234567890 ovs-vsctl: cannot create a port named 12345678901234567890 because the name is not valid # ovs-vsctl add-br 12345678901234567890 ovs-vsctl: cannot create a bridge named 12345678901234567890 because the name is not valid
I would suggest making the command more friendly by giving warnigs about potential issues. Another similar issue: When eth1 and eth0 are bonded with "lapcp=active", ovs-vsctl responded with enabled for both interfaces. But, both get disabled right away --- see below. 2012-10-16T21:43:34Z|00677|bond|INFO|interface eth0: link state down 2012-10-16T21:43:34Z|00678|bond|WARN|interface eth0: disabled 2012-10-16T21:43:34Z|00679|bond|INFO|interface eth1: link state down 2012-10-16T21:43:34Z|00680|bond|WARN|interface eth1: disabled 2012-10-16T21:45:49Z|00681|bond|WARN|interface eth0: enabled 2012-10-16T21:45:49Z|00682|bond|INFO|interface eth0: link state down 2012-10-16T21:45:49Z|00683|bond|WARN|interface eth0: disabled 2012-10-16T21:45:53Z|00684|bond|WARN|interface eth1: enabled 2012-10-16T21:45:53Z|00685|bond|INFO|interface eth1: link state down 2012-10-16T21:45:53Z|00686|bond|WARN|interface eth1: disabled
(In reply to comment #6) Jean, the bond issue should be a different one, please report a new BZ for it.
All the mentioned usability issues are due to the warnings emitted by the switching daemon not being pushed to the CLI invoking the action. There is no point in duplicating all the verification and error checking code in ovs-vsctl, instead the warnings should be reported back properly. I realize this is not trivial to the possible remote nature of ovs-vsctl but it's the only clean way to resolve this long term. I consider this more of an RFE rather than a bug though.
Hi Cong, I'll do. Thanks! Jean
Hi Thomas, I have no issue about an RFE for this issue. Thanks! Jean
*** Bug 972307 has been marked as a duplicate of this bug. ***