Welcome to the new location of Alien's Wiki, sharing a single dokuwiki install with the SlackDocs Wiki.

Welcome to Eric Hameleers (Alien BOB)'s Wiki pages.

If you want to support my work, please consider a small donation:

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
slackware:vde [2006/04/07 10:44] alienslackware:vde [2007/11/30 21:42] (current) – fix qemu 'macaddr' syntax; fix rc.vdenetwork script alien
Line 31: Line 31:
  
 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 ====
Line 40: Line 39:
 === 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</codeor <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
Line 56: Line 59:
 </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>
Line 117: Line 120:
 /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.
 +
  
  
Line 171: Line 175:
         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
Line 227: Line 229:
         # 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
Line 234: Line 237:
   restart|reload)   restart|reload)
         $0 stop         $0 stop
 +        sleep 1
         $0 start         $0 start
         ;;         ;;
Line 242: Line 246:
 </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
 # #
Line 270: Line 273:
  
 # 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'(erroroutput 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>
- 
 A networking powerhouse ()
SlackDocs