Quoting from TechNewsWorld

Imagine walking up to a friend running Windows on a laptop and asking to borrow the machine for a moment. You plug a pendrive into its USB port, open a window that boots into Linux, log on to a Web site, and download a file, then close the window, remove the pendrive, thank your friend, and walk away -- leaving your friend's Windows session unaffected.

While that scenario has a high coolness factor, its utility is a bit limited. Howver, what if you want to install a new application on your Windows system and you're unsure of that application's trustworthiness? You quickly launch Windows in a virtual environment and start the app in that environment; sure enough, it crashes horribly.

You shrug, close the virtual environment, throw it away, and resume your normal Windows activities. No harm done.

Users of VMware's powerful virtualization system have enjoyed this capability for some time. Now, the open source  world has a tool that allows similar powers: QEMU, the brainchild of Frances Fabrice Bellard. While not as robust as commercial virtualizers, QEMU's features set the stage for not only running x86 Linux on x86 Windows -- and vice versa -- but running just about any OS, regardless of processor, on Windows and Linux.

Behind the Magic

Strictly speaking, QEMU is an emulator, not a virtualizer. That is, the code of the "guest OS" is translated and executed by the processor of the "host OS," so a QEMU-enabled system host running x86, 64-bit x86, or PowerPC -- testing is underway to add Alpha, Spare, ARM, and IBM S/390 -- can run a guest OS executing x86, ARM, Spare, PowerPC, or MIPS instructions. A version for Mac OS X  is still in its infancy, but on the way. The full matrix of supported guest OSes that have been verified for each host OS is large, and in a constant state of flux.

QEMU performs its emulation magic using a technique called "dynamic binary translation." As guest code executes, QEMU identifies "translation blocks" or "TBs" -- sequences of instructions terminated by jump or branch instructions. TBs execute linearly because there are no branches within the blocks, which considerably minimizes the work QEMU must perform to emulate that code.

QEMU then passes through the TB, translating each instruction to equivalent "micro operations" that will be executed on the host. Some optimization is performed during the translation (such as removing redundant operations whose results are known not to have any effect outside of the TB), after which the converted micro operations code is executed on the host.

In the case of x86-on-x86 execution, QEMU does become a virtualizer. Much of the emulation is bypassed, and the new KQEMU Accelerator module allows QEMU to run both user and kernel-mode code at near full speed. (User code executes at full speed; according to an estimate by Bellard, 90 percent of kernel-mode code will execute at full speed with the accelerator enabled.)

When the accelerator is activated, the QEMU emulator simply examines the code to verify that it can be executed natively, and dispatches it to the accelerator. The code runs at full speed until the next exception, interrupt, or virtual device access; QEMU then steps in and provides the service needed to maintain the virtual environment.

One note: The accelerator module is closed-source. It's still free and can be used in a commercial application, but you need permission to redistribute it.

Virtual Comparisons

There are so many attractive aspects to QEMU, it's hard to know where to start. For example, on Linux, running it in "user-mode emulation" allows you to execute a Linux app written for a CPU other than the one running in your host system. QEMU intercepts calls to the Linux kernel -- from the guest app -- and manages the marshalling of data in both directions.

Consequently, even if the endianness of the host is different from that of the guest, QEMU will take care of it.

I was also smitten by the wealth of command-line options available. For example, you can configure the guest environment to recognize up to two virtual floppies and four virtual hard drives. If you want to protect the content of any of your virtual drives from being overwritten, you can start QEMU in "snapshot" mode, which diverts all write operations to a temporary directory.

Even better, if you later decide you want to commit those write operations, you can do so through the QEMU monitor. You can adjust the guest OS's memory, turn sound hardware on and off, enable and disable USB drives, and on, and on. If that's not enough, QEMU can also emulate an SMP system.

I wasn't able to test this, but the documentation claims that you can simulate up to 255 virtual processors.

To get an idea of how well QEMU performs next to VMware, I used Puppy Linux, a small-footprint Linux distribution. The Puppy Linux image takes less that 100MB and fits easily on a USB pendrive; nevertheless, it includes a remarkable array of applications. I downloaded a QEMU-enabled version of Puppy Linux and VMware.

Both were the same Linux release, and I adjusted the VMware version so both had 256 MB available.

For my test, I downloaded a moderately large JPEG file from the www.photo.net site and performed a blur operation in the mtPaint application provided with Puppy Linux. On my 1GHz Dell system, the VMware version ran approximately 10 percent faster than the QEMU version.

Note that this was a comparison of raw processor execution; I imagine that applications that make heavy use of virtualized hardware -- such as an RDBMS performing a lot of seek operations -- would produce a wider gap, with VMware outperforming QEMU even more.

At this point, QEMU will be most attractive to a small or midsize software development organization that needs to create a testbed of various OS flavors, and has decided that QEMU's zero cost overwhelms its performance shortcomings. QEMU's performance can't compete with commercial virtualizers -- at least, not yet.

Even so, with the capabilities it has -- its ability to run in multiple systems; the ease with which new virtual machines can be created; the performance enhancement of the Windows accelerator -- QEMU can hold its head high next to even the likes of VMware.

Read and comment on the original story, here.