QEMU: a Multihost, Multitarget Emulator
A few months ago, I suddenly found myself with an I-need-to-run-just-one-Windows-application problem. When I had started at my current job, I was determined finally to be Windows-free at work, just like I have been at home for several years. To that end, after I had unpacked my shiny new work computer, I erased Windows, installed my current favorite Linux distribution, and set up Ximian Evolution to connect to the Microsoft Exchange server. I thought that I had finally arrived at Linux nirvana.
It was not to be.
Microsoft's Exchange mail server has this feature where a team, or group of people, can access a shared mailbox. My manager thought it would be a good idea to set up one for our team and have clients send e-mail to that address instead of to each of us individually. With the shared inbox in place, I found myself needing to check it several times a day.
Evolution can connect to shared mailboxes, but not in the way I have to connect to mine. My department, being Linux-friendly and security-conscious, is not on the corporate network, so those who are on Windows-based systems in my department need to configure their Outlook e-mail client to connect to the Exchange server over HTTP. Evolution seems to support connecting to shared mailboxes only when you are on the same network as the Exchange server, not via the HTTP method.
There was no way around it. I had to run Outlook. And not just any version. I had to run Outlook 2003, which is the version that can use the HTTP-connection method. The problem with Outlook 2003 that older versions of Outlook do not have is that it is not compatible with Wine or CrossOver Office from CodeWeavers, which ruled out what I considered to be the obvious first-choice solution for running it on Linux.
My options were therefore:
Go back to using Windows.
Find another way to run Outlook 2003.
I did not want to go back to using Windows, not for only one application, so I started looking around for answers to the other option. My requirements were simple: it had to be able to run Outlook 2003, it had to be cheap, it had to be usable and it had to be reliable—no crashing. VMware is an obvious choice for this sort of thing, but as I was footing the bill myself, VMware was not an option. After a little bit of searching, I found an excellent VMware alternative: QEMU.
According to its home page: “QEMU is a FAST! processor emulator using dynamic translation to achieve good emulation speed.”
QEMU is a multihost, multitarget emulator. QEMU will run on x86, x86-64 and PowerPC systems, and it can emulate x86, x86-64, ARM, SPARC, PowerPC and MIPS architectures. For most of these, it can be run in two ways: full-system emulation and user-mode emulation. For details on which modes are supported for which architectures, check out the link in the on-line Resources.
User-mode emulation allows you to run Linux binaries compiled for other architectures on your machine. This is great for application development and testing, but I was more interested in full-system emulation.
Full-system emulation emulates a complete computer system from the BIOS on up to things like video and sound cards. For x86 system emulation, QEMU simulates a machine with the following peripherals:
i440FX host PCI bridge and PIIX3 PCI to ISA bridge.
Cirrus CLGD 5446 PCI VGA card or dummy VGA card with Bochs VESA extensions (hardware level, including all nonstandard modes).
PS/2 mouse and keyboard.
Two PCI IDE interfaces with hard disk and CD-ROM support.
NE2000 PCI network adapters.
SoundBlaster 16 card.
PC BIOS from the Bochs Project.
Plex86/Bochs LGPL VGA BIOS.
From the above list, you probably can tell that QEMU is not in contention as the Ultimate Linux Box. However, each of the emulated devices is well supported by Linux and Windows, which leads to easy Virtual Machine (VM) installs and no driver hunting, which is a “Very Good Thing”.
Being on an x86-based machine myself and not needing to run an OS that requires or even uses an x86-64, ARM, SPARC, PowerPC or MIPS processor, I can't vouch for QEMU's performance in that regard. I have tested some disk images of DebianPPC, Gentoo for SPARC and MenuetOS_64, which is written in x86-64 assembly language. They all booted and ran without trouble, but I was not able to compare their performance to real hardware. These, and many other QEMU-ready disk images, are available from the FreeOS Zoo (see Resources).
My purpose in using QEMU was to run an x86-based OS—Microsoft's Windows XP—inside my x86-based OS of choice, which is currently Ubuntu Linux 5.10. The good thing about this particular setup is that QEMU can employ a virtualization layer, called the KQEMU accelerator, on top of its standard emulation engine that speeds things up to what the QEMU Web site claims are “near native speeds”. Near native or not, I can say this, with the KQEMU accelerator installed, things are definitely faster.
The accelerator hands off as much processing as it can to the real processor and emulates only the necessary bits. This makes perfect sense. Why emulate x86 on x86? If there are good reasons to do so, I cannot think of any.
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
- Concerning Containers' Connections: on Docker Networking
- Where's That Pesky Hidden Word?
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- A Project to Guarantee Better Security for Open-Source Projects
- Firefox Security Exploit Targets Linux Users and Web Developers
- Doing Astronomy with Python
- My Network Go-Bag
- Build a “Virtual SuperComputer” with Process Virtualization
- Three More Lessons
- Calling All Linux Nerds!