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

[Mike Lovell]

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.

mike