At this point, we should have a working set of qemu binaries loaded in /tmp/qemu, a ISO image or CDROM copy of the Knoppix Live CD and a little experience starting up a Knoppix instances under QEMU in a Solaris 10 Host.

Next, we need to create a disk image file that we can use to load an OS image on. The command used to create these images file is called qemu-img. The qemu-img binary supports multiple formats including raw, cow, qcow and vdmk to name a few. Raw format appears to be the most platform neutral and independent, while the most versitile format appears to be qcow, which supports compression and encryption, as well as copy-on-write (COW). To create our image file to load Knoppix onto, run the commands:

     cd /export/src/images/Knoppix_3.8
     /tmp/qemu/bin/qemu create -f qcow knoppix.img 4G

You can verify that it built out the image the way you expected to by invoking the command:

     $ /tmp/qemu7/bin/qemu-img info knoppix.img                                                                   
     image: knoppix.img
     file format: qcow
     virtual size: 4.0G (4294967296 bytes)
     disk size: 17K

Starting Knoppix LiveCD to install on a QEMU Disk image

As it turns out, if you don't have your hard disk partitions setup and the /dev/hda1 partition doesn't have an ext2fs on it, running "tohd=/dev/hda1" at the Knoppix prompt doesn't work. So the first thing to do is to boot the Knoppix image off of CDROM or ISO image, yet add in the virtual disk image defined by "-hda knoppix.img". Because we're stil specifying "-boot d", QEMU will boot off the KNOPPIX CD or ISO image first.

     /tmp/qemu/bin/qemu -cdrom /vol/dev/rdsk/c1t0d0/knoppix -user-net \
              -enable-audio -pci -m 512 -k en-us -boot d -hda knoppix.img

Once Knoppix is booted, open a Konsole window from the KDE toolbar at the bottom of the Knoppix screen (It looks like a terminal), and type:

     $ su   # no password required for Knoppix
     # fdisk /dev/hda

From the fdisk partition menu, create a primary Linux partition on partition 1 of 3600MB and a Linux Swap partition on (0x82) on partition 2 of 500MB (remainder of the disk). Make partition 1 the active partition, but I'm not certain that because of how QEMU boots a system on whether or not this make any difference. But that's how you do it with a normal hard disk so let's do it that way here. Write out the changes to the disk and then do a mkfs /dev/hda1. Once that is complete, Halt the Knoppix image and restart it with the above command line. Once you see the Knoppix prompt again like this type:

     boot: knoppix screen=1152x864 dma tohd=/dev/hda1   # 1152x900 works under JDS/Linux Host, but 1152x864 is all Solaris can do

and then watch the disk spin for a bit, with the screen looking somewhat like this. When it's all done, Knoppix will boot normally. [On my 2Ghz Athlon system that I did this test on, the transfer rate racked up an impressive 30Mb/second for transferring the image from the ISO to the virtual disk on /dev/hda1.] What this actually does is just copy over the directory structure on the CDROM onto the Hard disk. (Gee, I thought you could install Knoppix to the Hard disk from the boot menu). Now, when you boot from your cdrom, you can add "fromhd=/dev/hda1" which will make it boot off the hard disk image. Given all things, this is probably not a big win, given that running from the CDROM or ISO image isn't going to be the limiting factor. However, it's a very quick test to make sure your virtual hard disk is writable, and you can boot from the image using the CDROM or ISO image. The start line for qemu doesn't change from the previous run, but how we invoke Knoppix is different. At the boot prompt, type:

     boot knoppix screen=1152x864 dma fromhd=/dev/hda1

Making Knoppix boot very fast while using a HD install

This morning, we looked at how we can make QEMU boot a system much faster using the savevm/loadvm commands from the monitor. Once the above system has booted, and you've got all the applications setup the way you want them, then type CTRL-ALT-2 to go into the QEMU monitor. Once inside the QEMU monitor, type "savevm knoppix-save.vm" and then "quit". The file knoppix-save.vm should be in directory /export/src/images/Knoppix_3.8

Restarting a QEMU savevm'd image

Once again, we add another parameter to the startup line for the qemu instance. To get the very quick restart of a running image, we run:

     /tmp/qemu/bin/qemu -cdrom /vol/dev/rdsk/c1t0d0/knoppix -user-net -enable-audio \
           -pci -m 512 -k en-us -boot d -hda knoppix.img -loadvm knoppix-save.vm

