I don’t have the exact steps offhand, but you should be able to create a veth pair manually, attach one end to your existing bridge, and specify the other end in the bridge_mappings section. Make sure you set both ends up using ‘ip link set <dev> up’ prior to this. The veth pair will end up linking the bridges together.
Nova/Neutron should still handle putting the tap interface of the instance in the bridge, even if bridge_mappings is wrong or not working. The port’s device owner is compute:nova, which likely explains the message you saw in the log. Hope that helps! James From: Paul Dekkers <[email protected]> Date: Tuesday, August 16, 2016 at 12:18 PM To: George Paraskevas <[email protected]>, openstack-operators <[email protected]> Subject: Re: [Openstack-operators] neutron flat network on existing bridge fails Hi, Thanks for your suggestion - I don't think that's it, because that gives me: Unable to add br224 to brqf709c220-fd! Exception: Exit code: 1; Stdin: ; Stdout: ; Stderr: device br224 is a bridge device itself; can't enslave a bridge device to a bridge device. and Skip adding device tapf99013c6-6b to brqf709c220-fd. It is owned by compute:nova and thus added elsewhere. _add_tap_interface /usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py:473 while this tapf99013c6-6b now actually is enslaved to brqf709c220-fd, even with the wrong physical_interface_mappings setting. So I guess it's ignored because of the error, or some other code built that bridge (nova? as it's owned by compute:nova ? I had no idea a bridge/interface could have an owner...) Regards, Paul On 16-08-16 17:39, George Paraskevas wrote: Hello, With Linux bridge, I believe you should use physical _interface_mappings =provider:br224 Beat regards George On Tue, 16 Aug 2016, 16:48 Paul Dekkers, <[email protected]<mailto:[email protected]>> wrote: Hi, I'm using Ubuntu 16.04.1 with it's Mitaka release, and neutron flat networking with linuxbridge+ml2: I'd like to attach my flat neutron network to an existing linuxbridge on my system. This fails with an error like: 2016-08-16 15:07:00.711 7982 DEBUG neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [req-720266dc-fe8d-47c4-a7df-19fee7a8d679 - - - - -] Skip adding device tapf99013c6-6b to br224. It is owned by compute:nova and thus added elsewhere. _add_tap_interface /usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py:473 with the result that the tap interface is added to a newly created bridge instead of the existing (br224) bridge. I've set bridge_mappings = provider:br224 in /etc/neutron/plugins/ml2/linuxbridge_agent.ini (because if I use physical_interface_mappings = provider:vlan224 the vlan224 interface is actually detached from the original bridge) I've created the bridge via /etc/network/interfaces: auto br224 iface br224 inet manual bridge_ports vlan224 auto vlan224 iface vlan224 inet manual vlan_raw_device eno1 Reason for doing this is that I'd like to attach an lxc container to this bridge (and only when neutron needs it the "brqf709c220-fd" (with for me an unpredictable name) is setup, so I can't use that), and/or like to have the machine itself use an interface on this network. (This is also my reason for using flat networking, and not vlan.) I've created the neutron networks with neutron net-create default --shared --provider:physical_network provider --provider:network_type flat (I would repeat this with a different physical_network name if I need more VLANs, instead of using the --provider:segmentation_id.) Instance networking works when I let nova/neutron create the bridge interfaces. Any idea why neutron refuses to use the bridge_mappings and why it creates a new interface? Regards, Paul P.S. To me it feels like this is what people would need when setting up a small single-network setup (both for instances and OpenStack), but most examples use multiple networks anyway. _______________________________________________ OpenStack-operators mailing list [email protected]<mailto:[email protected]> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
