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 [2006/04/12 07:32] alienslackware:qemu [2008/09/01 11:04] (current) – Explain user mode networking alien
Line 49: Line 49:
 You should realize that running an operating system directly on the hardware is always faster than running the same operating system inside a virtual machine, because of the processor overhead that the virtualization of all hardware dictates. Even so, the guest operating system inside the QEMU virtual machine feels suprisingly responsive if you have a decent CPU and lots of RAM. You should realize that running an operating system directly on the hardware is always faster than running the same operating system inside a virtual machine, because of the processor overhead that the virtualization of all hardware dictates. Even so, the guest operating system inside the QEMU virtual machine feels suprisingly responsive if you have a decent CPU and lots of RAM.
  
- +==== Obtaining and building QEMU ====
-==== Obtaining QEMU software ====+
  
 Qemu is not part of Slackware, but it is easily built from source, and [[http://www.slackware.com/~alien/slackbuilds/qemu/ | ready-made packages]] are available from my SlackBuild repository. If you want to build yourself you can use my [[http://www.slackware.com/~alien/slackbuilds/qemu/build/qemu.SlackBuild | SlackBuild script]] found at the above URL, or go to the [[http://qemu.org/download.html | QEMU website]] and compile the source code yourself. Qemu is not part of Slackware, but it is easily built from source, and [[http://www.slackware.com/~alien/slackbuilds/qemu/ | ready-made packages]] are available from my SlackBuild repository. If you want to build yourself you can use my [[http://www.slackware.com/~alien/slackbuilds/qemu/build/qemu.SlackBuild | SlackBuild script]] found at the above URL, or go to the [[http://qemu.org/download.html | QEMU website]] and compile the source code yourself.
 +
 +//NOTE// Building qemu and kqemu has changed with qemu 0.8.1.\\
 +Until qemu 0.8.0, if you want to use kqemu you need to
 +  - unpack the qemu source archive
 +  - change into the 'kqemu' subdirectory of the extracted directory structure
 +  - unpack the kqemu archive in this subdirectory
 +  - move up one directory level to the top of the qemu source tree and run the <code>
 +./configure
 +make
 +make install</code> commands to install the software (both qemu and kqemu.\\ With the release of 0.8.1, building kqemu is separated from building qemu. When you want kqemu to accelerate the emulation in qemu, you
 +  - download and unpack qemu sources
 +  - configure and build qemu with kqemu support (this is the default if you run ''./configure'')
 +  - install qemu on your computer using ''make install''
 +  - download, unpack kqemu archive
 +  - configure and build kqemu, and install it on your computer using ''make install''.
 +
  
  
Line 64: Line 79:
 You should prepare your Slackware system for the kqemu module so that it can operate as efficiently as possibble. Your computer will automatically have been setup in case you installed my Slackware packages from the URL I provided in the [[#obtaining_qemu_software | previous section]]. If you compiled everything yourself, please follow these instructions: You should prepare your Slackware system for the kqemu module so that it can operate as efficiently as possibble. Your computer will automatically have been setup in case you installed my Slackware packages from the URL I provided in the [[#obtaining_qemu_software | previous section]]. If you compiled everything yourself, please follow these instructions:
  
-  * The acceleration that kqemu offers works best if kqemu can map the Virtual Machine's memory pages to your computer's physical RAM. If kqemu finds a mounted RAM filesystem at ''/dev/shm'' it will create a hidden file there which will hold the RAM of the virtual machine. If it does not find a RAM filesystem, the VM's memory will be mapped to a disk file in your ''/tmp'' directory, and of course this will not nearly be as fast as working entirely in RAM.\\ +  * The acceleration that kqemu offers works best if kqemu can map the Virtual Machine's memory pages to your computer's physical RAM. If kqemu finds a mounted RAM filesystem at ''/dev/shm'' it will create a hidden file there which will hold the RAM of the virtual machine. If it does not find a RAM filesystem, the VM's memory will be mapped to a disk file in your ''/tmp'' directory, and of course this will not nearly be as fast as working entirely in RAM.\\ So, add this line to ''/etc/fstab'' <code>
-So, add this line to ''/etc/fstab'' <code>+
 none        /dev/shm        tmpfs   defaults        0 0 none        /dev/shm        tmpfs   defaults        0 0
-</code> By default, adding this line in ''/etc/fstab'' will allow a maximum of 50% of your physical RAM to be used up by the RAM filesystem. If you want your QEMU to emulate a computer with an //X MB// amount of memory, then this amount of memory "X" must be available to qemu in ''/dev/shm'', or else qemu will refuse to start. This means for instance, that if your computer has 1GB of RAM, and the above line is present in ''/etc/fstab'', qemu will be able to emulate a computer with a maximum of 500MB RAM (actually, a little less than 50% is effectively available to the VM, so try to give QEMU a couple of percents less than 50% of your physical RAM).\\ +</code> By default, adding this line in ''/etc/fstab'' will allow a maximum of 50% of your physical RAM to be used up by the RAM filesystem. If you want your QEMU to emulate a computer with an //X MB// amount of memory, then this amount of memory "X" must be available to qemu in ''/dev/shm'', or else qemu will refuse to start. This means for instance, that if your computer has 1GB of RAM, and the above line is present in ''/etc/fstab'', qemu will be able to emulate a computer with a maximum of 500MB RAM (actually, a little less than 50% is effectively available to the VM, so try to give QEMU a couple of percents less than 50% of your physical RAM).\\ If you need more RAM for QEMU, you must change the defaults like this: <code>
-If you need more RAM for QEMU, you must change the defaults like this: <code>+
 none        /dev/shm        tmpfs   size=750M         0 0 none        /dev/shm        tmpfs   size=750M         0 0
 </code> which makes 750MB of your RAM available for use by (k)qemu. </code> which makes 750MB of your RAM available for use by (k)qemu.
Line 75: Line 88:
 </note> </note>
  
-  * The installation of kqemu creates a device node ''/dev/kqemu'' that will by default be writeable by anyone. If you don't like that, you can limit access to the device node by letting it be owned by a Linux group (for instance, create a group called //qemu//) restrict access to the device node to just that group and add yourself to that group.\\ +  * The installation of kqemu creates a device node ''/dev/kqemu'' that will by default be writeable by anyone. If you don't like that, you can limit access to the device node by letting it be owned by a Linux group (for instance, create a group called //qemu//) restrict access to the device node to just that group and add yourself to that group.\\ If you're doing all of this yourself, you should add these lines to ''/etc/rc.d/rc.local'' to ensure that the device ''/dev/kqemu'' is available and accessible: <code>
-If you're doing all of this yourself, you should add these lines to ''/etc/rc.d/rc.local'' to ensure that the device ''/dev/kqemu'' is available and accessible: <code>+
 ## For 2.6 kernels, as long as udev does not re-create the ## ## For 2.6 kernels, as long as udev does not re-create the ##
 ## /dev/kqemu device node automatically, you can keep      ## ## /dev/kqemu device node automatically, you can keep      ##
Line 86: Line 98:
   chmod 666 /dev/kqemu   chmod 666 /dev/kqemu
 fi fi
-</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 kernelIf you decided to restrict access to ''/dev/kqemu'', then you should modify this file.+</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 
 +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 
 +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//Here, the Guest kernel processes will also be accelerated as opposed to the "regular" function 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 OS-es will not work reliably or not at all, you can tell qemu on the commandline as well: <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>
 qemu -no-kqemu <other parameters> qemu -no-kqemu <other parameters>
 </code> </code>
Line 105: Line 124:
 ==== Installing an Operating System in QEMU ==== ==== Installing an Operating System in QEMU ====
  
-Remember that QEMU builds a virtual computer around the Operating System you're going to use inside of it. So, the hard drives are virtualized as well. Before starting QEMU, we will create a big file that QEMU can then use as the virtual hard disk: <code>+In this section, we're going to install a Guest Operating System in QEMU. Since my guess is that many people use QEMU to run a copy of Windows on a Linux host, I will use Windows XP as an example. The hardware that QEMU emulates (see the [[#emulated_hardware_and_supported_guest_os-es | previous section]] for a list) is fully supported by at least Windows Xp/2000/NT and the few tweaks that are needed to make Windows 98/95 work well are documented in the [[http://qemu.org/qemu-doc.html | qemu user-documentation]]. In my experience, Windows 2000 is an optimal compromise between speed and functionality, but Windows XP works well on fast hardware and with the latest kqemu accelerator.\\ 
 +The instructions and tips that are documented in this section will mostly apply to the installation of any other Operating System. 
 + 
 +Remember that QEMU builds a virtual computer around the Operating System you're going to use inside of it. So, the hard drives are virtualized as well. So, before starting QEMU, we will create a big file that QEMU can then use as the virtual hard disk: <code>
 dd if=/dev/zero of=winxp.img bs=1k count=0 seek=4000000 dd if=/dev/zero of=winxp.img bs=1k count=0 seek=4000000
 </code> This will create a so-called //sparse file// with a size of about 4GB. A sparse file means that it can ultimately grow to 4GB of occupied disk blocks, but the file will only allocate enogh blocks to store the actual data. So, if you run ''du'' on that directory, it will report 4GB used, but actually, the file will currently use no space at all! Now, a real file using up 4GB of disk space before you even wrote to it, can be created using this command (it's up to you to decide what you want to use, either command is OK):  <code> </code> This will create a so-called //sparse file// with a size of about 4GB. A sparse file means that it can ultimately grow to 4GB of occupied disk blocks, but the file will only allocate enogh blocks to store the actual data. So, if you run ''du'' on that directory, it will report 4GB used, but actually, the file will currently use no space at all! Now, a real file using up 4GB of disk space before you even wrote to it, can be created using this command (it's up to you to decide what you want to use, either command is OK):  <code>
Line 115: Line 137:
 This is the big moment... we're going to fire up QEMU and tell it to use the 4GB empty file we have just created as the virtual computer's first hard drive, and use an ISO image to represent as a CD-ROM drive in the virtual machime. QEMU should also boot from that CD. Run <code> This is the big moment... we're going to fire up QEMU and tell it to use the 4GB empty file we have just created as the virtual computer's first hard drive, and use an ISO image to represent as a CD-ROM drive in the virtual machime. QEMU should also boot from that CD. Run <code>
 qemu -localtime -m 256 -hda winxp.img -cdrom ./ISOS/winxp_pro_us.iso -boot d qemu -localtime -m 256 -hda winxp.img -cdrom ./ISOS/winxp_pro_us.iso -boot d
-</code> Alternatively, as an example, the commandline would have looked like this if we had chosen to use a real CD in the CDROM drive ''/dev/cdrom'': ''qemu -localtime -m 256 -hda winxp.img -cdrom /dev/cdrom -boot d''\\ +</code> Alternatively, as an example, the commandline would have looked like this if we had chosen to use a real CD in the CDROM drive ''/dev/cdrom'': <code> 
-The '-boot d' parameter instructs QEMU to let the virtual machine boot from the (virtual) CD-ROM drive we've specified using //-cdrom//. The '-hda winxp.img' of course means that the first IDE harddisk is to be represented by our image file (QEMU can use a hdb, hdc and hdd as well, in case you need more hard disks inside QEMU).+qemu -localtime -m 256 -hda winxp.img -cdrom /dev/cdrom -boot d</code>. The ''-boot d'' parameter instructs QEMU to let the virtual machine boot from the (virtual) CD-ROM drive we've specified using //-cdrom//. The '-hda winxp.img' of course means that the first IDE harddisk is to be represented by our image file (QEMU can use a hdb, hdc and hdd as well, in case you need more hard disks inside QEMU).
  
-When you run the above command, you'll see a new window appear, and you'll actually see the Windows XP installer boot (assuming you didn't mess up during one of the previous steps)! To use the mouse in QEMU, you need to click in the window to give it focus. QEMU grabs the mouse, and to give it back to your other applications you press <key>C-A</key> (it even says so in QEMU's window bar). The installation of XP is a process that I'm not going to repeat, I am assuming you'll know how to proceed. The installation of Windows 2000/XP in QEMU still has a couple of annoyances. These are: excruciatingly slow progress from time to time, especially during the stage where Windows tries to detect the hardware in your system. QEMU even knows a separate commandline parameter ''-win2k-hack'' that you should add exclusively for the duration of a Windows 2000 installation if you experience //disk full errors// during the installation!\\+When you run the above command, you'll see a new window appear, and you'll actually see the Windows XP installer boot (assuming you didn't mess up during one of the previous steps)! To use the mouse in QEMU, you need to click in the window to give it focus. QEMU grabs the mouse, and to give it back to your other applications you press <key>C-A</key> (it even says so in QEMU's window bar). Another key combination worth mentioning is the full-screen toggle <key>C-A-f</key>. If QEMU is running full-screen you can fool anyone that you're suddenly running the evil OS :-)\\ 
 +The installation of XP is a process that I'm not going to repeat, I am assuming you'll know how to proceed. What you need to be aware of, is that the installation of Windows 2000/XP in QEMU still has a couple of annoyances. These are:\\ 
 +  * Excruciatingly slow progress from time to time, especially during the stage where Windows tries to detect the hardware in your system
 +  * Errors of "disk full" half-way the install. QEMU even knows a separate commandline parameter ''-win2k-hack'' that you should add exclusively for the duration of a Windows 2000 installation if you experience //disk full errors// during the installation 
 +  * Windows XP sometimes installs without a problem but at the first boot displays the following message: <code> 
 +A problem is preventing Windows from accurately checking the 
 +license for this computer. Error code: 0x800703e6.</code> If you see this, you have bad luck. You can get around this by booting XP in //Safe Mode// without networking support.\\
 Even though the slow pace of the Windows installation can make you wonder if you did the right thing installing QEMU, these annoyances will be gone once Windows installation has finished and you reboot into the OS for the first time.  Even though the slow pace of the Windows installation can make you wonder if you did the right thing installing QEMU, these annoyances will be gone once Windows installation has finished and you reboot into the OS for the first time. 
  
-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.+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, if you setup 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 ====
 +
 +So far we have been through the bare minimum to get your Guest OS installed and working on your host computer and interacting with the network. Much more is possible with QEMU, and I will dedicate this chapter to the advanced topics that are most interesting or least wel-documented in other places. I will also assume you're running a recent version of QEMU. The emulator advances in great strides, and some of the features and command line switches I talk about are not available in all releases. Generally speaking, try to upgrade to the latest official release. At the point of writing, I am using 0.8.1.
 +
  
 === Using copy-on-write files === === Using copy-on-write files ===
  
-QEMU uses a disk image file containing your installed Operating System. We created that image file in a previous section as a //raw// image, meaning the file has no special format. QEMU knows of several disk image formats, and one of them I want to introduce to you: the //QCOW// or ""qemy copy-on-write" format. The QCOW file can be used in combination with a //base image file//. Suppose you're happy with the installed OS in your ''winxp.img'' disk image file. You want to try out a new application, or you want to do some potentially disastrous tests in your virtual machine. You can then create a QCOW file that is based on the ''winxp.img'' file. Create the QCOW (qemu copy-on-write) file like this: <code>+QEMU uses a disk image file containing your installed Operating System. We created that image file in a previous section as a //raw// image, meaning the file has no special format. QEMU knows of several disk image formats, and one of them I want to introduce to you: the //QCOW// or ""qemy copy-on-write" format. The QCOW file can be used in combination with a //base image file//. Suppose you're happy with the installed OS in your ''winxp.img'' disk image file. You want to try out a new application, or you want to do some potentially disastrous tests in your virtual machine. You don't want to risk the possibility to thrash your installed OS and want a safe way to test with the option to revert to the original state if things go terribly wrong. \\ 
 +You can then create a QCOW file that is based on the ''winxp.img'' file. Create the QCOW (qemu copy-on-write) file like this: <code>
 qemu-img create -b winxp.img -f qcow winxp.qcow qemu-img create -b winxp.img -f qcow winxp.qcow
-</code> +</code> You then change the qemu commandline from <code>qemu -localtime -m 256 -hda winxp.img </code> to <code>qemu -localtime -m 256 -hda winxp.qcow </code> to use your new QCOW file.\\ 
-When you tell QEMU to use the QCOW file instead of the RAW image file (something like ''qemu -hda winxp.qcow''), QEMU will do all file writes to the QCOW image, thus treating the original RAW file as a //read-only// file. The effect is, that if you stop QEMU after you did some work, the original image file is //unaltered// and all changes are recorded into the QCOW files. If you delete the QCOW subsequently and re-start QEMU now using the original ''winxp.img'' file, there is no trace left of the session you ran using the QCOW file.\\ +When you tell QEMU to use the QCOW file instead of the RAW image file, QEMU will do all file writes to the QCOW image, thus treating the original RAW file as a //read-only// file. The effect is, that if you stop QEMU after you did some work, the original image file ''winxp.img'' is //unaltered// and all changes are recorded into the QCOW file ''winxp.qcow''. If you delete the QCOW subsequently and re-start QEMU with the original commandline using the original ''winxp.img'' file, there will be no trace left of the previous QEMU session you ran using the QCOW file.\\ 
-So, this is ideal for testing stuff out - in fact, this is how I test and build my new Slackware packages. When you're happy with the result, you can commit the changes to the base image file and get rid (if you want) of the now emptied QCOW file: <code>+So, this is ideal for testing stuff out - in fact, this is how I test and build my new Slackware packages. When you're happy with the result, you don't delete the QCOW file, bit instead commit the changes recorded in that file back to the base image file: <code>
 qemu-img commit winxp.qcow qemu-img commit winxp.qcow
-</code>+</code> If you want, you can get rid of the now emptied QCOW file.\\
 Read the qemu-img man page if you want to know more about the supported image file formats (some support compression and encryption!). Read the qemu-img man page if you want to know more about the supported image file formats (some support compression and encryption!).
  
Line 149: Line 214:
   * Freeze/unfreeze the Virtual Machine (VM) and save or restore its state from a disk file.   * Freeze/unfreeze the Virtual Machine (VM) and save or restore its state from a disk file.
   * Inspect the virtual machine state without an external debugger.   * Inspect the virtual machine state without an external debugger.
-  * Send key presses to OS running inside the virtual machine.+  * Send key presses to the guest OS running inside the virtual machine.
  
 == Changing a CD/floppy in the virtual machine == == Changing a CD/floppy in the virtual machine ==
  
-The most interesting feature of the monitor from an end user perspective is the ability to change removable media images. Two scenarios:+An interesting feature of the monitor from an end user perspective is the ability to change removable media images. Two scenarios:
   - Suppose you want to install Slackware in QEMU. You start QEMU with something like <code>   - Suppose you want to install Slackware in QEMU. You start QEMU with something like <code>
 qemu -localtime -m 256 -hda slackware.img -cdrom ./ISOS/slackware-10.2-install-d1.iso -boot d qemu -localtime -m 256 -hda slackware.img -cdrom ./ISOS/slackware-10.2-install-d1.iso -boot d
Line 176: Line 241:
 </code> </code>
  
-  - You're running X on the host as wellas on the guest and in the guest, want to switch to a console using <key>C-A-F6</key>. The host will intercept this key combination even if the QEMU window has focus. The solution here is to switch to the QEMU monitor using <key>C-A-2</key> keypresses and then run the //literal// command <code>+  - You're running X on the host as well as on the guest. In the guest, you need to run a keyboard sequence containing <key>C-A</key> - like, you want to switch to a console using <key>C-A-F6</key> or end your X session using <key>C-A-backspace</key>. The host will intercept this key combination even if the QEMU window has focus. The solution here is to switch to the QEMU monitor (<key>C-A-2</key>and then run the //literal// command - for instance <code>
 sendkey ctrl-alt-f6 sendkey ctrl-alt-f6
-</code>+</code> By 'literal' i mean that you type the characters exactly as I showed you.
  
  
-=== Mounting filesystems inside the virtual disk image ===+=== Mounting a QEMU disk image on the Host ===
  
-On the host, you can mount filesystems created in partitions that are present in QEMU's virtual disk image - and access the files contained in there - on certain conditions:+On the host, you can mount filesystems created in partitions that are present in QEMU's virtual disk image - and access the files contained in there - under certain conditions:
  
   - QEMU most **not** be running when you mount the virtual disk partitions!   - QEMU most **not** be running when you mount the virtual disk partitions!
Line 220: Line 285:
 ln -s lp0 parport0 ln -s lp0 parport0
 </code> </code>
 +
 +
 +=== Printing to the Host's CUPS server ===
 +
 +The Guest OS can print to a CUPS printer that you configured on the Host. No other software on the Host or the Guest is needed. The Guest's printing system must be able to use //IPP//, the "Internet Printing Protocol". This is the CUPS native protocol.
 +
 +If your Guest is Windows 2000/XP, you need to do the following:
 +  - Click on "add printer" from the printer list window;
 +  - Select "networkprinter or a printer connected to another computer";
 +  - Pick "Connect to a printer on the Internet ..." and enter the correct URL;
 +  - Install the driver for your printer (you will need to have the driver setup program ready if it is not supported by Windows by default);\\ \\ The URL for your CUPS printer will look like <code>
 +http://10.111.111.254:631/printers/lp0</code> where the address ''10.111.111.254'' is the IP address for the Host and ''lp0'' is the name of the printer that you defined in CUPS. Naturally, you will need to substitute values that are appropriate for your own computer!\\ If you use the ''rc.vdenetwork'' init script I documented in [[slackware:vde | my QEMU/VDE network page]] then ''10.111.111.254'' will actually be the correct IP address to use.
 +
 +If your Guest is Slackware Linux, then you need to setup the CUPS client in the Guest. I assume that you already installed the CUPS package when you installed Linux in the Guest. This is what you should do:
 +  - Edit the file ''/etc/cups/client.conf'' and look for the line that says "''#ServerName myhost.domain.com''". Change that line into <code>ServerName 10.111.111.254</code> where you supply a correct IP address for your host. If you use the ''rc.vdenetwork'' init script I documented in [[slackware:vde | my QEMU/VDE network page]] then ''10.111.111.254'' will actually be the correct IP address to use;
 +  - Make the CUPS init script executable so that CUPS will start automatically when the Guest boots: <code>chmod +x /etc/rc.d/rc.cups</code>
 +  - Reboot the Guest or (re-) start CUPS: <code>/etc/rc.d/rc.cups restart</code>
 +  - Your Guest should now be able to use your Host CUPS printer.
 +
 +<note tip>
 +In case you configured your Host's CUPS server to make it visible to other CUPS clients on your network (read my [[slackware:cups | "setting up CUPS" page]]), then the above CUPS client configuration won't be necessary. The Host's CUPS printer will automatically appear - ready for use - in your Guest even if CUPS is running in its default configuration.
 +</note>
 +
 +
 +=== Sound support in the Guest ===
 +
 +QEMU has pretty good sound support. It emulates several sound hardcards. You can print a list of the emulated cards by running <code>qemu -soundhw ?</code> Support for the Adlib sound card in QEMU is not enabled by default (Soundblaster 16 and Ensoniq ES1370 are available in the VM by default) You can add support for Adlib to the emulator when you build the software, by adding <code>--enable-adlib</code> to the ''configure'' command. If you want information about the tunable audio parameters, run <code>qemu -audio-help</code>
 +
 +For sound output, QEMU uses SDL which in turn uses OSS. Slackware uses the ALSA sound driver which has OSS emulation support. Since version 0.8.0, QEMU can use ALSA directly for sound output, but you will have to explicitly enable this when building the sofware. Add <code>--enable-alsa</code> to the ''configure'' command.\\
 +The scripts in the final section of this Wiki page show you how to setup your environment so that you can actually hear the sound that QEMU outputs. The requirement for sound to come from your speakers is the environment variable ''QEMU_AUDIO_DRV
 +'' which must have a value of either "''sdl''" or "''oss''", or in case you compiled-in ALSA support, it may have a value of "''alsa''" as well.
  
  
 === Using an USB device in QEMU === === Using an USB device in QEMU ===
 +
 +USB devices that are connected to the host machine can be accessed directly inside the Virtual Machine. QEMU                            needs an aditional parameter ''-usb'' to actually enable USB support in the VM. The emulated Intel SB82371 UHCI-Controller has a 8-port USB hub. If you want access to one of your physical devices, you will need to find out it's //Vendor-ID// and //Product-ID//. This information is obtained by examining the output of <code>/sbin/lsusb</code> or <code>cat /proc/bus/usb/devices</code>. You can either tell QEMU to make the device available by looking up the //VendorID // and //ProductID// and passing it on the commandline <code>
 +qemu -usb -usbdevice host:<VendorID>:<ProductID> <other_parameters>
 +</code> or starting QEMU just with USB support enabled: <code>
 +qemu -usb <other_parameters>
 +</code> After booting the guest OS in the VM, switch to the monitor by pressing <key>C-A-2</key> and enter the following command <code>
 +usb_add host:<VendorID>:<ProductID>
 +</code> When you return to the graphical screen of the Guest by pressing <key>C-A-1</key> you will see a USB "device attach" event in the messagelog (Linux) or on-screen (Windows).
 +
 +  * An example: You have a HP Scanjet 3300C connected to the USB port of your computer. The output of ''lsusb'' is <code>
 +# lsusb 
 +Bus 003 Device 002: ID 03f0:0205 ScanJet 3300C
 +</code> The command that you use to make this scanner accessible in QEMU is <code>
 +qemu -usb -usbdevice host:03f0:0205 <other_parameters></code>
 +
 +<note important>
 +The important thing to consider with using real USB devices, is that the Host must not have any driver loaded for the USB device. If your hotplug loads drivers automatically, you can enter the driver's name into the file ''/etc/hostplug/blacklist'' to make sure that hotplug will leave it alone. In the QEMU dccumentation I noticed that this is supposedly no longer an issue with (recent) 2.6 kernels. YMMV as I have not yet tried this.
 +</note>
 +
 +=== PXE booting your QEMU virtual machine ===
 +
 +In [[:slackware:pxe|another article]] on this Wiki, i talk about the advantages of network booting ([[wp>PXE boot]]) when you are installing Slackware. Booting the Slackware installer from the network can sometimes be the only way of installing Slackware - imagine a PC without floppy and CDROM drives. QEMU on the other hand, has no need for network boot since you can just create an ISO image and pass that as the "//-cdrom//" parameter and that's it.\\
 +Yet there are times when you'd want your QEMU virtual machine were able to use PXE to boot from the network, if only to test your network setup without sacrificing real hardware. There is only one problem, the emulated QEMU network card (Realtek 8029, a NE2000 clone) does not support booting from the network (it does not emulate a boot ROM).
 +
 +There are two ways to overcome this problem.
 +
 +  * The first is to use the [[http://rom-o-matic.net/|ROM-o-Matic]]. ROM-o-matic.net dynamically generates Etherboot ROM images. We will let it create a PXE-capable ISO image that has support for our emulated Realtec network card. We can then use this small (~130kB) ISO image with the "//-cdrom//" parameter to QEMU to let it serve as a "replacement" PXE-boot ROM for the emulated network card.\\ The ISO generation works as follows - on the ROM-o-Matic start page,
 +    * Select //latest production release// 
 +    * Choose NIC/ROM type **ns8390:rtl8029 - [0x10ec,0x8029]**
 +    * Choose ROM output format **ISO bootable image without legacy floppy emulation (.iso)**
 +    * To generate and download a ROM image press: <key>Get ROM</key>\\ No further customizations are needed, the default options are exactly right for our purposes.
 +    * Save the generated ISO file on your local hard disk (for instance as //qemu_pxeboot.iso//)\\ \\ To use this ISO to boot from your PXE server, run qemu as follows: <code>
 +qemu -cdrom qemu_pxeboot.iso -boot d <other options>
 +</code> Read the article on [[:slackware:pxe|installing Slackware using PXE]] if you want to know more about how to setup a full-blown PXE server.
 +
 +  * The other option you have is available since QEMU 0.9.0 and that is to use the //''-option-rom''// parameter. As of the 0.9.0 release, QEMU can do a PXE boot using one of the PXE-capable boot roms available in ''/usr/share/qemu'':
 +    * /usr/share/qemu/pxe-ne2k_pci.bin
 +    * /usr/share/qemu/pxe-pcnet.bin
 +    * /usr/share/qemu/pxe-rtl8139.bin\\ In order to support booting from the network, the ''-boot'' parameter has been extended with the possible value //''n''// for "network". An example of the command to PXE-boot your QEMU Virtual Machine from the network follows: <code>
 +qemu -localtime -m 256 -hda slackware.img -boot n -option-rom /usr/share/qemu/pxe-ne2k_pci.bin <other_parameters></code>
 +
 +
 +<note tip>
 +If you read the [[slackware:vde#dnsmasq|Wiki article on VDE]] in order to improve the networking support for QEMU, and are running dnsmasq using the example ''rc.vdenetwork'' script, you can easily add support for network booting to the script. Look in the script for <code>DNSMASQ_OPTIONS=""</code> and change it into <code>
 +DNSMASQ_OPTIONS="--dhcp-boot=/slackware-11.0/pxelinux.0,\"10.111.111.254\",10.111.111.254"</code> The two assumptions here (which you are free to change of course) are:
 +  * QEMU sees your //host// as having the IP Address ''10.111.111.254''
 +  * Your //host// has a TFTP server setup so that ''/slackware-11.0/pxelinux.0'' is the location under the tftproot directory where the PXE bootloader ''pxelinux.0'' can be downloaded.
 +</note>
 +
 +<note tip>
 +If your TFTP server is not installed on the //host// but somewhere on the "real" network, you're in a bit of a problem: the PXE client and the TFTP server are separated by a NAT firewall!\\
 +Actually, there is no problem if you are using VDE for the network support. The ''rc.vdenetwork'' script installs a few basic iptables rules that make your //host// act as the NAT (masquerading) router for the QEMU //guests//. The TFTP requests will not be able to pass the NAT (which causes Slackware's //tftp-hpa// server to log errors like '' in.tftpd[8146]: tftpd: read(ack): Connection refused'').\\
 +We need a some extra work on the iptables firewall here, to let the TFTP traffic pass along. Add the following commands to the ''rc.vdenetwork'' script, or another place if your firewall is not setup there: <code>
 +modprobe ipt_state
 +modprobe ipt_helper
 +modprobe ip_conntrack_tftp
 +modprobe ip_nat_tftp
 +iptables -A INPUT -m helper --helper tftp -j ACCEPT
 +iptables -A OUTPUT -m helper --helper tftp -j ACCEPT
 +</code> after which the QEMU VM will find the TFTP server and start downloading the bootcode, and the Operating System.
 +</note>
 +
 +
 +=== Copy/paste text between Host and Guest ===
  
 FIXME FIXME
  
  
-=== The VNC patch and other user contributions ===+=== Sharing files between Host and Guest ===
  
 FIXME FIXME
  
  
-=== A QEMU start script ===+''Code Text'' 
 + 
 +==== A QEMU start script ====
  
 For ease of use, we will create a script that will start QEMU with a lot of default options. The script will write the output into a //.log// and //.err// file and then change into a background process, so that you can just start the script  in a terminal and get your prompt back, or add it to your Window Manager menu. Call the script for instance ''start_winxp.sh'' and make it executable. <code shell> For ease of use, we will create a script that will start QEMU with a lot of default options. The script will write the output into a //.log// and //.err// file and then change into a background process, so that you can just start the script  in a terminal and get your prompt back, or add it to your Window Manager menu. Call the script for instance ''start_winxp.sh'' and make it executable. <code shell>
Line 243: Line 405:
 # Qemu can use SDL sound instead of the default OSS # Qemu can use SDL sound instead of the default OSS
 export QEMU_AUDIO_DRV=sdl export QEMU_AUDIO_DRV=sdl
 +
  
 # Whereas SDL can play through alsa: # Whereas SDL can play through alsa:
Line 294: Line 457:
  
   * [[http://qemu.org/ | QEMU homepage]]   * [[http://qemu.org/ | QEMU homepage]]
 +
 +  * [[http://qemu.org/qemu-doc.html | QEMU user documentation]]
  
   * [[http://qemu.dad-answers.com/download/qemu/ | QEMU daily CVS snapshot]]   * [[http://qemu.dad-answers.com/download/qemu/ | QEMU daily CVS snapshot]]
  
   * [[http://qemu.dad-answers.com/ | QEMU users forum]]   * [[http://qemu.dad-answers.com/ | QEMU users forum]]
 +
 +  * __IRC__: the #qemu channel on Freenode.
 Hardware virtualization with QEMU ()
SlackDocs