Bad, vile and meaningless: Brief Experiences in Using QEMU from Alan's clob

QEMU

QEMU is a software CPU emulator. This means that it contains a models of several CPUs that it can run on any of the other CPUs it supports. For instance, proprietary software only available on x86 CPUs could be run in sparc with only some performance being lost to the dynamic translation. Additionally, QEMU also can emulate Sparc, PowerPC and PC hardware, allowing you to simulate complete computers to guest applications. This will allow you to run a copy of Windows inside your Linux system, for instance.

In the main, this is wouldn't be particularly exciting, what with emulators having been the daily bread in computing since the stone ages. QEMU. however. recently grew a kernel module that provides x86 virtualization instead of emulation. This means that instead of recompiling x86 instruction sequences into native code (the additional abstraction meaning loss of efficiency), it can now run the code directly. This makes it suddenly much faster, and in fact brings it closer to vmware in performance and functionality.

Some other virtualization projects, such as Xen, are not able to run Windows because the guest operating system is not perfectly virtualized due to limitations of x86 hardware. The trick here is to dynamically translate some offending opcodes that break virtualization in guest OS's code into marker opcodes and then emulate the original opcodes when the x86 CPU hits these markers.

The KQEMU module is not free software at the moment of writing, although it can be had for no charge. The author apparently wishes some kind of compensation for his efforts.

Ok, so how to setup Windows 2000 inside QEMU

You need QEMU version greater than 0.6.1. That version simply never worked for me. The final installed image was always unbootable. At this moment you can snatch the CVS tree from gnu.savannah.org and compile that. I suggest using 0.6.2 when it's released.

Additionally, you should install zlib1g-dev and libsdl1.2-dev and linux-headers / kernel-headers for your current kernel version. Also drop the kqemu module inside the qemu directory.

At this point you should be ready to run the emulator. However, before getting to that point, we will probably have to prepare a disk image for ourselves so that we can install the W2K somewhere. QEMU comes with qemu-img that can be used to build a disk image. 4 GB is plenty for W2K, so here we go:

Now you need to do the usual steps inside the installer: choose partitions, make the partitions, install the OS, etc. Yada yada yada. What it boils down to is that eventually you'll be prompted to remove the CD and reboot.

Use ctrl+alt+2 to switch to monitor. Here you can issue emulator commands. One simple command is for instance eject cdrom that allows you to remove the CD. Another one is quit to terminate the emulator.

At this point you should have a W2K image that's good for installing MS updates and any additional software.

Using the image

Plan ahead. There's no reason to ever face the ordeal of installing w2k again. QEMU can be used with the current disk-image frozen as it is for forever, all changes being made either to temporary snapshots or to another file. The temporary snapshot is great for throwaway usage like using W2K just to launch IE so you can check our website with MicroSoft's brand of excrement. That's the qemu -snapshot option. Additional bonus: near-perfect repeatability of whatever you are using the system for.

However, if you plan to install software or otherwise continue building up your W2K install, here's a command that is of enormous interest: qemu create -b w2k-fresh-install.img w2k-development.img. When you give the w2k-development image to QEMU it will write new data only to that image but read all the old, untouched data from the w2k-fresh-install. This allows you to safely checkpoint what you are doing, for instance before installing new software or service packs you would do well to start a new image, and only after it has worked out okay, do a qemu-img commit w2k-development.img to fold the changes in this image to its base-image.

The effects of a commit can not be reversed, so be careful. As a thumb rule I suppose there's no need to commit at all, usually. Only do it if the new disk files start to approach the originals in size, and you're sure you no longer need the original -- maybe some folding up would be good for you at that point.

Compressing the image for conserving disk space

QEMU originally makes these images in what it calls raw format. These are sparse files (meaning they got holes in them, disk area never used is never allocated from the physical media). This may be practical if all you are doing is keeping the data on just one system. But if you would like to use rsync or scp to move data to other systems, the handy sparsiness feature will be lost during these copies. Therefore, for maximum wieldiness, it's best to compress the image. QEMU contains transparent compression module, which you can invoke as follows:

qemu-img convert w2k-development.img -c -O qcow w2k-development-compressed.img

The -c there is for compress. Otherwise this would be simply a format change. (The qcow format does not use sparse files, so it would still be useful for our purposes.) With the compression, a fresh w2k install can be had in some 600 MB handy image. You may even be tempted to burn it on CD, along with some statically linked copies of essential qemu binaries...

In case you like the raw files, you can use the perforate package's zum to restore the sparsiness on the files. zum builds a copy of the source file and then replaces the original with the copy, but is careful not to copy long stretches of zeroes to the new file, thus allowing the filesystem to use its sparse logic to store the file.