Mister Muffin Blog

Works like a breeze - only note to NOT use a qcow diskimage (will be horribly slow) and use the following qemu options to select network and sound hardware that windows knows about out of the box:

To create a disk image use one of the following commands depending on whether your system has fallocate support or not:

$ dd if=/dev/zero of=windows.img bs=1 count=1 seek=3000MiB
$ fallocate -l 3000MiB windows.img

If your filesystem supports sparse files, then your image will not immediately occupy its full size on your disk. Then start qemu like this:

$ qemu-system-x86_64 -k en-us -enable-kvm -hda windows.img \
> -cdrom windows_xp.iso -net nic,model=rtl8139 -net user \
> -soundhw ac97 -m 1024

For bare Windows XP you do not need to specify the -m 1024 option. Windows XP will be quite happy with the default of 128 MiB RAM. But given the amount of RAM current hosts have available I usually throw in a bit extra.

My roommate akira used this setup to connect to a university distance course which required the students to use the proprietary Adobe Connect software to connect to the classroom. It turns out that with above setup, the speaker and microphone forwarding between the host and the Windows XP guest worked out of the box. Getting a USB webcame to work turned out to be a bit more tricky but can be accomplished by adding the following to the qemu invocation above:

$ qemu-system-x86_64 [...] \
> -readconfig /usr/share/doc/qemu-system-common/ich9-ehci-uhci.cfg \
> -device usb-host,vendorid=0x046d,productid=0x0825,id=webcam,bus=ehci.0

This will attach the hosts usb device with id 046d:0825 (a Logitech webcam in this case) to the qemu guest. It doesn't even seem to be necessary to unload the kernel module responsible for the webcame (uvcvideo in this case) from the host. The guest seems to be able to cooperate well with it. The interesting bit of above invocation is the -readconfig argument which points to /usr/share/doc/qemu-system-common/ich9-ehci-uhci.cfg which is a hardware configuration for qemu written by Gerd Hoffmann. It creates a USB 2.0 adapter with companion USB 1.0 controllers as a multifunction device on one of the guests PCI slots. This has the advantage that attaching any USB device from the host to the guest bus ehci.0 will work no matter whether the device is USB 1.0 or 2.0. If you know what you are doing you can always specify -usb or -device usb-ehci,id=ehci, depending on the USB standard of your device and then attach it to the right bus. But the -readconfig solution will work out of the box in both cases. You can read more about qemu and USB in the excellent documentation which can be found at /usr/share/doc/qemu-system-common/usb2.txt.gz or at docs/usb2.txt in the qemu git which was also written by Gerd Hoffmann.

In case you want to read data from the guest with the virtual machine switched off you can mount the disk image you created earlier by doing:

mount -o loop,offset=32256 windows.img windows

Or find out the offset with fdisk: switch display units to sectors with 'u' and print the partition table with 'p'. Then do the math for the proper partition offset. With a default windows xp install it will be 63 sectors times 512 bytes = 32256 bytes.