Description of problem: spawning a VM fails with Virtual Interface creation failed VM ends up in ERROR state it causes all tempest scenario tests to fail too Version-Release number of selected component (if applicable): python-neutron-11.0.2-0.20170926082939.5b0191f.el7ost.noarch python-neutron-lbaas-11.0.2-0.20170927152439.743c1db.el7ost.noarch openstack-neutron-metering-agent-11.0.2-0.20170926082939.5b0191f.el7ost.noarch python-neutronclient-6.5.0-0.20170814170137.355983d.el7ost.noarch openstack-neutron-11.0.2-0.20170926082939.5b0191f.el7ost.noarch puppet-neutron-11.3.1-0.20170923020712.889da59.el7ost.noarch python-neutron-lib-1.9.1-0.20170821170222.0ef54c3.el7ost.noarch openstack-neutron-common-11.0.2-0.20170926082939.5b0191f.el7ost.noarch openstack-neutron-ml2-11.0.2-0.20170926082939.5b0191f.el7ost.noarch openstack-neutron-openvswitch-11.0.2-0.20170926082939.5b0191f.el7ost.noarch openstack-neutron-linuxbridge-11.0.2-0.20170926082939.5b0191f.el7ost.noarch openstack-neutron-lbaas-11.0.2-0.20170927152439.743c1db.el7ost.noarch openstack-neutron-sriov-nic-agent-11.0.2-0.20170926082939.5b0191f.el7ost.noarch opendaylight-6.2.0-0.1.20171010rel2000.el7.noarch (opendaylight_api container) How reproducible: 100% Steps to Reproduce: 1. deploy Overcloud using Pike TripleO/OSPd 2. create network/subnet and spawn a VM (alternatively run any tempest scenario test, i.e.: tempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basic_ops[compute,id-7fff3fb3-91d8-4fd0-bd7d-0204f1f180ba,network,smoke] or neutron.tests.tempest.scenario.test_basic.NetworkBasicTest.test_basic_instance[id-de07fe0a-e955-449e-b48b-8641c14cd52e] 3. observe failure in VM spawning or tempest reporting failure with "Current status: BUILD. Current task state: spawning." Actual results: failure of VM/tgempest tests Expected results: success Additional info: ovsdb logs: 2017-10-11T03:16:02.640Z|44500|vlog|INFO|opened log file /var/log/openvswitch/ovsdb-server.log 2017-10-11T03:16:02.640Z|44501|socket_util|ERR|6639:127.0.0.1: bind: Permission denied audit.log type=AVC msg=audit(1507715831.683:158277): avc: denied { name_bind } for pid=48480 comm="ovsdb-server" src=6639 scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket type=SYSCALL msg=audit(1507715831.683:158277): arch=c000003e syscall=49 success=no exit=-13 a0=11 a1=7ffd5a4a0f40 a2=10 a3=7ffd5a4a0f38 items=0 ppid=1 pid=48480 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="ovsdb-server" exe="/usr/sbin/ovsdb-server" subj=system_u:system_r:openvswitch_t:s0 key=(null)
Seems related to bug1498921
The default ovsdb protocol port is 6640 [1]. What is a reason to not use the standard port number? I see bug 1498921 allowed 6639, but is it correct thing to do?
Forgot to paste link: [1] https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=101
Linke to ovsdb protocol rfc: https://tools.ietf.org/html/rfc7047#section-6
there's ODL-OVS service running on 6640 *** This bug has been marked as a duplicate of bug 1498921 ***
(In reply to Waldemar Znoinski from comment #5) > there's ODL-OVS service running on 6640 > > *** This bug has been marked as a duplicate of bug 1498921 *** I thought OVS (openflow) would be on 6633 or 6653?