[libvirt] [RFC Incomplete Patch] Libvirt + Openvswitch

[kmestery]

On Jan 27, 2012, at 2:55 PM, Laine Stump wrote:
> On 01/27/2012 02:22 PM, kmestery wrote:
>> Hi Dan:
>> 
>> We at Cisco have been looking at this as well, and in fact were going to propose some things in this area as well. Our proposal (which frankly just builds on top of what you have):
>> 
>> The proposal at hand is to add some libvirt configuration as follows:
>> 
>> <network>
>>    <name>ovs-network</name>
>>    <forward mode='ovs' dev='br0'>
> 
> Nice!
> 
> It might be good to settle on a common nomenclature for openvswitch between the network code and interface code. I think I might lean more towards your "openvswitch" than Dan's "ovs", just because it's immediately more obvious to someone who doesn't know what they're looking for.
> 
I agree, using openvswitch makes sense and is more obvious.

> Rather than using the dev attribute, I think it would be more appropriate to use the separate <bridge name='xxx'
> 
> 
> <bridge name='br0'/>
> 
> The dev attribute currently has two uses (depending on forward mode) - 1) for virtual networks it indicates which device must be used for all traffic from this network as an egress from the host, and 2) for macvtap modes, it indicates both which interface the guest should connect to, AND which device to use for egress from the host (since both are the same).
> 
> As far as I understand it, the openvswitch model is more like our bridge mode, where <bridge name='xx'/> is used to indicate which device the guest's tap interfaces should connect to.
> 
> 
> One advantage of this other than consistency, is that this way a management application that didn't understand the ovs forwarding mode would still properly understand that guests using this network would have their interfaces connected to br0.
> 
This all makes sense, thanks for the detailed explanation Laine!

> Alternately, since the openvswitch is presumably equivalent to a bridge, you could follow the method networks that use host bridges and macvtap in "bridge" mode - they both use <forward mode='bridge'>, but are differentiated by whether or not they have a <bridge name='xxx'/> element, or a dev='xx' attribute. Possibly the forward mode would still be bridge, and a separate "<openvswitch name='br0'/> (or something like that) could be used, or maybe mode could remain "bridge", and the <bridge> element could get a new attribute, e.g.:
> 
> <bridge name='br0' type='openvswitch'/>
> 
> Actually I think I like this best, because someone looking at the reduced set of attributes would still get all the useful info they needed: 1) it is a bridged connection to the rest of the network (rather than routed) and 2) the device used is br0.
> 
This makes sense.
> 
>>    <script path='/etc/qemu-ifup-ovs'/>
> 
> What do you need the script for? ifup scripts bring up security questions, are currently only permitted with qemu domains for "generic ethernet" interfaces (which are really there just as a way to make *something* work when one of the existing supported types doesn't work), and result in the domain being marked as "tainted".
> 
> The preferred method is to put whatever functionality is needed directly into libvirt.
> 
Agreed, we can remove this and add the functionality needed into libvirt.

>>    </forward>
>> </network>
>> 
>> This would setup the OVS network entity, and sets up a forwarding mode of "ovs", which indicates Open vSwitch is used to forward traffic.
>> 
>> <interface type='network'>
>>    <source network='ovs-network'/>
>>    <virtualport type='openvswitch'>
>>        <parameters interfaceid="interface-xyz"/>
>>    </virtualport>
> 
> I like this re-used of virtualport, rather than defining a new element.
> 
>> </interface>
>> 
>> This model of exposing parameters to virtualport types allows for further expansion as new interface types and parameters are added.
>> 
>> Thoughts?
> 
> Uh, "how about some patches?" :-) This all seems to be coming together rather nicely.


Lets see what Dan says. I can rework his patch to accommodate the above if he is ok with it.

Thanks!
Kyle