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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
