[Top][All Lists]

[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: Wed, 27 Jun 2012 12:37:27 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

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 <->

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

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.


reply via email to

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