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