| Next revision | Previous revision |
| slackware:vde [2006/04/07 10:07] – created alien | slackware:vde [2007/11/30 21:42] (current) – fix qemu 'macaddr' syntax; fix rc.vdenetwork script alien |
|---|
| |
| The solution is a small but powerful piece of software called [[http://vde.sourceforge.net/ | VDE]] - which stands for //Virtual Distributed Ethernet//. You can see VDE as the software incarnation of a hardware network switch plus attached cables. Using the //vde_switch// and //vde_plug// programs you are able to create quite complex virtual analogies of a network that can span several hosts, even across the Internet. Read the documentation if you want to know more about this exciting product. For our limited purpose of enhancing the network capabilities of the QEMU Virtual Machines, I will just point out that VDE configures a //virtual// network for your QEMU Guests, and uses a single tap device to set it all up. You configure the tap device as root (typically during the boot stage of your computer) after which no further root access is required for the Virtual Machines to connect to the VDE "switch".\\ | The solution is a small but powerful piece of software called [[http://vde.sourceforge.net/ | VDE]] - which stands for //Virtual Distributed Ethernet//. You can see VDE as the software incarnation of a hardware network switch plus attached cables. Using the //vde_switch// and //vde_plug// programs you are able to create quite complex virtual analogies of a network that can span several hosts, even across the Internet. Read the documentation if you want to know more about this exciting product. For our limited purpose of enhancing the network capabilities of the QEMU Virtual Machines, I will just point out that VDE configures a //virtual// network for your QEMU Guests, and uses a single tap device to set it all up. You configure the tap device as root (typically during the boot stage of your computer) after which no further root access is required for the Virtual Machines to connect to the VDE "switch".\\ |
| | |
| | === Getting a VDE package === |
| | |
| | I have created a Slackware package for VDE that you'll find in my [[http://www.slackware.com/~alien/slackbuilds/vde/ | SlackBuilds repository]]. The package by the way installs a version of the example [[#example_scripts | rc.vdenetwork]] script in it's //doc// directory. |
| | |
| |
| ==== DNSMasq ==== | ==== DNSMasq ==== |
| Dnsmasq is targeted at home networks using NAT and connected to the internet via a modem, cable-modem or ADSL connection but would be a good choice for any small network where low resource use and ease of configuration are important." | Dnsmasq is targeted at home networks using NAT and connected to the internet via a modem, cable-modem or ADSL connection but would be a good choice for any small network where low resource use and ease of configuration are important." |
| |
| I could not have said it better myself. We will use dnsmasq to compensate for the loss of the QEMU-internal DHCP Server (because we abandon user-mode networking). Note that Slackware comes with a dnsmasq package and a ''/etc/rc.d/rc.dnsmasq'' init script is installed automatically, although it is not executable by default. If your machine already runs dnsmasq, you will have to look at the ''rc.vdenetwork'' script in the [[#example_scripts | last section]] and integrate the dnsmasq related configuration into your existing setup. If you're //not// already running dnsmasq, you don't have to worry about this ''rc.dnsmasq'' file that Slackware installed - we won't be using it. | I could not have said it better myself. We will use dnsmasq to compensate for the loss of the QEMU-internal DHCP Server (because we abandon user-mode networking). Note that a Slackware full-install contains a dnsmasq package already, and a ''/etc/rc.d/rc.dnsmasq'' init script is installed automatically, although it is not executable by default. If your machine already runs dnsmasq, you will have to look at the ''rc.vdenetwork'' script in the [[#example_scripts | last section]] and integrate the dnsmasq related configuration into your existing setup. If you're //not// already running dnsmasq, you don't have to worry about this ''rc.dnsmasq'' file that Slackware installed - we won't be using it. |
| |
| Dnsmasq will pick up any existing network configuration information of your computer, by reading ''/etc/hosts'' and ''/etc/resolv.conf'' and will use that information when it sends DHCP configuration to the QEMU Guest. If your computer has a functioning network connection to the LAN and/or the Internet, your QEMU Guest(s) will enjoy the same functionality. Furthermore, by examining your computer's message log ''/var/log/messages'' you will be able to determine what IP address the QEMU Guest picks up, and you can use that knowledge to ''ssh'' into the Virtual Machine or point a web browser to a running Apache server inside the VM - or connect to whatever other network service that you enabled on your VM. | Dnsmasq will pick up any existing network configuration information of your computer, by reading ''/etc/hosts'' and ''/etc/resolv.conf'' and will use that information when it sends DHCP configuration to the QEMU Guest. If your computer has a functioning network connection to the LAN and/or the Internet, your QEMU Guest(s) will enjoy the same functionality. Furthermore, by examining your computer's message log ''/var/log/messages'' you will be able to determine what IP address the QEMU Guest picks up, and you can use that knowledge to ''ssh'' into the Virtual Machine or point a web browser to a running Apache server inside the VM - or connect to whatever other network service that you enabled on your VM. |
| |
| |
| ====Tying it all together ==== | ====Tying it all together ==== |
| === How it works === | === How it works === |
| |
| * First of all, we load the "tun" driver which is a kernel module that you should have enabled for your kernel. Slackware kernels have this tun module, if you compile your own kernels, make sure you configure<code>CONFIG_TUN=m</code> or <code>CONFIG_TUN=y</code>. Also, the device ''/dev/net/tun'' needs to exist. On my Slackware system it is created automatically when I run <code>modprobe tun</code> (or let the ''rc.vdenetwork'' init script below load the module). If your system does not automatically create that device file, you should create it yourself: <code> | * First of all, we load the "tun" driver which is a kernel module that you should have enabled for your kernel. Slackware kernels have this tun module, if you compile your own kernels, make sure you configure<code> |
| | CONFIG_TUN=m (Device Drivers - Network device support -> Universal TUN/TAP device driver support) |
| | CONFIG_IP_NF_CONNTRACK=m (Connection tracking) |
| | CONFIG_IP_NF_IPTABLES=m (IP tables support) |
| | CONFIG_IP_NF_NAT=m (Full NAT)</code> Instead of building these as modules, you can of course compile them into the kernel by changing the 'm' to 'y'. Also, the device ''/dev/net/tun'' needs to exist. On my Slackware system it is created automatically when I run <code>modprobe tun</code> (or let the ''rc.vdenetwork'' init script below load the module). If your system does not automatically create that device file, you should create it yourself: <code> |
| mkdir /dev/net | mkdir /dev/net |
| mknod /dev/net/tun c 10 200 | mknod /dev/net/tun c 10 200 |
| </code> The TCPIP configuration values I used in this example are arbitrary - you may choose whatever you like, as long as you pick an address within a subnet range that is not used on your local network. The Virtual Machines you are going to be running will all be in the IP subnet defined by the //tap0//'s IP address and netmask. The tap0 will act as the default gateway for that subnet. | </code> The TCPIP configuration values I used in this example are arbitrary - you may choose whatever you like, as long as you pick an address within a subnet range that is not used on your local network. The Virtual Machines you are going to be running will all be in the IP subnet defined by the //tap0//'s IP address and netmask. The tap0 will act as the default gateway for that subnet. |
| |
| * Traffic to and from the subnet behind the tap0 interface must be forwarded of course - <code> | * Traffic to and from the subnet behind the tap0 interface must be forwarded <code> |
| echo "1" > /proc/sys/net/ipv4/ip_forward | echo "1" > /proc/sys/net/ipv4/ip_forward |
| </code> and since we are most probably setting up all of this on an ordinary workstation, we don't want to cause network disruption by suddenly announcing the birth of a new network segment. We will "hide" the tap0 interface and our QEMU/VDE subnet behind a firewall, by applying couple of NAT //iptables// rules. Tus, we designate the eth0 interface as the external firewall interface (in the example I use //eth0// - your external interface might be called different). <code> | </code> and since we are most probably setting up all of this on an ordinary workstation, we don't want to cause network disruption by suddenly announcing the birth of a new network segment. We will "hide" the tap0 interface and our QEMU/VDE subnet behind a firewall, by applying couple of NAT //iptables// rules. Tus, we designate the eth0 interface as the external firewall interface (in the example I use //eth0// - your external interface might be called different). <code> |
| /etc/rc.d/rc.vdenetwork start | /etc/rc.d/rc.vdenetwork start |
| </code> We're all set! It is time to start your QEMU session and see if it all works as expected! I have provided another script in the [[#example_scripts | last section]] of this article as an example of how to run QEMU and have it using VDE for the networking. | </code> We're all set! It is time to start your QEMU session and see if it all works as expected! I have provided another script in the [[#example_scripts | last section]] of this article as an example of how to run QEMU and have it using VDE for the networking. |
| | |
| |
| |
| echo -n "Starting VDE network for QEMU: " | echo -n "Starting VDE network for QEMU: " |
| |
| # If we are running 2.6, load tun module | # Load tun module |
| if uname -r | grep '^2.6'; then | /sbin/modprobe tun 2>/dev/null |
| /sbin/modprobe tun 2>/dev/null | # Wait for the module to be loaded |
| # Wait for the module to be loaded | while ! /bin/lsmod |grep -q "^tun"; do echo Waiting for tun device;sleep 1; done |
| while ! /bin/lsmod |grep -q "^tun"; do echo Waiting for tun device;sleep 1; done | |
| fi | |
| |
| # Start tap switch | # Start tap switch |
| # Remove the control socket | # Remove the control socket |
| rm -f /tmp/vde.* | rm -f /tmp/vde.* |
| | rmdir /var/run/vde.ctl |
| # Stop dnsmasq | # Stop dnsmasq |
| pgrep -f dnsmasq | xargs kill -TERM | pgrep -f dnsmasq | xargs kill -TERM |
| restart|reload) | restart|reload) |
| $0 stop | $0 stop |
| | sleep 1 |
| $0 start | $0 start |
| ;; | ;; |
| </code> | </code> |
| |
| A script that you can use to start QEMU, connect it to the vde_switch, and have sound in the VM is presented here. Note that if you run more than one QEMU session, the Virtual Machines will see each other on the network privided by the VDE | A script that you can use to start QEMU, connect it to the vde_switch, and have sound in the VM is presented here. Note that if you run more than one QEMU session, the Virtual Machines will see each other on the network provided by the VDE switch. This means that all of them must have unique MAC addresses. Since QEMU will assign the //same// MAC address to each VM by default, we will have to pass each QEMU instance it's own MAC Address. So, for running multiple QEMU powered VM's, you'll have to create multiple copies of the following script (or think up some magic to generate unique MAC addresses). Actually, I also provide this same example script on the [[slackware:qemu | QEMU Wiki page]]. The example assumes you want to run Windows XP, so that explains the comments and the naming of the various files used. You can run anything you want inside the QEMU VM or course, QEMU won't care. <code> |
| switch. This means that all of them must have unique MAC addresses. Since QEMU will assign the //same// MAC address to each VM by default, we will have to pass each QEMU instance it's own MAC Address. So, for running multiple QEMU powered VM's, you'll have to create multiple copies of the following script (or think up some magic to generate unique MAC addresses). Actually, I also provide this same example script on the [[slackware:qemu | QEMU Wiki page]]. The example assumes you want to run Windows XP, so that explains the comments and the naming of the various files used. You can run anything you want inside the QEMU VM or course, QEMU won't care. <code> | |
| #!/bin/sh | #!/bin/sh |
| # | # |
| |
| # This command returns to the command prompt immediately, | # This command returns to the command prompt immediately, |
| # and QEMU's error output is redirected to files. | # and QEMU's (error) output is redirected to logfiles. |
| vdeqemu -net vde,vlan=0 -net nic,vlan=0,macaddr 52:54:00:00:EE:02 -m 256 -localtime -soundhw all -hda winxp.img -cdrom ${ISODIR}/winxp_pro_us.iso 1>winxp.log 2>winxp.err ${PARAMS} & | vdeqemu -net vde,vlan=0 -net nic,vlan=0,macaddr=52:54:00:00:EE:02 -m 256 -localtime -soundhw all -hda winxp.img -cdrom ${ISODIR}/winxp_pro_us.iso 1>winxp.log 2>winxp.err ${PARAMS} & |
| </code> | </code> |
| |
