Linux Docs - Qemu and VMPlayer
Site Navigation:


Qemu and VMPlayer

Author:  Sven Knispel
Updated:  09-04-2006
Feedback welcome:
Free service provided by:

[Updated 09.04.2006, added troubleshooting]
I am a happy qemu user (more here). When I read that VMPlayer (a free stripped down VMWare allowing to run but not to create or maintain hosts) was very fast so I decided to give it a try.
I have an up-and-running FC4 without X as a server for testing purposes installed with qemu.

Based on this example ths article will cover:

  • Creating/converting an image with qemu for VMPlayer
  • Creating a VMPlayer .vmx configuration file

1. Creating/converting an image with qemu

The qemu-img utility allows you to create an image or to convert an exisiting image:
Create an image qemu-img create -f raw <image> <size (e.g. 4G)>

Convert an image qemu-img convert -f raw <qemu-image> -O <vmplayer-image (.vmdk ext)>

2. Creating a .vmx file

To run VMPlayer needs a .vmdk and a .vmx file. For my FC4 server it looks like (required changes are italic and explained below): config.version = "8"
virtualHW.version = "3"
ide0:0.present = "TRUE"
ide0:0.filename = "fc4nox.vmdk"
memsize = "128"
MemAllowAutoScaleDown = "FALSE"
ide1:0.present = "TRUE"
ide1:0.fileName = "auto detect"
ide1:0.deviceType = "cdrom-raw"
ide1:0.autodetect = "TRUE"
floppy0.present = "FALSE"
ethernet0.present = "TRUE"
usb.present = "FALSE"
sound.present = "FALSE"
displayName = "Fedora Core 4"
guestOS = "other26xlinux"
nvram = "fc4nox.nvram"
MemTrimRate = "-1"
ide0:0.redo = ""
ethernet0.addressType = "generated"
ethernet0.connectionType = "nat"
uuid.location = "56 4d 0d 92 c9 cd 3c 25-c5 bf 91 91 43 5d bf 33"
uuid.bios = "56 4d 0d 92 c9 cd 3c 25-c5 bf 91 91 43 5d bf 33"
ethernet0.generatedAddress = "00:0c:29:5d:bf:33"
ethernet0.generatedAddressOffset = "0"
tools.syncTime = "TRUE"
ide1:0.startConnected = "TRUE"
uuid.action = "create"
checkpoint.vmState = ""
tools.remindInstall = "TRUE"

2.1 Changing the .vmx file

Following values have to be adapter to your settings:

  • ide0:0.filename is the name of your .vmdk file
  • memsize is the memory to be allocated to the guest system
  • displayName is the name of the guest system for the titlebar
  • guestOS qualifies the guest OS (see table below)
  • nvram is the name of the memory file created while running VMPlayer

The field guestOS must be one of the following: "darwin" = Darwin (unsupported)
"other-64" = Other 64-bit OS
"other" = Other OS
"freeBSD-64" = freeBSD 64-bit
"freeBSD" = freeBSD
"solaris10-64" = Solaris 10 64-bit
"solaris10" = Solaris 10
"solaris9" = Solaris 9
"solaris8" = Solaris 8
"solaris7" = Solaris 7
"solaris6" = Solaris 6
"solaris" = Other Solaris
"netware6" = Netware 6.x
"netware5" = Netware 5.x
"netware4" = Netware 4.x
"netware" = Other Netware
"otherlinux-64" = Other Linux 64Bit
"linux" = Other Linux
"other26xlinux-64" = Other Linux 2.6.x 64-bit
"other26xlinux" = Other Linux 2.6.x
"other24xlinux-64" = Other Linux 2.4.x 64-bit
"other24xlinux" = Other Linux 2.4.x
"ubuntu-64" = Ubuntu Linux 64-bit
"ubuntu" = Ubuntu Linux
"turbolinux" = Turbo Linux
"mandrake" = Mandrake Linux
"sjds" = Sun Java Desktop System
"nld9" = Novell Linux Desktop 9
"sles-64" = SUSE Linux Enterprise Server 64-bit
"sles" = SUSE Linux Enterprise Server
"suse-64" = SUSE Linux 64-bit
"suse" = SUSE Linux
"rhel4-64" = Red Hat Enterprise Linux 4 64-bit
"rhel4" = Red Hat Enterprise Linux 4
"rhel3-64" = Red Hat Enterprise Linux 3 64-bit
"rhel3" = Red Hat Enterprise Linux 3
"rhel2" = Red Hat Enterprise Linux 2
"redhat" = Red Hat Linux
"winVista-64" = Windows Vista x64 Edition (experimental)
"winVista" = Windows Vista (experimental)
"longhorn-64" = Windows Longhorn x64 Edition (experimental)
"longhorn" = Windows Longhorn (experimental)
"winNetBusiness" = Windows Server 2003 Small Business
"winNetEnterprise-64" = Windows Server 2003 Enterprise x64 Edition
"winNetEnterprise" = Windows Server 2003 Enterprise Edition
"winNetStandard-64" = Windows Server 2003 Standard x64 Edition
"winNetStandard" = Windows Server 2003 Standard Edition
"winNetWeb" = Windows Server 2003 Web Edition
"winXPPro-64" = Windows XP Professional x64 Edition
"winXPPro" = Windows XP Professional Edition
"winXPHome" = Windows XP Home Edition
"win2000AdvServ" = Windows 2000 Advanced Server
"win2000Serv" = Windows 2000 Server
"win2000Pro" = Windows 2000 Professional
"winNT" = Windows NT
"winMe" = Windows Me
"win98" = Windows 98
"win95" = Windows 95
"win31" = Windows 3.1
"windows" = Other Windows
"MS-DOS" = MS-Dos

