qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] net: RFC New Socket-Based, Switched Network Backend (QD


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] net: RFC New Socket-Based, Switched Network Backend (QDES)
Date: Tue, 26 Jun 2012 09:29:49 +0100

On Mon, Jun 25, 2012 at 5:32 PM, Mike Lovell <address@hidden> wrote:
> On 06/25/2012 09:33 AM, Mike Lovell wrote:
>>
>> On 06/25/2012 04:40 AM, Stefan Hajnoczi wrote:
>>>
>>> Have you looked at QEMU's net/vde.c backend?
>>>
>>> Does VDE (http://vde.sourceforge.net/) already do everything that QDES
>>> does?
>>>
>>> Stefan
>>
>>
>> I have looked at VDE and used it for a few things. I think QDES has an
>> advantage over VDE in that it doesn't require additional steps to get up and
>> running. With VDE, one has to at least start a vde_switch process on the
>> host for the guest to connect to. Then, if multiple hosts are being used,
>> the multiple vde_switch processes have to be connected. Maybe through some
>> vde_plug processes connected through netcat or ssh. Its a few extra steps
>> that can be a pain in a dynamic environment. With QDES, the only
>> configuration should be the options to QEMU as long as the multiple hosts
>> can send and receive data through the same multicast address.
>>
>> QDES doesn't have anywhere close to the feature set that VDE does. This
>> doesn't do VLANs at the switching level. It doesn't support STP so
>> connecting it to other bridges might cause weird behavior. Etc. But it does
>> provide a really easy way for multiple guests on multiple hosts to be
>> connected.
>
>
> Oh. I forgot another reason why I decided to do this over using VDE. I'll do
> this one with an example. Say you have 3 virtual machines on 3 different
> hosts. Each host has a vde_switch process running, Switch A, B, and C. Each
> vde_switch has connections to the other 2 through some vde_plug's and
> netcat. In this case, VDE will disable one of the links between switches to
> prevent loops, say the link between Switch A and C. Traffic from the VM
> connected to Switch C that is destined for the VM on Switch A will have to
> traverse through Switch B. This is a suboptimal traffic flow. Especially
> when you consider that the traffic has to flow through 3 to 4 additional
> processes on each host for each direction.

I haven't tried VDE myself but this sounds odd.  Why can't you run a
single vde_switch instance and connect multiple guests to it (with
netcat)?

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]