[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] 4.3 Planning: Taking stock



> 
>       * openvswitch toostack integration
> 
> I think openvswitch is a win from a benefit/effort point of view.  It's 
> already
> got an RFC posted by Bastian to the list; and we've got some expertise on
> openvswitch in the XenServer team -- who can't write it but could maybe
> give advice / figure out bugs quicker.  If we can just get someone motivated
> enough to take it up, then we'd have a pretty good feature for not too much
> work.
> 

What are the requirements here? I just had a look at 
http://lists.xen.org/archives/html/xen-devel/2012-09/msg00943.html, is that the 
RFC script you are referring to?

What I would need is to be able to specify a vlan tag for the port too, but 
even better would be that you manually create the port outside of xen and the 
domu would plug into that port. I'm not sure if the port/interface names are 
long enough to allow this in an intuitive way though (eg to specify grokable 
port names).

The big problem I have with brctl compatibility layer is that at the moment it 
isn't working for vlan tagged virtual switches (it used to, don't know what's 
changed), and if the cleanup script doesn't get run for any reason it leaves 
stale ports around, and they collide after reboot when the same vif number is 
reused.

Also there is a qemu-ifup script that does some brctl stuff too, and also seems 
to race with the interface rename, at least under the Debian Xen 4.1 packages.

James


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.