Comment 10 for bug 776650

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

-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!