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:qemu [2007/02/09 21:04] – Add new qemu 0.9.0 PXE options '-boot n -option-rom <pxe_rom_filename>' alienslackware:qemu [2008/09/01 11:04] (current) – Explain user mode networking alien
Line 67: Line 67:
   - download, unpack kqemu archive   - download, unpack kqemu archive
   - configure and build kqemu, and install it on your computer using ''make install''.   - configure and build kqemu, and install it on your computer using ''make install''.
 +
 +
  
 ==== Running QEMU and kqemu ==== ==== Running QEMU and kqemu ====
Line 98: Line 100:
 </code> My kqemu package also installs a [[http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html | udev]] rule file as ''/etc/udev/rules.d/50-kqemu-rule'' in case you run QEMU on a 2.6 kernel, with these contents: <code> </code> My kqemu package also installs a [[http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html | udev]] rule file as ''/etc/udev/rules.d/50-kqemu-rule'' in case you run QEMU on a 2.6 kernel, with these contents: <code>
 # kqemu # kqemu
-KERNEL="kqemu", NAME="%k", MODE="0666"</code> If you decided to restrict access to ''/dev/kqemu'', then you should modify this file to for instance <code>+KERNEL=="kqemu", NAME="%k", MODE="0666"</code> If you decided to restrict access to ''/dev/kqemu'', then you should modify this file to for instance <code>
 # kqemu # kqemu
-KERNEL="kqemu", NAME="%k", MODE="0660" , GROUP="qemu"</code>.+KERNEL=="kqemu", NAME="%k", MODE="0660" , GROUP="qemu" 
 +</code>.
  
   * To make the kqemu module load on boot, you should add the following line to the file ''/etc/rc.d/rc.modules'': <code>   * To make the kqemu module load on boot, you should add the following line to the file ''/etc/rc.d/rc.modules'': <code>
 /sbin/modprobe kqemu /sbin/modprobe kqemu
-</code>+</code> Use the following line instead for kqemu if you have UDEV: <code> 
 +/sbin/modprobe kqemu major=0 
 +</code> This will automatically create the device node ''/dev/kqemu'' on demand.\\ Note that nowadays Slackware comes with ''/etc/rc.d/rc.modules'' as a symbolic link to the file ''/etc/rc.d/rc.modules-<kernelversion>''. You have to check carefully that you modify the //modules// file for the kernel you are currently running.
  
-This concludes the alterations needed for a performance boost of your Virtual Machines inside QEMU. As I said earlier, running qemu is really simple - it is a single binary with a lot of optional commandline parameters that customize the virtual machine it will setup for use. QEMU will use the kqemu accelerator if it finds the kernel module loaded in memory (and if it's built with support for kqemu). The newer versions of QEMU and kqemu (at the time of writing, it's only available in the CVS repository of QEMU, but it will be released as QEMU 0.8.1) provide an additional layer of acceleration called //kernel-kqemu//. In this acceleration mode, the Guest kernel processes will also be accelerated as opposed to the "regular" functionality of kqemu to only accelerate the Guest's user processes. You do need to supply an explicit parameter to the qemu commandline: <code>+This concludes the alterations needed for a performance boost of your Virtual Machines inside QEMU. As I said earlier, running qemu is really simple - it is a single binary with a lot of optional commandline parameters that customize the virtual machine it will setup for use. QEMU will use the kqemu accelerator if it finds the kernel module loaded in memory (and if it's built with support for kqemu). QEMU provides an additional layer of acceleration called //kernel-kqemu//. In this acceleration mode, the Guest kernel processes will also be accelerated as opposed to the "regular" functionality of kqemu to only accelerate the Guest's user processes. You do need to supply an explicit parameter to the qemu commandline: <code>
 qemu -kernel-kqemu <other parameters> qemu -kernel-kqemu <other parameters>
 </code> If you don't want kqemu functionality at all, for instance because some programs and Guest OS-es will not work reliably or not at all with acceleration enabled, you can explicitly tell qemu on the commandline to do without: <code> </code> If you don't want kqemu functionality at all, for instance because some programs and Guest OS-es will not work reliably or not at all with acceleration enabled, you can explicitly tell qemu on the commandline to do without: <code>
Line 145: Line 150:
  
 When you're done with installing from CD, do not forget to at least remove the ''-boot d'' commandline parameter, so that the virtual computer will start from it's hard drive instead of booting from the CDROM. When you're done with installing from CD, do not forget to at least remove the ''-boot d'' commandline parameter, so that the virtual computer will start from it's hard drive instead of booting from the CDROM.
 +
  
  
 ==== Networking your virtual machine ==== ==== Networking your virtual machine ====
  