and in about 10 seconds on my PIII/1Ghz with 1.5G of Ram, my Knoppix instance is back where it was when I ran the savevm command from the QEMU monitor.

After you restore an image like this, I found out that you should do a [CTRL-ALT-1] to reset the virtual machine's system state, which explains the weirdness I saw with the keyboard and restored image

I wish I had found this sooner. Waiting 10-15 minutes for something to bootup and enumerate all the devices is pretty hideous. Makes me really want to see a Solaris kqemu module for QEMU get written so we can have the near machine speed that the Linux folks have (I run JDS3/Build 32 on my Toshiba M2, and with kqemu it's really really nice, but this blarg is about making QEMU work on Solaris).

Yesterday, I talked about QEMU and what it can do. As I've been working with it, there are a couple of reasons I want to run an OS under QEMU with Solaris 10 as my Host.
1) I need/want to run some Windows applications that I don't have under Solaris (say acrobat 7 or real player).
2) I want to test an OS out without having to frag my laptop again (as I've been doing since last year with Solaris 10 in beta, and now Solaris 10.1 [aka 11] in beta)

Getting started with QEMU

Assuming you can follow the download and patching of qemu-0.7.0 from yesterday, then running of

     ./configure --prefix=/tmp/qemu --with-oss=yes --oss-inc=/opt/oss/include; gmake install

the next thing you need to do is setup a working area. For the purposes of the demostration, I use /export/src/images as my top level directory where I keep the QEMU images. I also use /export/src/iso as the location for any CDROM image iso files I use to boot/install a guest OS under QEMU.

     $ mkdir -p /export/src/iso /export/src/images
     $ cd /export/src/images
     $ mkdir Knoppix_3.8
     $ cd Knoppix_3.8

The great thing about Knoppix is the ability to boot a complete OS on a PC without having to touch the hard disk, not to mention it's free and they have several yearly updates to the code base. These disks have become great recovery tools and have a lot of different uses. My favorite use of Knoppix is a test of how QEMU is running. Since it seems to take about 4 hours to install Solaris Express from a DVD image in a QEMU session, I'm really not interested in finding out it doesn't work after 4 hours. Plus, since it doesn't really require any disk space requirements at all, starting Knoppix under qemu is dead simple. Not everyone has Windows 98, 2000, XP, etc, and the time requirements to actually get comfortable with it are minimal compared to the amount of time it's taken me to get things like a 5 CD iso build of JD3 Linux/Build 32 installed, or Solaris Express on DVD. So I think is a pretty good example, plus I think any tech ought to be carrying a Knoppix disk, or something like it.

Getting Knoppix 3.8

Assuming you've gotten a Knoppix 3.8 iso image from your local bittorrent, and burned it to a CDROM, this is all you need. Blastwave has a version of bittorrent for Solaris, so getting a copy is just a matter of doing a "pkg-get -i bittorrent", assuming you loaded pkg-get from www.blastwave.org. (It seems that Knoppix V 3.7 was the last version available via FTP)

Booting Knoppix 3.8 from a CDROM under QEMU

So either you have an ISO image sitting in a directory like /export/src/iso/KNOPPIX_V3.8.1-2005-04-08-EN.iso or you actually burned the image onto media and it's in a CDROM drive in the Solaris system. If you are running vold (volume managment), we need make sure we can see the physical device.

$ eject -q cdrom       # to get the volume name of the knoppix disk
                       # it should be something like /vol/dev/dsk/c1t0d0/knoppix
                       # but we really need to give it the rdsk name so it can boot it.
#
#  To start Knoppix under QEMU if using a real CDROM under Solaris with vold enabled, try
#
$ /tmp/qemu/bin/qemu -cdrom /vol/dev/rdsk/c1t0d0/knoppix -user-net -enable-audio -pci -m 512 -k en-us
#
#  To start Knoppix under QEMU if using an ISO image file under Solaris, try
#
$ /tmp/qemu/bin/qemu -cdrom /export/src/iso/KNOPPIX_V3.8.1-2005-04-08-EN.iso -user-net -enable-audio -pci -m 512 -k en-us
#
#
# -user-net      : enables the slirp network stack that QEMU presents to the guest OS. This is default
#                  if you don't have tunnels (The tunnel code in QEMU for solaris is not quite there yet)
# -enable-audio  : have QEMU present a Soundblaster 16 to the virtual machine
# -pci           : have QEMU present a PCI bus.  The opposite is ISA, but at this point is only useful for
#                  things like DOS. Solaris Newboot as a guest chokes on "-isa"
# -m 512         : the ammount of physical memory to be given to QEMU for this guest OS.
#                  my system has 1536MB so giving it 512 is not too bad. This variable you
#                  will need to be careful with.
# -k en-us       : Sets up the keymapping for QEMU. Seems to be important if you're doing a savevm/loadvm,
#                  which I'll talk about later.
#

What you see immediately is a screen that looks like this. At this prompt type:

     boot knoppix screen=1152x864 dma # or screen=1024x768, something workable with your display window
                                         # 1152x900 works in JDS but for some reason doesn't work on Solaris. Go figure.

This takes about 15 minutes to boot on my PIII/1Ghz, and about 7 minutes to boot on my 2GHz Athlon XP. What this gives you is a working Knoppix instance running in QEMU under a Solaris host. Assuming you don't have any compile problems, and your Solaris host has a valid network/DNS mappings, your Knoppix guest OS should have an eth0 interface with an address of 10.0.2.15. Since QEMU provides a virtual DHCP server to the client (How else did it get that 10.0.2.15 address), and proxies DNS from a virtual host using 10.0.2.3 and having a defaultroute of 10.0.2.2, networking for the most part should just work. One big caveat - You cannot ping out of a guest OS to the host or any other address because SLIRP does not support ICMP. Telnet, FTP, SSH/SCP, X11, VNC and Samba all work without issue.

To verify, open a kconsole window (In your Knoppix QEMU Guest) , and run:

     $ ifconfig eth0

and see

     eth0      Link encap:Ethernet  HWaddr 52:54:00:12:34:56  
               inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
               inet6 addr: fe80::5054:ff:fe12:3456/64 Scope:Link
               UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
               RX packets:634 errors:0 dropped:0 overruns:0 frame:0
               TX packets:571 errors:0 dropped:0 overruns:0 carrier:0
               collisions:0 txqueuelen:1000 
               RX bytes:267069 (260.8 KiB)  TX bytes:53495 (52.2 KiB)
               Interrupt:11 Base address:0xc100 

(YES, your networking will look *exactly* like that, because the "virtual machine" presented by QEMU to the guest OS looks the same.)

One thing that occurs when you click your mouse into the QEMU guest OS window, is that QEMU grabs it, and doesn't let go of it. If you feel like you've lost your mouse, hit CTRL_ALT and see if it releases your mouse so you can go outside the QEMU window.

Start firefox and surf the web (though if your Solaris host uses a web proxy, so should the Guest OS's brower). You can ssh to your Solaris host (make sure to use the real network address of the host, not 127.0.0.1). FTP also works, but I find that often you may have to use passive mode ("quote pasv") in the ftp client to pass data back and forth. I've found ssh/scp much easier to work with when dealing with a QEMU guest OS and the user-net stack.

Booting Knoppix Really Fast

QEMU has the ability to save the state of the local VM, and restore back to it from the command line. How we do this is by going into the QEMU monitor using [CTRL-ALT-2]. The monitor is a command line tool which provides a set of of tools and features, as displayed by this help menu

     QEMU 0.7.0 monitor - type 'help' for more information
     (qemu) help
     help|? [cmd] -- show the help
     commit  -- commit changes to the disk images (if -snapshot is used)
     info subcommand -- show various information about the system state
     q|quit -- quit the emulator
     eject [-f] device -- eject a removable media (use -f to force it)
     change device filename -- change a removable media
     screendump filename -- save screen into PPM image 'filename'
     log item1[,...] -- activate logging of the specified items to '/tmp/qemu.log'
     savevm filename -- save the whole virtual machine state to 'filename'
     loadvm filename -- restore the whole virtual machine state from 'filename'
     stop  -- stop emulation
     c|cont  -- resume emulation
     gdbserver [port] -- start gdbserver session (default port=1234)
     x /fmt addr -- virtual memory dump starting at 'addr'
     xp /fmt addr -- physical memory dump starting at 'addr'
     p|print /fmt expr -- print expression value (use $reg for CPU register access)
     i /fmt addr -- I/O port read
     sendkey keys -- send keys to the VM (e.g. 'sendkey ctrl-alt-f1')
     system_reset  -- reset the system

Assuming you started your session as I described, you can hot-key between the QEMU guest, the QEMU monitor, and the QEMU serial port. CTRL-ALT-1 from the MONITOR or QEMU serial port will take you to the Guest OS. CTRL-ALT-2 from the Guest OS or the QEMU serial port will take you to the MONITOR. CTRL-ALT-3 from the GUEST or the MONITOR will take you to the QEMU serial port.

Saving a running QEMU Guest OS session

Use CTRL-ALT-2 to go to the MONITOR and type

     savevm knoppix-save.vm

then

     quit

You will find a file created in the local directory (still in /export/src/images/Knoppix_3.8, right?) called knoppix-save.vm which contains the memory contents of the virtual machine. Since we're running off of a CDROM iso image, it doesn't matter about what's in the "file system". We're not using one yet. As you can see, the more you do with QEMU, the more command line parameters you need, which is why I wrote the script to do this. There are some java GUI's, but I'm a command line kind of guy, so I write my own stuff. Restart the Knoppix session using the command from above plus a new parameter -loadvm knoppix-save.vm and make sure that the amount of memory you originally specified at the time you saved this instance is the same that you start the -loadvm knoppix-save.vm: like:

     /tmp/qemu/bin/qemu -cdrom /vol/dev/rdsk/c1t0d0/knoppix -user-net -enable-audio \
                        -pci -m 512 -k en-us -boot d -loadvm knoppix-save.vm

This will have the Knoppix system back up in about 10 seconds. Once the system is back up, switch to the QEMU console with [CTRL-ALT-2], then switch back to the VM using [CTRL-ALT-1]. This appears to prevent the weirdness I'm seeing with a Konsole window and the keyboard interaction, where the keyboard doesn't seem to work correctly. But still, it's much faster than the 15 minutes it took to actually start the virtual machine from a dead stop.

This is all fine and good in testing. However, the savevm/loadvm feature is more likely to be used on Operating Systems that have a read/write disk, and not a read-only disk such as a CDROM or ISO image. This is where it gets tricky. In order to prevent corruption of the Hard disk image file containing the Operating System, if you use the savevm/loadvm feature, it is imperative that you not boot the disk image without the -loadvm and it's statefile. Otherwise, some pretty serious corruption could take place.

QEMU is a generic and free open source process emulator, and has the ability to run practically any operating system across platforms.

Well, almost.

I found this code about a month ago, and with some help from other Solaris type developers, google and the qemu-developers mailing list, I've been able to get the code working under Solaris 10, 32-bit X86. So far, I've been able to install Win98SE, Win2KPro, Win2K Svr SP4, WinXP Home upgrade and Win 2003 Server under QEMU on a Solaris host. In addition, JDS3, Solaris 10, and Solaris Express work, as well as things like the Knoppix live CD.

Windows products are most finicky. Win98SE actually runs pretty decently on my Toshiba M2, now that I added configure support for OpenSounds' OSS Audio driver. I've got an image that has all the latest patches, Real Player, Adobe Acroread 6.0, Quicktime, Flash/Multimedia plugins and the latest Mozilla product suite (Firefox, Thunderbird and Mozilla). Why Windows 98SE? It's very lightweight, and there are two patches for it. One which implements the halt instruction properly so when I leave the qemu instance idle, it's not sucking the CPU down. And second, the power management actually turns itself "off" so I don't actually have to quit from the qemu monitor session (Which you get into by typing "ctrl-alt-2")

However, getting Win2K, XP Home and Win 2003 installed can be somewhat traumatic. The emulation is not quite perfect, so the virtual machine tends to hiccup, especially during installs. There is a well-known bug when installing Win2K under QEMU, and manifests itself by filling up the virtual disk. This can be worked around by going into the QEMU monitor (ctrl-alt-2) and stopping the instance and restarting. I've done this a few times, and mostly it never worked. I eventually figured out from a QEMU user's mailing list posting that you can work around this problem by adding -hdachs cylinders,heads,sectors to the the start line for qemu, such that the virtual disk is has 16 heads and 63 sectors/per cylinder, and just do the math to divide the size of the virtual disk by (16*63*512) to get the number of cylinders.

However, I've found out that often times when I've gotten a Windows install to work, I can't patch it. Some technology called Slipstream which allows you to take a Windows install CD and add patches to it becomes very attractive, especially since the patching isn't quite 100%. I'll eventually figure out if this works and post how it goes.

The most current release of QEMU (0.7.0) available at http://fabrice.bellard.free.fr/qemu/download.html and the patch against qemu-0.7.0 to make it compile under Solaris 10/X86 is found at qemu-0.7.0-solpatch-050504. To configure and build QEMU-0.7.0 for Solaris, I used gcc-3.4.3, gmake, gnu fileutils and libSDL-1.2.8 from www.blastwave.org. If you've never used Blastwave's tools, checkout the website. It has a script called pkg-get which is Solaris derivitive of the Debian apt-get tools. The Blastwave Solaris packages all have dependencies, which pkg-get will automagically download and install for any package you download. In addition, the sound drivers at www.opensound.com can be downloaded and used for several months if you don't want to buy a license. They definitely seem to work better than using the stock Solaris audio driver, but that could just be a feature of the SDL library.

Once you have the the code downloaded, cd to the directory holding qemu-0.7.0/ directory and run

gpatch -p0 < qemu-0.7.0-solpatch-050504 

to patch the current code. The configure script can be run like this depending on whether you have OSS sound drivers or not.

./configure --prefix=/tmp/qemu --with-oss=yes --oss-inc=/opt/oss/include

or

./configure --prefix=/tmp/qemu --with-oss=no   # if you don't have the OSS Sound drivers

If you're wondering why I used the prefix to be in /tmp/qemu - The code is quite "beta". You don't have to be root to run the code and given the fact that development on the code is going pretty quickly, I find this a very easy way to test out a set of patches or changes, without having to worry about stuff being left on the hard drive.

Here's an example shell script I use to start most images. I edit the first lines if I want to be able to get back to the virtual machine using the redir parameters :

#!/bin/bash
#
#CONFIG - set the USE variables to a value if you want their config
#         value below to propogated into the QEMU start line.
#
USE_LOCALTIME=1
USE_SSH=1
USE_TELNET=1
USE_FTP=1
USE_FDA=
USE_CDROM=1
USE_AUDIO=1
USE_BOOT=1
USE_KEYMAP=1
USE_LOADVM=
USE_MEMORY=1   # should always have this defined
USE_HDA=1
#
##########################################################################################
#
# LOCALTIME_CONFIG : "-localtime" # whether to use localtime from the bios or not
#
LOCALTIME_CONFIG="-localtime"
#
# SSH_CONFIG : -redir tcp:5022:10.0.2.15:22 - redirect tcp port 5022 on the host OS
#                                             to tcp port 22 in the guest OS.
#            : -redir udp:5022:10.0.2.15:22 - redirect udp port 5022 on the host OS
#                                             to udp port 22 in the guest OS
#  This SSH_CONFIG is for allowing systems outside the HOST system to access the
#  guest OS via SSH on port 5022 on the Host.  The TELNET_CONFIG and FTP_CONFIG
#  work the same way.  FTP is a bit funky, in that you have to use passive mode
#  often because of how the port redirector code works since it's part of the host.
#
SSH_CONFIG="-redir tcp:5022:10.0.2.15:22 -redir udp:5022:10.0.2.15:22"
TELNET_CONFIG="-redir tcp:5023:10.0.2.15:23"
FTP_CONFIG="-redir tcp:5021:10.0.2.15:21 -redir udp:5021:10.0.2.15:21"
#
# FDA_CONFIG : "-fda /vol/dev/rdsk/floppy/unnamed_floppy" to give access to the real floppy
#              "-fda /export/src/iso/DU.img" to give access to the virtual floppy image DU.img
#
FDA_CONFIG="-fda /export/src/image/Knoppix_3.8/save_floppy.img"
#
# CDR_CONFIG : "-fda /vol/dev/rdsk/c0t0d0/knoppix" to give access to the real cdrom
#              "-fda /export/src/iso/Knoppix-3.8.iso" to give access to a virtual cdrom through the iso image
#
CDR_CONFIG="-cdrom /vol/dev/dsk/c0t0d0/knoppix"
#
AUDIO_CONFIG="-enable-audio"
#
# BOOT_CONFIG : "-boot c" to boot off of first hard disk
#               "-boot d" to boot off of second hard disk or CDROM
#
BOOT_CONFIG="-boot d"
#
# KEYMAP_CONFIG : "-k "
#
KEYMAP_CONFIG="-k en-us"
#
# LOADVM_CONFIG : "-loadvm ${LOADVM_FILE}"
#
LOADVM_FILE=knoppix_save.img
if [ ! -f "${LOADVM_FILE}" ]; then
  unset USE_LOADVM
else
  LOADVM_CONFIG="-loadvm ${LOADVM_FILE}"
fi
#
# MEMORY_CONFIG : "-m 512" to allocate 512MB for the QEMU instance
#
MEMORY_CONFIG="-m 384"  # to allocated 384MB of memory for QEMU
#
# HDA_CONFIG : "-hda imagefile.img" # which file is ide controller 0, target 0
#
HDA_CONFIG="-hda knoppix.img"

set -x
/tmp/qemu/bin/qemu ${USE_LOCALTIME:+${LOCALTIME_CONFIG}} \
        ${USE_SSH:+${SSH_CONFIG}} \
        ${USE_TELNET:+${TELNET_CONFIG}} \
        ${USE_FTP:+${FTP_CONFIG}} \
        ${USE_FDA:+${FDA_CONFIG}} \
        ${USE_CDROM:+${CDR_CONFIG}} \
        -user-net  \
        ${USE_AUDIO:+${AUDIO_CONFIG}} \
        ${USE_BOOT:+${BOOT_CONFIG}} \
        ${USE_KEYMAP:+${KEYMAP_CONFIG}} \
        ${USE_LOADVM:+${LOADVM_CONFIG}} \
        ${USE_MEMORY:+${MEMORY_CONFIG}} \
        ${USE_HDA:+${HDA_CONFIG}}
stty sane
exit 0

This script sets up to run a qemu session with a 384MB memory segment, has a virtual CDROM that is actually the physical cdrom device in Solaris containing the Knoppix CD. You may also use an ISO image of a disk. "-boot d" tells qemu to boot from the CDROM, as opposed to "-boot c" which would be to boot from the first hard disk. The "-user-net" is a slirp based network config which uses a NE2000 driver interface to the guest OS, to make a connection out of the machine.

SLIRP networking in QEMU

The QEMU process provides a network layer to the Guested OS. As an example, to get Solaris 10 working under QEMU, you have to use the Install Time Update found at the Community Boot Driver ITU Floppy which has a specially modified version of the ni (ne2000) driver written by Masayuki Murayama and modified by Juergen Keil to work in the QEMU guest running Solaris. If you are using the -user-net option, the QEMU process sets up it's own internal DHCP and DNS servers, as well as a default router. The default address for the client is normally 10.0.2.15. This works very well, but because it's a user level process, it's much harder to get back to the virtual machine. The above redir parameters setup access back to the virtual machine, by having QEMU open up listeners on the ports specified, and then redirecting the traffic down through the slirp stack to the guest OS. An annoying side effect of using some internal software I use called inetmenu (which configures the networking correctly at boot time) caused my systems' default name to have a address of 127.0.0.1. What this did was screw up the "source" ip address on the packets entering the QEMU guest OS, which it never responded to. Eventually I figured out that problem, and solved it by doing a "telnet 192.168.30.151 5023" instead of a "telnet 127.0.0.1 5023". The reason this works on most systems is the hostname is usually not tied to localhost or 127.0.0.1. Once I use the real IP address of the Host system, qemu properly translated the packets to the guest OS, and I was able to log in.

Video as part of QEMU

The video config of the Virtual machine is a Cirrus Logic 5446. Under Solaris Xfree86 (Xsun), you can squeeze 1152x900 at 16-bits no problem. Getting it to work with Xorg is a little trickier. Knoppix has no problem driving the video at 1152x900 @ 16-bits.

Audio as part of QEMU

Audio config is a sound blaster 16, which seems to work ok. Though I've noticed better sound quality when using the OSS sound drivers. I think the libSDL is not very well optimized and I haven't had time to recompile it with a better compiler and under Solaris 10.

Another nice feature is the image files are easy to backup. All you need is disk space. I used a copy of a Win98SE image that I had installed to do the XP Home Upgrade. I didn't have any luck booting from the WinXP Home upgrade disk and having it recognize the Win98SE disk (or NT4 or any other valid Windows media I had). However, since you can start the upgrade to XP Home by booting into Win98SE and running the setup off the CDROM image, that's how I successfully got a working Win XP Home image. But QEMU is probably the biggest use of disk space that I have these days as I'm constantly retesting images and such.