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'>
<script path='/etc/qemu-ifup-ovs'/>
</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>
</interface>
This model of exposing parameters to virtualport types allows for further expansion as new interface types and parameters are added.
Thoughts?
Thanks,
Kyle
On Jan 27, 2012, at 4:58 AM, Dan Wendlandt wrote:
>
> Hello all,
>
> I know of many people who want to spin up VMs using libvirt + kvm/qemu and attach those VMs to an openvswitch bridge (see: http://www.openvswitch.org). However, the only way I know of to get this working is a kludge that uses to tap devices along with <interface type="ethernet"> while running ovs-vsctl outside of libvirt. Even worse, doing this on RHEL/Fedora seems to require privilege tweaks (e.g., running qemu as root, not dropping capabilities), which may not be acceptable for production deployments (see: http://fedoraproject.org/wiki/How_to_debug_Virtualization_problems#Errors_using_.3Cinterface_type.3D.27ethernet.27.2F.3E ).
>
> So I would like to start taking steps toward better libvirt/openvswitch integration. My initial step has the fairly limit goal of enabling kvm/qemu VM NICs to attach to an openvswitch bridge in much the same way VM NIC can already attached to the linux bridge. For example, specifying:
>
> <interface type="openvswitch">
> <source bridge="br0"/>
> <mac address="ca:fe:de;ad:be:ef"/>
> </interface>
>
> I also wanted to add a new child element of <interface> that can be used to specify some OVS specific configuration. To start, I just want to expose a single 'interfaceid' value (this parameter is specific to openvswitch). Extending the previous example:
>
> <interface type="openvswitch">
> <source bridge="br0"/>
> <mac address="ca:fe:de;ad:be:ef"/>
> <openvswitchport interfaceid="interface-xyz"/>
> </interface>
>
> For this first step (see attached patch), I am only targeting the model where the OVS bridge has been created externally ahead of time. I am not tackling any of the "network" logic that actually creates/destroys bridges, as it is not needed for my target use case.
>
> A couple notes about the attached patch:
> - I haven't actually run this code. I was just poking around the libvirt code to learn about it and figured that a diff was the most concrete way to propose what I was thinking of doing. I would be curious for pointers about big chunks of work that I may have missed (for example, I haven't added any tests yet).
> - the code was modeled on the network interface "bandwidth" code, that calls out to 'tc' to configure bandwidth rates. Ideally we would be able to make direct C calls to OVS (and we plan to make that possible in the future), but calling an external utility right now is the only viable path.
> - no attention was paid to style guidelines. Will do that before any real submission.
> - I wasn't very clear on the notion of an "actual" net def, as opposed to a normal net def. What's the best place to look for documentation on this?
>
> Anyway, I'm primarily looking for feedback about whether I'm barking up the right tree before I spend time debugging or polishing the patch, so I would appreciate thoughts, advice, etc. Thanks,
>
> Dan
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list