Wireless bridged networking in KVM. Why is it so complicated

kvmvirtual machinevirtualboxvmwarewifi

I've been using VirtualBox (and sometimes VMWare) for years and I've never had any problem with the virtual network adapters, no matter if the physical ones were wired or not.

I also played some time ago with KVM in a wired set-up and, although I had to edit some configuration files to get it working, I could also create a bridged adapter without any major problems.

Today I decided (wrongly, it seems) to try to use KVM in a laptop running Ubuntu 13.10 and tried to create a virtual machine with bridged networking over a wireless interface. It was extremely painful to set this up.

After following all the tutorials I found (for example) and having to reboot my laptop several times to get the connection back I just gave up and went back to my old well-known VirtualBox.

And, actually, the first thing I noticed when I looked into the official KVM documentation was that they discourage from trying to bridge a wireless adapter since, according to them:

The here shown method, will not work with most(all?) wireless drivers, as these do not support bridging.

So, my question is:

How come they say that most wireless adapters do not support bridging if it works in VirtualBox and VMWare just "out-of-the-box"?
And what's the difference between these hypervisors that makes it so complicated in KVM, if it works at all?

Best Answer

Background on KVM

I think this is partly due to expectations with KVM. KVM is first and foremost a server product and not a desktop product for virtualization. It can be used in either application but it's definitely suited more for being used on a server.

I use it on 3+ hosts at work each hosting 5-10 VMs apiece and it has run flawlessly and is easy to manage, and basically just works.

Question #1

How come they say that most wireless adapters do not support bridging if it works in VirtualBox and VMWare just "out-of-the-box"?

I believe you're drawing this conclusion from this blurb on the KVM website.

WARNING: The here shown method, will not work with most(all?) wireless drivers, as these do not support bridging.

This statement is here because it is typically the case. I believe this is often why when you install VirtualBox or VMWare there are typically kernel modules that are getting installed and these products provide their own wrapping around doing this to facilitate making it easier. These products are essentially working around these issues.

I believe this issue is also a driver issue. The drivers for WiFi under Linux still pales in comparison to the support that's provided by the Windows drivers for the same hardware. That's just a fact of life.

NOTE: I've had wireless NICs in the past that I was not able to put into bridge mode in the past as well. I've typically worked around the issue by either using VirtualBox or getting a different NIC for my laptop.

I'll also highlight that neither VirtualBox nor VMware could do this either, at least not until more recent versions. See this as evidence from VMware's KB:

If your host has a wireless network adapter, you cannot use bridged networking on Linux hosts in VMware Workstation 5 or lower, VMware Server 1.x, any version of GSX Server, any hosts in VMware Workstation 3 or lower, or in VMware GSX Server 2 or lower. Under these products, if you want to run virtual machines on a host that uses wireless Ethernet adapters, you must configure your virtual machines to use NAT or host-only networking.

Source: Using bridged networking with a wireless NIC (760)

Question #2

And what's the difference between these hypervisors that makes it so complicated in KVM, if it works at all?

I can't really shed any light on this particular question, other than to say that if it was easy I imagine this feature would be enabled. I think the crux of the issue has to do with this feature requiring 3 or more groups to coordinate their efforts (hardware manuf., driver devs., Linux kernel, & KVM).

These situations are often what results when you need multiple groups to work together in the open source world (IMO)!

So can I set it up or what?

You can set this up following the directions from either of these 2 articles. The setup requires using a TUN/TAP device which can be put into bridge mode.

Related Solutions

Ubuntu – How to connect a KVM guest to the internet with wireless

You should be able to use the user-mode networking stack. Start qemu like this:

qemu-system-x86_64 \
    -smp 1 -m 1024 \
    -net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp:127.0.0.1:2222-10.0.0.2:22 \
    -net nic \
    -cdrom systemrescuecd-x86-2.0.1.iso -boot d

The important options:

-net nic: Show a virtual network card for the guest
-net user: Make the qemu process on the host communicate over the real network just like any other process would
net=10.0.0.0/8: The subnet on the virtual network
host=10.0.0.1: The host IP address on the virtual network
hostfwd=tcp:127.0.0.1:2222-10.0.0.2:22: The qemu process on the host listens for TCP connections from localhost on port 2222 and forwards them to the virtual network to 10.0.0.2:22 (so you can ssh to your new virtual machine)

On the guest run

ifconfig eth0 10.0.0.2 up
ip route add default via 10.0.0.1 dev eth0

Test SSH from host to guest

ssh 127.0.0.1 -p 2222

and from guest to host

ssh 10.0.0.1

Test the internet reachability from the guest

wget google.com

The host process works like a NAT router. Only TCP and UDP traffic will work. In particular ping only works between the guest and the host you can't ping google.com (my usual network testing method). The advantage of this approach is that you don't even need root privileges.

Add virtual bridge without the loss of networking

With KVM (but not Xen) you can now use Macvtap instead of bridging. So you don't actually have to tear down the host's network stack and bring it back up with a bridge.

Macvtap works by piggybacking on an existing ethernet interface. It will make your ethernet interface listen on an additional MAC address and it will "steal" the incoming packets addresses to that MAC address so they don't appear to enter through that ethernet interface anymore and instead go to the guest.

If you still want to use a bridging config, you can do it, and of course you realize, it's risky. One way would be to put all of the commands you need to execute to convert the configuration (brtcl, ip, etc...) into a shell script. Schedule an at job to reboot the machine 10 minutes later, then execute the shell script. If it succeeds, cancel the at job, and edit config files to make your changes permanent. If you make a mistake, at least you will get your server back 10 minutes later. I don't recommend it!