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.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list