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: Mike Lovell
Subject: Re: [Qemu-devel] net: RFC New Socket-Based, Switched Network Backend (QDES)
Date: Mon, 25 Jun 2012 10:32:38 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

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.

QDES is able to send traffic directly to the correct destination because it isn't using something like STP. Connecting it to a regular 802.1D switching network would probably result in bad things. There aren't loops in QDES because individual packets only flow one way through it. Packets received from the sockets aren't sent back out the sockets.

I hope that makes sense.

mike



reply via email to

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