[Bug 776650] Re: Build qemu-kvm with native VDE support

David Masover ninja at slaphack.com
Sat Jan 19 09:50:27 UTC 2013

I'd like to expand on Dwight's comments a bit. Qemu network cards have
two sides, the side the VM sees (virtio is probably fastest, if you can
get drivers for it), and the "backend", which is how that's connected to
anything else. Here are the backends it has:

-net user. Dirt simple to set up. Pure user-mode networking -- the VM
intercepts all requests the guest makes, and just does those again on
the host. Doesn't need any special privileges, and for most purposes,
it's basically just like having a NAT. It even has a bit of other
scattered functionality, like a built in SMB server, so Windows machines
can access the host filesystem. Not the fastest, though, and not
terribly flexible.

-net tap. This would be plenty for Dwight's use case. The host gets a
"tap" interface, which is connected (as if via a crossover cable) to the
guest -- with pretty much full networking capabilities. May need to run
as root. With iptables, you can certainly set up forwarding, and let
guest VMs talk to each other. You can run dnsmasq on the host to provide
DHCP and DNS for the VMs. It's just slightly obnoxious, because this is
one tap device per client.

-net socket -- two modes here: TCP or UDP multicast. TCP lets you wire
one NIC on one VM to another NIC on another VM -- basically, a crossover
cable. You *could* build a VDE-like switch out of this, by having one VM
connect directly to the host with TAP, and have it bridge to other VMs
connected with the socket. But this is a pain -- you're basically
building a switch out of a VM, which is hugely inefficient compared to
VDE. Multicast probably isn't as pleasant -- I don't know enough about
multicast to be sure, but it looks like this could end up broadcasting
to the entire real network -- better than bridging, but not terribly

-net vde -- actual VDE support. VDE lets you do much more than what
Dwight is asking for. You can create entire virtual networks, with
functioning switches and everything, that aren't connected to the host
at all -- and you can connect these to other VMs on other machines.
Tonight, I wanted to play with UDP hole punching
(http://en.wikipedia.org/wiki/UDP_hole_punching) and other NAT traversal
stuff, but I don't have a spare router, and my desktop actually has a
real Internet IP address (no NAT). VDE would've let me create as many
virtual routers as I wanted, between as many virtual networks as I
wanted, all virtualized inside my desktop. It's not just that bridging
is a bad idea here, it's that it wouldn't even solve the problem -- the
*whole point* is that I want to "punch through" to an otherwise
inaccessible network.

I should mention that vdekvm actually does not work for what I want to
do, at least as far as I can tell. When I tell it to connect to a
switch, it actually tries to create that switch and connect it to the
host -- but I want a network that _isn't_ connected to the host!

You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu-kvm in Ubuntu.

  Build qemu-kvm with native VDE support

To manage notifications about this bug go to:

More information about the Ubuntu-server-bugs mailing list