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