In Chapter 1, Understanding Linux Virtualization, we used the
virt-host-validate command to do some pre-flight checks in terms of the host’s preparedness for KVM virtualization. As a part of that process, some of the checks include checking if the following devices exist:
/dev/kvm: The KVM drivers create a
/dev/kvmcharacter device on the host to facilitate direct hardware access for virtual machines. Not having this device means that the VMs won’t be able to access physical hardware, although it’s enabled in the BIOS and this will reduce the VM’s performance significantly.
/dev/vhost-netcharacter device will be created on the host. This device serves as the interface for configuring the
vhost-netinstance. Not having this device significantly reduces the virtual machine’s network performance.
/dev/net/tun: This is another character special device used for creating TUN/TAP devices to facilitate network connectivity for a virtual machine. The TUN/TAP device will be explained in detail in future chapters. For now, just understand that having a character device is important for KVM virtualization to work properly.
Let’s focus on the last device, the TUN device, which is usually accompanied by a TAP device.
So far, all the concepts that we’ve covered include some kind of connectivity to a physical network card, with isolated virtual networks being an exception. But even an isolated virtual network is just a virtual network for our virtual machines. What happens when we have a situation where we need our communication to happen in the user space, such as between applications running on a server? It would be useless to patch them through some kind of virtual switch concept, or a regular bridge, as that would just bring additional overhead. This is where TUN/TAP devices come in, providing packet flow for user space programs. Easily enough, an application can open
/dev/net/tun and use an
ioctl() function to register a network device in the kernel, which, in turn, presents itself as a tunXX or tapXX device. When the application closes the file, the network devices and routes created by it disappear (as described in the kernel
tuntap.txt documentation). So, it’s just a type of virtual network interface for the Linux operating system supported by the Linux kernel – you can add an IP address and routes to it so that traffic from your application can route through it, and not via a regular network device.
TUN emulates an L3 device by creating a communication tunnel, something like a point-to-point tunnel. It gets activated when the tuntap driver gets configured in tun mode. When you activate it, any data that you receive from a descriptor (the application that configured it) will be data in the form of regular IP packages (as the most commonly used case). Also, when you send data, it gets written to the TUN device as regular IP packages. This type of interface is sometimes used in testing, development, and debugging for simulation purposes.
The TAP interface basically emulates an L2 Ethernet device. It gets activated when the tuntap driver gets configured in tap mode. When you activate it, unlike what happens with the TUN interface (Layer 3), you get Layer 2 raw Ethernet packages, including ARP/RARP packages and everything else. Basically, we’re talking about a virtualized Layer 2 Ethernet connection.
These concepts (especially TAP) are usable on libvirt/QEMU as well because by using these types of configurations, we can create connections from the host to a virtual machine – without the libvirt bridge/switch, just as an example. We can actually configure all of the necessary details for the TUN/TAP interface and then start deploying virtual machines that are hooked up directly to those interfaces by using
kvm-qemu options. So, it’s a rather interesting concept that has its place in the virtualization world as well. This is especially interesting when we start creating Linux bridges.