Using The QEMU Emulator, My Thoughts And Experiences

By Michael Huff

[ Disclaimer: QEMU comes with support for emulating a full x86, PowerPC, or SPARC system; because of my own focus and my lack of having software that needs other architectures, I have stuck to using the emulator's x86 aspect. It should be remembered that, while I am going into as much detail as I can about my experience with QEMU, I am leaving a good portion of the software unaddressed. Simply put, other than trying to boot a Darwin ISO, I have not used it to run no-x86 OSes. ]

Using QEMU: Introductory thoughts

I have been using Linux, along with Windows, since 1997 — sometimes alternating; using one for a while and then replacing it with the other; sometimes dual-booting, with both installed on the same computer. I'm never quite happy with either arrangement. Regarding using one at a time, there are applications on one I miss when I use the other, and Win32 ports and WINE always seem to fall short of using the application natively. When it comes to dual booting, dividing up hard drive space is always a problem; especially considering that while Linux can read NTFS (and read and write to FAT32), any hard drive space dedicated to Linux is mostly inaccessible to Windows.

I remember using a copy of OS/2 Warp I got in mid-1997, and thinking the idea of integrating what is essentially a virtual DOS (or DOS/Windows) computer was neat. This indirectly led me to explore other virtualisation setups, including running AppleDOS in ApplePC under DOSEMU on Linux. When VMWare released their software, I tried an evaluation copy of it, but was unable at that time to get it to work with the Slackware system I had set up. By that point, emulation, it's capabilities, and hardware requirements surpassed the underpowered 486 that was the computer I would have to work with for the next couple of years.

Nowadays, I have a decently modern computer, and I've gone to town rediscovering emulation and the different modern programs such as Basilisk II, Bochs, and QEMU; and I can see the potential that is so close to being able to seamlessly switch from one operating environment to the next. So far, the program I like best for x86 emulation is QEMU, and I'd like to write a bit about my experience with it and thoughts on it.

How I set up and built QEMU under Linux

For those of you who do not know, QEMU is the (fast!) emulation suite written by Fabrice Bellard (available at https://fabrice.bellard.free.fr/qemu/). QEMU includes programs to emulate a number of platforms, including the x86, SPARC, and PowerPC. It also is capable of running stand-alone programs for various platforms (much the same way WINE runs Microsoft Windows programs under X).

As you would expect with a sufficiently complex program such as QEMU, compiling from source requires that a number of other libraries and add-ons be installed, in order to be successful. Out of the three operating systems I have used QEMU on, two (NetBSD and Windows) do not gain any benefit from compiling from source; there, I stick to using pkg_add or the binary installer, respectively.

However, shortly before the release of QEMU 0.7.0, Fabrice Bellard wrote and released the closed-source kqemu module for the Linux kernel, which requires compiling both the module and the QEMU program from source, in order to install. It's estimated that, without the module, QEMU performs at roughly 5:1 or 10:1 (that is to say, taking five or ten native instructions to perform one emulated instruction), whereas, with the module, the ratio approaches 2:1. Suffice to say, this performance increase is well worth some minimal fussing about with compiling sources. (Experimental versions of the kqemu module are available for FreeBSD and Windows, but, in this article, I will address using it with Linux.)

Compiling the source, while slightly more complex then the usual "./configure && make && make install" routine, is still very do-able for most people. This explanation is based on my experience with Debian; if you're using another distribution, the specifics will be different, but the basic idea should be the same. Also, compiling kqemu is different if you are using the 2.6 kernel, as opposed to the 2.4 kernel I use. (The difference is outlined on the instruction page for kqemu, which is at https://fabrice.bellard.free.fr/qemu/kqemu-doc.html).

First, I execute "sudo apt-get install qemu" to get most of the infrastructure in place (mainly the bochsbios package and whatever SDL libraries are not already installed). After that, I grab the libsdl-dev package with apt-get, and then I install the kernel source tree. The kqemu instruction page gives great step-by-step instructions on how to configure your Linux kernel source tree for kqemu. The only thing I will add here is that, on my current system, I have never had a "home-made" Linux kernel successfully boot, undoubtedly due to something I'm doing wrong. (I have never been good with rolling my own Linux kernel.) Fortunately, installing the new kernel is not necessary; simply building it works. These days, I just extract the source from the tar archive I made of the compiled source tree, and then create the appropriate /usr/src/linux symbolic link.

The rest is easy. Obtain the QEMU and kqemu source files, extract the QEMU source, then change into the newly-created QEMU source directory and extract the kqemu source there. Then, do the familiar "./configure && make && sudo make install" ritual, to build and install it.

A more knowledgeable person than me will know how to set up the proper links and scripts in /etc/init.d/. Not wanting to jump into that, myself, I simply run "sudo insmod kqemu", before running QEMU.

Setting up and using my QEMU environment

After QEMU is successfully installed, it's time to use it. On my computer, I have my primary HD on one IDE controller, and my DVD and second hard disk on another; this minimises the amount of seeking the hard drive heads have to carry out, and increases performance. After writing them to CD, I copy any interesting ISO images to a directory on my second hard disk, and use create hard disk images on my primary hard drive. This gives QEMU a performance boost when it uses these ISO files as a virtual CD (in addition to the performance boost already gained by reading from the hard drive instead of the slower CD-ROM drive). From my home directory, I create a QEMU directory, and then separate directories for each virtual machine, though there is no practical reason you could not dump each uniquely named hard disk image into one single directory.

As with Bochs, QEMU includes a separate hard disk creation program; however, using hard disk images under QEMU is considerably easier than with Bochs. With Bochs, you have to take note of the sectors, heads, and sectors per track of each hard disk image (and then save this information in your ~/.bochsrc); with QEMU, the complexity is in the number of image formats supported (which currently are vvfat, vpc, bochs, dmg, cloop, vmdk, qcow, cow, and raw). Myself, I mostly ignore them, and use the default raw format.

There are front ends for QEMU available, but, personally speaking, I find it easiest to simply type the command parameters in by hand. While that may sound weird, there are only a few that are likely to change:

1. the virtual device you boot from. (When you install your OS, you will want to choose to boot from the CD, and then quit QEMU after it is installed, and then choose to boot from the hard disk.)
2. the name and location of the virtual CD (or whether or not you use one at all).
3. the amount of RAM you assign to the virtual machine. (Often, the default of 128 megs is fine, but you may need to adjust it, or you may find that you can free some up.)

Once your OS is installed to the hard disk image, and your settings are finished, you may want to create a simple shell script that invokes QEMU with the proper command.

I have installed Windows XP, FreeDOS, FreeBSD, and NetBSD at different times on QEMU. I have tried to install Windows 2000, but gave up after it got stuck during the install. My largest gripe about QEMU may well be a personal failure (to RTFM?) on my part: my network does not work. If I use the default /dev/net/tun device, DHCP hangs (until I control-c it); if I use the unprivileged -user-net option, dhcp "works", but the machine is inaccessible. The work-around I have for this is to use mkisofs to create ISO images of any files I want to import into the virtual machine, and attach them as virtual CD-ROMs. I also have odd focus weirdness (QEMU grabbing the focus in window mode, after I press Ctrl-Alt to release the cursor).

My experience backing up and sharing virtual hard disks has been hit and miss. I have had XP complain about data corruption after unzipping a hard disk image, but had no problems running a NetBSD image after extracting it. Not having tried many of the image formats, I do not know if switching from the raw format to another one would improve matters or not.

One thing to note is that when using floppy images (e.g., the boot floppies for a Linux distribution), it's better to dd the images to another file from inside the virtual machine. For instance, if you want to boot from the file big.fs, you would copy it to your virtual hard drive, boot the virtual drive with another file attached as the floppy drive (e.g., specifying "-fda 2.fs" on the command line), and then running a command such as dd if=big.fs of=/dev/fd0 bs=512 inside the emulator; then rebooting — but now with 2.fs having the contents of big.fs arranged in a way that makes QEMU happy. Just trying to boot from the raw image, in my experience, tends to produce mixed results (varying from making no difference to not working at all).

Closing thoughts

In closing, I think QEMU is a great program, and a real asset for those who want to use virtual environments for whatever purposes. It works great with CLIs and lightweight window mangers, but I would not recommend it for people who want to use intensive GUI environments such as XP or GNOME/KDE on a regular basis (e.g., as a second desktop). Compared to Bochs, it's much faster (in fact, on the QEMU Web page, it justifiably boasts of being a "fast!" emulator), but it's also worth noting that its interface is simpler, both on the command line and in the way that you swap out devices while the program is running. (With QEMU, you simply type Ctrl-Alt-2, and then use the eject and change commands).

Compared to VMware, I think that QEMU (when using the kqemu module) performs nearly as well, but QEMU lacks VMware's flexibility in managing memory assigned to your virtual machine. This is because VMware is able to swap out part (or most, depending on your configuration) of your virtual machine's RAM to disk, but QEMU is stuck using whatever the size you have allocated to /dev/shm. In QEMU's favor, QEMU currently does not ship with a GUI front end, but between the ability to use a key combination (Ctrl-Alt-f) to switch between full-screen and window modes, and the simplicity of QEMU's internal console commands, you really do not miss it. I prefer QEMU's interface, because I feel it strikes the right balance between capabilities and leanness. (After all, memory and CPU cycles used by a Win32 or GTK front end are not available to be used by the virtual machine!)

 

---

Since 1997 Michael Huff has used Linux and BSD to read and post on the world wide web, do light programming and to explore his curiosity on various operating system concepts. Because he fails at programming, he considers himself a moderate end-user. His hobbies are listening to music and tinkering with different OS configurations.