-By default, QEMU uses a feature which is called //user-mode network//. QEMU will run an internal DHCP server that can assign an IP address to the virtual computer in case that is configured to use DHCP. The network range and gateway are hard-coded into QEMU but it allows your virtual machine to call out to your host machine and beyond. For user-mode networking, you don't need to configure anything on your host. will probably document user-mode networking sometime later, but for now I suggest you read [[slackware:vde | my article on VDE]] where I show how you can use [[http://vde.sourceforge.net/ | VDE (virtual distributed ethernet)]] in combination with dnsmasq to get a much enhanced network experience.+=== User mode networking === 
 + 
 +By default, QEMU uses a feature which is called //user-mode network//. QEMU will run an internal DHCP server that can assign an IP address to the virtual computer in case that is configured to use DHCP. The network range and gateway are hard-coded into QEMU but it allows your virtual machine to call out to your host machine and beyond. For user-mode networking, you don't need to configure anything on your host. \\ QEMU will enable user mode networking by default if you do not pass it any network parameters at all, or if you start it like this: <code> 
 +qemu -net nic -net user <other qemu parameters> 
 +</code> The network characteristics for user mode networking are as follows: 
 +|Gateway/DHCP/TFTP server: |10.0.2.2 |  
 +|DNS server:               |10.0.2.3 |  
 +|Samba server:             |10.0.2.4 |  
 +|Netmask:                  |255.255.255.0 |  
 +|Guest IP:                 |any address above 10.0.2.15 |  
 + 
 +There are limitations to the user mode networking due to the nature of the implementation. 
 + 
 +  * QEMU will act as a firewall between guest OS and the host computer, so that no network communication is possible from any host program to the guest OS. For instance, you will not be able to setup a ssh session to the guest. \\ To get around this dilemma, QEMU has a "''-redir''" optional argument which enables you to redirect certain ports on the host. Traffic destined for these ports will end up at the guest. For example, let's redirect port 22000 on the localhost to port 22 in the guest, in order to setup a ssh session into the guest: <code> 
 +qemu -redir tcp:22000::22 <other qemu options> 
 +</code> If the guest is running a SSH server at port 22, then it is possible to connect a ssh session on the host to the guest's SSH server like this: <code> 
 +ssh -p 22000 localhost 
 +</code> 
 +  * There is actually no proper network connection between the guest and the world outside the Virtual Machine. QEMU will intercept TCP and UDP packets from the guest, dissect them and pass their data payload on to destination computers as if QEMU itself were sending the data. In reverse, QEMU will grab the return traffic and re-assemble TCP and UDP packets for the guest OS. This private implementation of a network stack in QEMU results in TCP and UDP traffic working transparently for the guest OS, but ICMP packets (ping, traceroute for instance) will not be able to pass the boundary. This should not be a concern to you. However lots of people will run a ''ping'' as their first test of the network in QEMU's guest OS and are led to believe that the guest's network is not functional because they do not see a ping response. 
 + 
 +=== Connecting multiple guests to a VLAN === 
 + 
 +QEMU knows the concept of VLAN's. Think of a VLAN as a virtual switch, emulated by QEMU, to which you connect your guest. You typically use a vlan to connect multiple guests into a virtual network. By default, QEMU assigns //vlan=0// to your guest if you do not specify a vlan number. So, the following two commands are basically the same: <code> 
 +qemu -net nic,vlan=0 -net user <other qemu parameters> 
 +qemu <other qemu parameters> 
 +</code> In addition, I advise you to assign your guest OS's network card a fixed MAC address. If you do not assign a MAC address, QEMU will randomly pick a value and many OS-es will not like that (for instance, Slackware's UDEV will create new interfaces eth1, eth2, ... everytime it finds a new MAC address for your interface card at boot). You can assign a MAC address as follows (you can make up any value that is valid, i.e. 6 bytes separated by colons, in hexadecimal representation): <code> 
 +qemu -net nic,vlan=0,macaddr=51:45:4d:55:00:01 
 +</code> 
 +When several guests are connected using the same vlan number, any network packet that is sent by one of the guests, will be distributed over the vlan to all of the other guests. This allows for transparent network communication between the guests.\\ **NOTE** this has nothing to do with the ability of the guests to connect to the world outside QEMU! 
 + 
 +=== Virtual Distributed Ethernet (VDE) === 
 + 
 +To overcome the limitations of //user mode networking//, I suggest you read [[slackware:vde | my article on VDE]] where I show how you can use [[http://vde.sourceforge.net/ | VDE (virtual distributed ethernet)]] in combination with dnsmasq to get a much enhanced network experience. Using VDE, you will be able to make your QEMU guest fully accessible to programs running on your host, and if you bridge your network connections, you can make your Virtual Machines appear on your LAN as if they were real machines.
  
 ==== Advanced topics ==== ==== Advanced topics ====
 Hardware virtualization with QEMU ()
SlackDocs