[libvirt] [RFC Incomplete Patch] Libvirt + Openvswitch

[Ansis Atteka]

Libvirt has a function virNetDevBridgeRemovePort() which can
remove port from the Linux Bridge, but it seems that no one calls it.

Wanted to confirm if port removal happens automatically for Linux
Bridges if VM goes down? The difference between OVS and
Linux Bridge is that OVS will need a hook that removes all ports on
VM shutdown event (and maybe also for some other events?).

Thanks,
Ansis


On Tue, Jan 31, 2012 at 9:26 PM, Laine Stump <laine at laine.org> wrote:

> On 01/31/2012 06:57 AM, Daniel P. Berrange wrote:
>
>> On Fri, Jan 27, 2012 at 02:58:58AM -0800, 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<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>
>>>
>> IMHO we should not be introducing a new "type" for OpenVSwitch. Contrary
>> to common understanding, type='bridge' is not referring explicitly to
>> Linux software bridging. Rather it refers to the concept of bridging the
>> guest to the LAN at the network level, of which Linux software briding
>> is one possible impl. OpenVSwitch is another possible impl. Other
>> hypervisors
>> have different impls too of course.
>>
>> If OpenVSwitch is available in the kernel, is there really any reason
>> to *not* use it ?  ie, could we just have
>>
>>     <interface type="bridge">
>>       <source bridge="br0"/>
>>       <mac address="ca:fe:de;ad:be:ef"/>
>>     </interface>
>>
>> and if we see that 'br0' is using OpenVSwitch, then libvirt can know
>> to just do the right thing.
>>
>
> Of course! <facepalm/> If the code can tell that br0 is an openvswitch
> bridge rather than a linux host bridge, we don't even have to add
> type='openvswitch' to the <source> element!
>
> I definitely like this the best, too.
>
>
>
>  That way every application that uses
>> libvirt today will automatically be able to take advantage of the
>> benefits OpenVSwitch brings without further work
>>
>
> Except that an interfaceid is needed (or is that optional?)
>
>
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/**mailman/listinfo/libvir-list<https://www.redhat.com/mailman/listinfo/libvir-list>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120202/2b4f8167/attachment-0001.htm>