2.2. Network configuration

2.2.1. Network adapter

You may want to change the network configuration.
br> Following attributes are relevant for network configuration (note that the "0" "in ethernet0" can also be 1 for a second adapter):

  • ethernet0.present = "TRUE" or "FALSE" whether the NIC is present or not
  • ethernet0.addressType = "generated" for DHCP or "static"
  • ethernet0.connectionType = "nat", "hostonly" or "bridged"
  • ethernet0.generatedAddress = "00:0c:29:12:17:6a" any MAC address (unique for your network)
  • ethernet0.generatedAddressOffset = "1" ofset from the MAC address, usefull when configuring multiple hosts

2.2.1. Connection type

This option is worth some more explanation as it is not self explaining.

VMPlayer supports three network modes:

  • NAT
  • Bridged
  • host-only
The default mode would be NAT: in this mode the guest can access the local network through a Network Allocation Table.
If the virtual machine will need to share an IP address with the host computer, use network address translation (NAT). This choice may be the best one if the virtual machine will run on a home computer.

If the virtual machine will run on a host computer that is on a network and a separate IP address will be available for the virtual machine (or the virtual machine can get one automatically from a DHCP server), use bridged networking. This choice may be appropriate if the virtual machine will run on a corporate network.

2.3. IDE configuration

You may want to create an empty image with qemu and then install the guest OS in VMPlayer. Therefore you must give your guest OS access to the CD-ROM.
The nubering of the IDE devices goes like this:

  • 1:0 is secondary master
  • 1:1 is secondary slave

2.3.1. Booting an ISO

The same can be done to boot from an ISO file instead of a CD-ROM: ide1:0.present = “TRUE”
ide1:0.fileName = “c:\some-file.iso”
ide1:0.deviceType = “cdrom-image”

2.3.1. Booting a CD-Rom

ide1:0.present = “TRUE”
ide1:0.fileName = “auto detect”
ide1:0.deviceType = “cdrom-raw”

3. References

A few interstiong references to read more about virtualisation:

4. Troubleshooting

Starting with FC4 Kernel 2.6.16-1.2069 I had the problem that stopped running as it was not finding the headers for my kernel, aborting with the error "The kernel defined by this directory of header files does not have the same address space size as your running kernel". This error is caused by the lack of support of FC4 (also see original discussion here). Fortunately there is vmware-any-any-update to solve this problem.

  • 1. download the latest version of vmware-any-any-update from here
  • 2. untar into a temp directory
  • 3. run to update vmplayer and rerun vmware-config

More details can be found here.

5. Benchmark

I don't know much about benchmarks but avter some research on Google I came up with the BYTE Linux benchmark.
After downloading and compiling LMBench I ran it on different configurations:

  • 1. on my host system (FC4 with X)
  • 2. on FC4 in VMPlayer
  • 3. on FC4 in qemu 0.72 with kqemu on
  • 4. on FC4 in qemu 0.72 with kqemu off

All reading were taken under similar conditions with an FC4 running KDE 3.5, with Firefox and Thunderbird open as well as GEdit, Konqueror, Gaim and a few shells. The host was running long enough for the running processes to have taken up the physical memory (System was running for 1 1/2 day). The guest system is a FC4 configured without X as a server with sshd, httpd, mysqld and sendmail running. Both qemu and VMWare were configured to allocate 128 MB of physical RAM to the guest.

5.1. Results

For each System I took 3 readings. The results are in the table below.
ConfigurationReading 1Reading 2Reading 3

5.2. Interpretation

These results must be interpreted with care.
As I stated before I am not a benchmark specialist and someone who knows more about it would certainly find a flaw flaw in this experience. Nevertheless my conclusion is that qemu is quite as fast as vmware and that both systems are as responsive as the host. Clearly the acceleration drivers (kqemu) makes a real difference. This result confirms the subjective impression I have had after working alternatively on both guests for a few days.