Stefan, The problem aI face is that a bridge in the middle ( using taps) breaks LLDP ( L2 discovery protocol) and should break ISIS as well. Sockets aren't bad, but if for some reason I take the listener VM down and bring back up, then I have to bring down all connector VMs, which chains on itself if there is a lot of connectivity defined. When UDP was available that wasn't an issue.
Anyway, that is how I came to VETHs. I am aware that you can use UDP multicast, but performance past one hop is extremely poor ( resulting in 3 of 5 pings to be lost. Thanks Tim On Friday, September 20, 2013, Stefan Hajnoczi wrote: > On Thu, Sep 19, 2013 at 05:31:01PM -0400, Tim Epkes wrote: > > Any plans to provide VETH support for Qemu-KVM. It is a great pt-pt tie > > when when connecting to KVM's on the same machine. I have multiple > reasons > > for doing so (one is educational). Thanks > > QEMU already supports -netdev tap (if you want to use the host Linux > networking stack) and -netdev socket (if you just want point-to-point > tunneling). > > The veth driver isn't suitable for QEMU's use case. QEMU is a userspace > process that wants to inject/extract Ethernet frames. That's exactly > what the tun (tap) driver does. veth is useful for containers where you > want a Linux network interface that is handled by the host network stack. > > Two solutions for point-to-point: > > 1. Run two guests with -netdev tap. Put the interfaces on a software > bridge (see brctl(8)). Or you could also use IP forwarding instead > of a bridge if you like. > > 2. Run two guests with -netdev socket. They send Ethernet frames > directly to each other. > > See the qemu man page for configuration details. > > Stefan >
