First off, what is QEMU? Well, it's a system emulator, meaning that it allows you to emulate a number of hardware architectures (x86, x86-64 and PowerPC are currently known to work, with others including Sparc and MIPS in development) and thereby run another operating system on top of your existing OS. It also offers user emulation mode, but this article will focus only on the system emulation side of things.

So what makes QEMU interesting? Well, there are a number of other Emulators to consider, such as BOCHS (which, though powerful, can be hard to configure), and VMWare (a polished, proprietary, commercial product). Another whole school of products to consider is that of the emerging "Virtualization" field. Xen is the name that sticks out in this area, although technically Xen offers "para-virtualization", a virtualization technique that presents a software interface to virtual machines that is similar but not identical to that of the underlying hardware. While Xen has a great future, due to the fact that it requires a modified kernel on the host and the guest operating systems, there are some situations in which Xen is not the ideal choice. In any case, for this article, I'm going to focus on QEMU because it's easy to install and configure, and it opens up a world of OS tinkering that any Open Source afficionado will love.

Initially I thought QEMU was a great toy to play around with, and that I could justify it to myself by being able to run other Linux distros, and compare them to my own. Having used VMWare at my previous employer to allow for offline demos of a Linux-based web server from Windows laptops, I was reasonably familiar with the concept of emulators. However, right from the beginning, I was impressed by the quality of QEMU, as well as the feature set. The three things that stood out for me were:

- Networking seemed to "just work" from the first, allowing the emulated machine to access the Internet while running from my wireless laptop.
- Being able to run in snapshot mode (where the original state is preserved and any changes are written to a temporary location), and the functionality availble through QEMU's monitor.
- The breadth of command line options for things like location of CD-ROM, floppy disk, hard disks, which device to boot from, how much memory the Emulated machine should have.

