Open Stack

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>