Hi Simon, Thank you! One of those bugs helped me focus on an area of the (nova) code that I hadn't found my way to yet, and I was able to at least get back the functionality I had with Havana (hybrid OVS+Ethernet-Bridge model) by setting firewall_driver in nova.conf to nova.virt.libvirt.firewall.IptablesFirewallDriver instead of nova.virt.firewall.NoopFirewallDriver - now I can launch an instance with functional networking again.
I'd still like to understand how the OVS port is supposed to get setup when the non-hybrid model is used, and eliminate the ethernet bridge if possible. I'll dig into that a bit more... ~iain On Fri, Mar 14, 2014 at 3:01 AM, Simon Pasquier <simon.pasqu...@bull.net> wrote: > Hi, > > I've played a little with XenAPI + OVS. You might be interested by this > bug report [1] that describes a related problem I've seen in this > configuration. I'm not sure about Xen libvirt though. My assumption is > that the future-proof solution for using Xen with OpenStack is the > XenAPI driver but someone from Citrix (Bob?) may confirm. > > Note also that the security groups are currently broken with libvirt + > OVS. As you noted, the iptables rules are applied directly to the OVS > port thus they are not effective (see [2] for details). There's work in > progress [3][4] to fix this critical issue. As far as the XenAPI driver > is concerned, there is another bug [5] tracking the lack of support for > security groups which should be addressed by the OVS firewall driver [6]. > > HTH, > > Simon > > [1] https://bugs.launchpad.net/neutron/+bug/1268955 > [2] https://bugs.launchpad.net/nova/+bug/1112912 > [3] https://review.openstack.org/21946 > [4] https://review.openstack.org/44596 > [5] https://bugs.launchpad.net/neutron/+bug/1245809 > [6] https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver > > On 13/03/2014 19:35, iain macdonnell wrote: >> I've been playing with an icehouse build grabbed from fedorapeople. My >> hypervisor platform is libvirt-xen, which I understand may be >> deprecated for icehouse(?) but I'm stuck with it for now, and I'm >> using VLAN networking. It almost works, but I have a problem with >> networking. In havana, the VIF gets placed on a legacy ethernet >> bridge, and a veth pair connects that to the OVS integration bridge. >> In understand that this was done to enable iptables filtering at the >> VIF. In icehouse, the VIF appears to get placed directly on the >> integration bridge - i.e. the libvirt XML includes something like: >> >> <interface type='bridge'> >> <mac address='fa:16:3e:e7:1e:c3'/> >> <source bridge='br-int'/> >> <script path='vif-bridge'/> >> <target dev='tap43b9d367-32'/> >> </interface> >> >> >> The problem is that the port on br-int does not have the VLAN tag. >> i.e. I'll see something like: >> >> Bridge br-int >> Port "tap43b9d367-32" >> Interface "tap43b9d367-32" >> Port "qr-cac87198-df" >> tag: 1 >> Interface "qr-cac87198-df" >> type: internal >> Port "int-br-bond0" >> Interface "int-br-bond0" >> Port br-int >> Interface br-int >> type: internal >> Port "tapb8096c18-cf" >> tag: 1 >> Interface "tapb8096c18-cf" >> type: internal >> >> >> If I manually set the tag using 'ovs-vsctl set port tap43b9d367-32 >> tag=1', traffic starts flowing where it needs to. >> >> I've traced this back a bit through the agent code, and find that the >> bridge port is ignored by the agent because it does not have any >> "external_ids" (observed with 'ovs-vsctl list Interface'), and so the >> update process that normally sets the tag is not invoked. It appears >> that Xen is adding the port to the bridge, but nothing is updating it >> with the neutron-specific "external_ids" that the agent expects to >> see. >> >> Before I dig any further, I thought I'd ask; is this stuff supposed to >> work at this point? Is it intentional that the VIF is getting placed >> directly on the integration bridge now? Might I be missing something >> in my configuration? >> >> FWIW, I've tried the ML2 plugin as well as the legacy OVS one, with >> the same result. >> >> TIA, >> >> ~iain >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev