Weiqi Gao's Observations - qemu tag

QEMU: The Open Source Virtualizer

Wed, 28 Nov 2007 04:23:00 GMT

According to its home page, "QEMU is a generic and open source machine emulator and virtualizer."

I started playing with QEMU 695 days ago, and have made three posts about QEMU:

QEMU: The Open Source Processor Emulator (648 days ago)
QEMU: Just How Fast Is It? (577 days ago)
QEMU: Gentoo Guest Performance (558 days ago)

Unlike treating it like many of the other technologies that I took a look and then forgot about, I kept on using it as an emulator to run some of my non-GNU/Linux software. The software I want to run were pretty old, so they run at a reasonable speed even in emulator mode (1/20 native speed). I wrote WQGHLT along the way, which you can find here under GPLv2.

To run QEMU in virtualizer mode would require a piece of software called the KQEMU host driver, which was not available in open source form at the time. So I did not experiment. Another option for QEMU acceleration is through the kvm feature of a recent Linux kernel. But that requires a CPU that has hardware support for virtualization, which my AMD64 does not have.

KQEMU version 1.3.0pre11 was released under the GPLv2 on February 6, 2007. And it turns out that it is possible to have a QEMU/KQEMU combination running (and the guest running at 76% native speed according to the dhry2 benchmark) under Debian 4.0 x86_64. However, as everything Debian, the complete information for getting this setup working is scattered around the internet, and I have to do some digging and carbon-dating.

The good news is that both QEMU and KQEMU are available in Debian 4.0 Etch (QEMU 0.8.2/KQEMU 1.3.0pre9) and unstable (QEMU 0.9.0 and/KQEMU 1.3.0pre11). The bad news is that the packaged combination does not work; I saw the kernel panic in the guest OS when I tried. The compromise is to use the KQEMU from Debian unstable repository and the source release from QEMU website.

My recipe follows.

Preperations

I outlined how I changed my APT settings in the Getting Sun Java 6 On Debian 4.0 With APT Pinning post that I made 26 days ago. I did not change any of the settings this time.

Installing KQEMU

There are numerous web pages that describes how to install a kernel module using the module-assistant (aka m-a) command. I adapted the instructions in this page:

[root@gao-2006]# feta install qemu-common/unstable
[root@gao-2006]# feta install qemu-source/unstable
[root@gao-2006]# m-a prepare
[root@gao-2006]# m-a build kqemu-source
[root@gao-2006]# m-a install kqemu-source
[root@gao-2006]# modprobe kqemu
[root@gao-2006]# echo kqemu >> /etc/modules

Note that I used the feta command to do the work of apt-get, as Jonathan excellently suggested 164 days ago.

I did not include the output from the above commands. Let me just say that the outputs are long, informative, upbeat, and colorful. When everything is done, I have a kqemu-modules-2.6.18-5-amd64 package built and installed, with the kqemu kernel module installed at /lib/modules/2.6.18-5-amd64/misc/kqemu.ko. A /dev/kqemu entry is created with the following characteristics:

crw-rw-rw- 1 root root 10, 62 2007-11-28 09:11 /dev/kqemu

The output of the "lsmod | grep kqemu" command indicates that the KQEMU kernal module is indeed loaded, but is not currently being used by any programs.

Downloading and compiling QEMU

I downloaded QEMU 0.9.0 source from the QEMU download page. It has the standard ./configure, make, make install installation sequence. The only peculiarity is that QEMU requires GCC 3.x and SDL library to build. This is easily fixed by installing the gcc-3.4 and libsdl-console-dev packages and their dependencies.

The configure process informs me that kqemu support is enabled.

The build process produces the following set of executables:

[root@gao /opt/qemu-0.9.0/bin]# ls
qemu        qemu-img     qemu-ppc          qemu-system-mipsel
qemu-arm    qemu-m68k    qemu-sparc        qemu-system-ppc
qemu-armeb  qemu-mips    qemu-system-arm   qemu-system-sparc
qemu-i386   qemu-mipsel  qemu-system-mips  qemu-system-x86_64

I also needed to install the texlive package and its dependencies to make the documentation.

Running QEMU in virtualizer mode

On the x86_64 platform, the kqemu module can only be activated by the qemu-system-x86_64 program. There are two command line arguments for qemu-system-x86_64 that control its behavior:

(no argument): Only user code is executed directly; kernel code is dynamically translated
-kernel-kqemu: Both user code and kernel code are executed directly (full vertualization mode)
-no-kqemu: Both user code and kernel code are dynamically translated

When qemu-system-x86_64 runs, "lsmod | grep kqemu" shows that the kqemu kernel module is indeed being used:

[root@gao-2006]# lsmod | grep kqemu
kqemu                 170120  1

Benchmarks

I rerun the benchmark program inside a Debian 4.0 i386 guest OS. And the result is captured in this screenshot:

A comparison with my earlier results shows that the result of 219.0 dhrystone for QEMU in full virtualization mode is 18.4 times the 11.9 dhrystone for QEMU in emulator mode. Note that these benchmarks were run on the same physical hardware.

The benchmark result ran in the host OS is 288.6 dhrystone.

QEMU: Gentoo Guest Performance

Sun, 21 May 2006 16:04:07 GMT

It took me 12 days (not months as I previously guessed) but I have an instance of Gentoo installed as a QEMU guest. That includes the time of the initial installation of Gentoo, which went very smoothly due to their superb documentation, the emergence of links the terminal mode web browser, which brought in more than 200 dependencies including the entire X Window System, and a failed attempt to emerge Gnome, which would have brought in another 250 packages but errored out when there are 100 to go. (After the failed Gnome installation, I wanted to clean up a bit and retry. One of the cleanup commands I used is emerge --depclean, which wiped out the 150 packages already installed for Gnome.)

And here's the benchmark result:

On the surface, Gentoo's index of 11.9 compares unfavorably against Ubuntu's 56.0. However, on close inspection, I discovered that the Ubuntu guest's clock is running much slower then the host's clock, which inflated Ubuntu's index.

An rough estimate shows that Ubuntu's clock is running at one quarter of the regular clock speed. So the Ubuntu number should be roughly 14.0, still better than the Gentoo number. Incidentally, with the new lower number, the emulated QEMU system falls into the Pentium 200 category.

So for all that long compile time, I get a Gentoo system that runs at 85% the speed of Ubuntu. Apparently for the system emulated by QEMU, none of the optimizations that I hear Gentoo enthusiasts talking about matters.

QEMU: Just How Fast Is It?

Wed, 03 May 2006 04:08:46 GMT

I last blogged about my experience with QEMU 71 days ago.

Since then I have brought up several other operating systems on it, including NT 4.0, Windows 2000 and FreeBSD 6.0. One thing I noticed is that the newer OSes has more demand on the system and therefore behaves more sluggishly, to the point of not being very useful.

My latest adventure with QEMU is a second try at Ubuntu 6.06 Beta (Dapper Drake).

Maybe it's because I have experienced Ubuntu once before, or maybe it's because Ubuntu 6.06 Beta is really that much better than 5.10, or maybe it's because I'm getting a little bit impatient with Fedora Core 5's degradations, my impression of Ubuntu has improved, even though it's running very slowly under QEMU.

To measure how much slower the emulated system is compared with the host system, I ran a little bench mark program that I found on the internet. The result can be found in the screenshot below:

The bench mark index is 294.0 on the host OS and 56.0 on the guest OS. So the guest is running at 19% of the speed of the host system, making my AMD64 3500+ look like a P3/700MHz.