[libvirt] [RFC Incomplete Patch] Libvirt + Openvswitch

[Laine Stump]

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.

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.

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.


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

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