There are two ways to install QEMU - either in binary format or from source. Since I was having some inital problems installing from source (more on that later), I installed the binary to get started quickly and see if it was worth my time investment to work through the source installation problems. Installing the binary is as simple as downloading the tar archive file from the website (http://fabrice.bellard.free.fr/qemu/qemu-0.7.2-i386.tar.gz), copying it to the root ("/") directory, and unpacking it as root. They suggest you download a number of test disk images to ensure things are working correctly. Personally, I prefer to mix things up a bit, so I downloaded Damn Small Linux (DSL) - http://www.damnsmalllinux.org/, and ran that as a live CD using:

qemu -cdrom dsl2.5.iso

This tells QEMU to start up with the DSL CD image as the emulated CD-ROM. And there it is - a beautiful DSL instance. I decided I also wanted to install Damn Small Linux to an (emulated) hard drive so I could save settings between boots. And because I'd never installed DSL to hard drive and wanted to see what the process was. To do this, I simply created a disk image with following command:

qemu-img create dsl.img 250M

Simple, isn't it? This creates my cavernous 250MB hard drive image, and then I boot into Damn Small Linux again and run the installation process (including writing to the MBR so I can boot from this emulated hard drive image in the future):

qemu -cdrom dsl2.5.iso -boot d dsl.img

When the installation is complete, you can boot into your new Damn Small Linux installation with:

qemu dsl.img

You'll notice I'm not specifying any networking options here. Well, fear not - if you have anything like a standard setup with networking availble on your host system, QEMU will auto-magically make networking available to your guest OS. This is because the default is "-user-net", which uses the user mode network stack if no tun/tap network init script is found. Given all the networking nightmares I'd experienced with VMWare, this was a pleasant surprise. If you do have special networking needs, there are a number of other configurations available, which are all well explained in the man pages. One downside of the default option is that QEMU effectively firewalls any incoming connections to the emulated machine, so you won't be able to connect to it via the network without digging into some of the other networking options.

QEMU handles mouse input in a similar way to VMWare - when you left-click inside an emulated machine, it grabs the mouse for that machine - to release, you press Ctrl+Alt. A nice touch is that the title window for an emulated machine includes a message with this information, as a quick reminder for those unfamiliar with it. QEMU also features a "monitor" which allows users to perform complex tasks, such removing or inserting CDs or Floppy Disks, freezing the emulated machine, committing changes to the underlying disk for a machine started in "snapshot" mode, or to inspect the status of the emulated machine. Ctrl+Alt+2 takes you to the monitor window where you can issue these commands, and Ctrl+Alt+1 returns you to the emulated machine itself.

So now I'm convinced. I see that QEMU is a great piece of software and I want to invest the time to build from source, or rather, to fix my failed source compilation. So what problems was I having? Well, there were a few things compounded. Firstly, I was missing a number of SDL development packages to allow for graphical output of the emulated machines (which I consider a must-have). Secondly, I'm not seeing the KQEMU plugin as being recognized as part of my "configure" script. The KQEMU is a binary, and closed source (but free) plugin provided by the developer of QEMU, Fabrice Bellard, which provides CPU virtualization for emulated machines, thereby greatly enhancing the speed of the emulated machine. Without the accelerator, QEMU emulates a 800MHz Pentium II with a default of 128MB of RAM, although this can be easily adjusted, and a standard mouse and keyboard, as well as optionally CD-ROMs, Floppy Disks, NE2000 PCI network adapters, Serial Ports, a Soundblaster 16 card and up to 2 PCI IDE Hard Disks. The QEMU website claims that while the regular emulation is anywhere from 5:1 to 10:1 in terms of speed, with the KQEMU accelerator, this jumps to 2:1.

Both of my compilation issues (SDL development packages missing and the KQEMU accelerator not being recognized) were resolved by finding the appropriate packages (in this particular case: libsdl-devel, zlib1g, linux-headers), but what's more, in the process of troubleshooting this situation, I learned about static libraries, shared libraries and dynamic libraries. I learned about using "ldd" to diagnose the libraries that are required by a particular program, as well as "ldconfig -p" to view currently installed libraries.

Once I had the right packages installed, installing QEMU and the KQEMU accelerator was a simple process:

curl http://fabrice.bellard.free.fr/qemu/qemu-0.7.2.tar.gz > qemu-0.7.2.tar.gz
tar -zxvf qemu-0.7.2.tar.gz
cd qemu-0.7.2
curl http://fabrice.bellard.free.fr/qemu/kqemu-0.7.2.tar.gz > kqemu-0.7.2.tar.gz
tar -zxvf kqemu-0.7.2.tar.gz
./configure --target-list="x86_64-softmmu i386-softmmu"
make
sudo make install

The target list from the "./configure" command is optional, but if you are having trouble compiling all the target systems, this may help. Also, if you are on a very recent distro with GCC 4.0, QEMU won't compile with it. Be sure to specify GCC 3.4 (you can do this by including something like "--cc=gcc-3.4 --host-cc=gcc-3.4" with your configure command). You can now load the KQEMU kernel module with:

sudo modprobe kqemu
sudo mknod /dev/kqemu c 250 0
sudo chmod 666 /dev/kqemu

To load the KQEMU module at boot time will vary based on your distro. Mine (Ubuntu) uses /etc/init.d/bootmisc.sh, but once you've located the appropriate script, here's the text to insert:

# Start Qemu with KQemu accelerator
/sbin/modprobe kqemu
mknod /dev/kqemu c 250 0  # Create the KQEMU device
chmod 666 /dev/kqemu      # Make it accessible to all users

By default QEMU allocates 128MB RAM to an emulated machine. If I wanted to bump that up to 256MB (having 512MB on the host machine in question), I got an error message saying:

You do not have enough space in '/dev/shm' for the 256 MB of QEMU virtual RAM.
To have more space available provided you have enough RAM and swap, do as root:
umount /dev/shm
mount -t tmpfs -o size=272m none /dev/shm

So this led me into an exploration of Shared Memory - what is it and how it is allocated? I learned about tempfs and Shared Memory. I also learnt about other virtual file systems, what their settings are and where they are configured.

Now I had QEMU and KQEMU installed and configured, and I realized that there was a whole lot more I could do with QEMU than I'd originally anticipated. QEMU is the perfect way to create a test/staging environment for my own small scale production web server. Currently I use source control and local installation on my laptop to QA any code changes to the production server, but now that I can very easily create an exact replica of my production server (I rent a 4.2GB Virtual Private Server on which I've installed Debian Sarge), I can have a mirror image of my server to test anything from new administration scripts, security updates to new software installations. Also, I'd always been interested in FreeBSD (http://www.freebsd.org/ - now with a brand-new website), but had never had a way to be able to install and use it. This was the perfect opportunity. Many people also use QEMU to run Windows on top of Linux. Since I don't have a copy of Windows, I thought I'd try out ReactOS instead - an open source ground up implementation of a Windows XP compatible OS.

What's my point here? That this situation is not so remarkable in the open source world. That one thing leads to another, and that the freedom provided by open source opens up possibilities that wouldn't otherwise be possible. It's unlikely that I would have paid for a copy of VMWare for myself just to play around with, but if I hadn't "played around" with QEMU due to it's openness and accessibility, I wouldn't have discovered about Libraries and Shared Memory. I wouldn't have realized the potential usage as a mirror of my production server without the need for messy dual boots, or additional hardware. And I wouldn't now be heading off in another direction. Where to? Rsync, and server "mirroring". I look forward to the journey.

This article originally appeared on Linux.com.

Comments

Post a comment

Your name:

Comment: