Open Stack

On Fri, Mar 14, 2014 at 11:01:36AM +0100, Simon Pasquier 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.

It is not that simple. XenAPI is the management interface provided by
the commercial XenServer products. The libvirt driver targets libxl or
XenD which are the interfaces provided by the open source Xen community
project. So the Xen platform you have chosen to run, directly determines
what Nova driver you must then run to manage it.

> 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

The libvirt Xen driver in Nova is marked as group C deprecated due to
the lack of any automated testing in the jenkins gate. 99% of its code
is shared with the other livirt drivers, so you can infer some level
of quality from that, but this of course makes an assumuption about
the underling libvirt Xen driver's level of testing. In short we're
looking for people who are interested in libvirt Xen to step forward
and provide systems doing automated testing to validate this setup.

> > 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.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|