HOWTO: kvm with vde networking on Ubuntu, Debian et cetera

As discussed in a previous article, KVM is a kernel-accelerated virtualization package for Linux that utilizes AMD or Intel VT to reduce the cost of virtualization. It is based in part on qemu, a long-lived processor emulation package which also has a non-VT virtualizing engine, kqemu. One of the benefits of using qemu as a codebase is that qemu already has emulation for various pieces of hardware, including network cards. qemu can use a variety of methods for providing networking, including slirp, tunneling, and various others.

To me, the most interesting type of networking is VDE, or "virtual distributed ethernet". This is most similar to the type of networking performed by VMware. vde provides virtual switches (or hubs) and lets you connect them together at will. This document will not explain how to configure a complicated setup; it explains only how to set up a single TUN/TAP interface and utilize it. I will also briefly cover IP Masquerading, which is necessary for your system to access the outside world if it doesn't have a real, routable IP address. If you only require networking between the host and the guest, then you don't need to deal with that.

Before we can proceed, we have to make sure that you have certain packages. This guide doesn't cover setting up kvm; again, read my earlier article for that information. But we will need to install certain packages just to get TUN/TAP and vde working properly. We specifically need the vde and uml-utilities packages for the assorted vde programs and for tunctl, respectively.

Setting up a TUN/TAP interface couldn't be easier on Debian Linux and its derivatives, like Ubuntu. Just add a few lines to the /etc/network/interfaces file, a little something like this:

auto tap0
iface tap0 inet static
  address 172.16.1.1
  network 172.16.1.0
  netmask 255.255.255.0
  vde-switch vde-net

This is actually a fully working example that I am using on my personal system. I use a portion of the 172.16.0.0/12 (rfc1918) address space, because it is the least-frequently-utilized block of reserved addresses (both 10.0.0.0/8 and 192.168.0.0/16 are more popular.) You cannot use a real IP address with this method; in order to do that you must use bridged networking, which I plan to examine in a later article. Once you have added these lines (or some very similar ones - if you change the address, don't forget to change the network number and netmask if necessary) you can issue the following command:

sudo ifup tap0

If this completes without errors, you are home free! If not, make sure you have installed both vde and uml-utilities. Assuming it succeeds, take a quick look at your new interface just to be sure it looks reasonable. It should look very close to the following:

$ ifconfig tap0
tap0      Link encap:Ethernet  HWaddr 9A:47:E1:FD:61:D4 
          inet addr:172.16.1.1  Bcast:172.16.1.255  Mask:255.255.255.0
          inet6 addr: fe80::9847:e1ff:fefd:61d4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:18 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:0 (0.0 b)  TX bytes:468 (468.0 b)

The interface automatically got an IPv6 address because IPv6 is enabled in the system. You can safely ignore this. What we do need to know is where vde has put the socket file used to communicate with it. This is easily figured out, by grepping the output of ps like so:

$ ps ax | grep vde_switch
14653 ?        Ss     0:00 /usr/bin/vde_switch -s /var/run/vde/tap0.ctl -p /var/run/vde/tap0.pid -t tap0 -d
18241 pts/0    R+     0:00 grep vde_switch

Debian (or whatever Debian derivative) automatically ran vde_switch for you when you brought up the tap0 interface, and will kill it if you bring tap0 down. Look at the full command line for pid 14653. -s specifies the socket, which in this case is /var/run/vde/tap0.ctl. This is all you need to know to proceed.

vde has a program which is supposed to be smart enough to launch qemu (or kvm) and point it in the right direction to get all of its settings. But if you get an error saying something like "file not found" and not telling you what file, you probably needed to go through the above step to find out what the socket is. I'm going to just skip all that and explain how to use it my way, because I already had and solved that problem. I ended up writing a very simple script to launch kvm. Here it is:

#!/bin/bash
echo "Loading KVM modules..."
sudo modprobe kvm
sudo modprobe kvm-intel
echo -n "Starting kvm with vdeq... "
sudo /usr/bin/vdeq /usr/bin/kvm \
/media/c/Documents\ and\ Settings/mespinoza/My\ Documents/My\ Virtual\ Machines/qemu-win2k/ \
-hda /media/c/Documents\ and\ Settings/mespinoza/My\ Documents/My\ Virtual\ Machines/qemu-win2k/drivec.img \
-boot c \
-m 384 \
-localtime \
-usb -usbdevice tablet \
-k en-us \
-net nic,model=rtl8139 -net vde,sock=/var/run/vde/tap0.ctl \
-no-acpi

The first few lines load the kvm modules. They could be put into modules.autoload or something; I'll worry about that a little later. If you've done that, you can omit those lines. I want you to especially look at one line, however, the one that looks like this:

-net nic,model=rtl8139 -net vde,sock=/var/run/vde/tap0.ctl \

This code instructs qemu or kvm to use vde networking with a virtual Realtek rtl8319a NIC, and that the socket file is located where we formerly found it, in /var/run/vde/tap0.ctl. This script successfully loads my virtual machine, which is currently located on an NTFS partition (hence the amazing ugliness of the example, and the extremely poor I/O rates I'm getting right now) because I have nowhere else with room for it. This whole kvm project, for me, is a means of getting away from Windows. VMware is capable of filling that need, of course, but kvm is lighter, and it is Free software.

What I really took away from this whole project is that it is simply not yet time to use KVM - wait for some nice new configuration tools to come out, and perhaps for the project to stabilize and become reliable as well...