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

[Stefan Hajnoczi]

On Wed, Jun 27, 2012 at 7:37 PM, Mike Lovell <address@hidden> wrote:
> On 06/27/2012 02:26 AM, Stefan Hajnoczi wrote:
>>
>> On Tue, Jun 26, 2012 at 5:48 PM, Mike Lovell <address@hidden> wrote:
>>>
>>> you can connect multiple guests to a single vde_switch. as i understand
>>> it,
>>> the communication happens over a local unix domain socket. this would
>>> limit
>>> the guests on the same switch to the same host. so if you want guests on
>>> multiple hosts to talk using vde, i think you need a vde_switch on each
>>> host
>>> and then connect the vde_switch processes.
>>
>> It can be done with socat or netcat (unix_domain_socket_a <-> TCP <->
>> unix_domain_socket_b):
>> http://www.dest-unreach.org/socat/doc/socat.html
>>
>> Another idea is to take the QDES code and turn it into a freestanding
>> program that speaks the net/socket.c protocol.  That way it works with
>> existing QEMUs: launch the qdes daemon, then launch qemu -netdev
>> socket,connect=qdes-host:qdes-port.
>
>
> okay. so yes that would be possible. its complicated by the fact that there
> are multiple unix domain sockets used between a vde client application (like
> QEMU) and the vde_switch process and some of these are dynamically created.
> clients connect to a control socket for the switch, negotiate the creation
> of a new unix socket, and then pass traffic over the new socket. whatever is
> starting the vde_switches and the qemu guests will have to be aware of this
> and connect them.
>
> this goes back to one of my original points. setting this up on multiple
> physical hosts is more complex than QDES is. with QDES, you just need to
> specify a ip and port on the physical host that is unique to each process as
> well as specify a multicast ip and port thats the same for all. no figuring
> out where the other virtual machines are running, spawning additional
> processes, and connecting all of those processes together. (i hope to
> eventually remove the need to specify the local address and port)
>
> also, connecting multiple guests on multiple hosts to a single vde_switch
> instance results in a sub-optimal traffic flow. traffic from a guest on one
> host will have to go to the host running the vde_switch and then to the host
> with the destination guest. with QDES, the traffic goes directly to the host
> running the destination guest.
>
> i actually did my initial prototyping of QDES using an external python app
> that talks to QEMU using the socket network backend. i used the udp one
> instead of connect but it still worked. some of the future work i intend to
> do is to have a few external applications that can talk to other QDES as
> well. i want to do one that can forward packets between a tap device and
> other QEMU processes so that regular systems can talk to the QEMU virtual
> machines. doing another that talks to the QEMU sockets backend would be
> possible as well. i do think there is some value in having it built into
> QEMU in the ease of use.

QEMU has socket and vde, both of which are not used a huge amount.
That's why I've been prodding on the difference between vde and QDES.
Using a multicast socket to efficiently broadcast is cool and I'm not
sure if vde can do that.  If it can't then adding that to vde would be
nicer than adding a whole new custom backend to QEMU.

Stefan