On Wed, Jun 27, 2012 at 7:37 PM, Mike Lovell <m...@dev-zero.net> wrote: > On 06/27/2012 02:26 AM, Stefan Hajnoczi wrote: >> >> On Tue, Jun 26, 2012 at 5:48 PM, Mike Lovell <m...@dev-zero.net> 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
