Difference between revisions of "QEMU"
(→Nitty Gritty: dhcp over the bridge seems to fail)
|Line 325:||Line 325:|
sudo tunctl -d $IFACE &> /dev/null
sudo tunctl -d $IFACE &> /dev/null
=== Front-ends for Qemu ===
=== Front-ends for Qemu ===
Revision as of 17:17, 12 May 2010
From the QEMU about page,
QEMU is a generic and open source machine emulator and virtualizer.
When used as a machine emulator, QEMU can run OSes and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your own PC). By using dynamic translation, it achieves very good performances.
When used as a virtualizer, QEMU achieves near native performances by executing the guest code directly on the host CPU. A host driver called the QEMU accelerator (also known as KQEMU) is needed in this case. QEMU supports virtualization when executing under the Xen hypervisor or using the KVM kernel module in Linux. When using KVM, QEMU can virtualize x86, server and embedded PowerPC, and S390 guests. The virtualizer mode requires that both the host and guest machine use x86 compatible processors.
- 1 Difference between qemu and qemu-kvm
- 2 Installing QEMU
- 3 Choosing Windows version
- 4 Creating the hard disk image
- 5 Preparing the installation media
- 6 Installing the operating system
- 7 Running the system
- 8 Moving data between host and guest OS
- 9 Optimizing Windows 9x CPU usage
- 10 Using the QEmu Accelerator Module
- 11 Using the Kernel-based Virtual Machine
- 12 Basic Networking
- 13 Tap Networking with QEMU
- 14 Front-ends for Qemu
- 15 Keyboard seems broken / Arrow keys don't work
Difference between qemu and qemu-kvm
Depending on your needs, you can choose either to install upstream qemu or qemu-kvm from the [extra] repository. Upstream qemu is a pure emulator, with no hardware acceleration (actually, it does have initial KVM support, but this implementation is still buggy and nowhere as complete as in qemu-kvm, many functions still doesn't work). Upstream qemu is capable of emulating many different platforms (arm, i386, m68k, mips, ppc, sparc, x86_64, etc). On the other hand you have qemu-kvm, which is qemu (i386 and x86_64 architecture support only) with KVM (kernel virtual machine) additions, allowing you to run virtual machines at close to native speed. qemu-kvm is the version you want if you have a capable CPU and only need to run virtual machines for the i386 and x86_64 architecture (Linux, Windows, BSD, etc).
Not all processor supports kvm. You will need an x86 machine running a recent Linux kernel on an Intel processor with VT (virtualization technology) extensions, or an AMD processor with SVM extensions (also called AMD-V). Xen has a complete list of compatible processors. For Intel processors, see also the Intel® Virtualization Technology List.
To install the machine emulator version:
$ sudo pacman -S qemu
To install the KVM version (please see the page on Kvm for more details):
$ sudo pacman -S qemu-kvm
Choosing Windows version
Qemu can run any version of Windows. However, 98, Me and XP will run at quite a low speed. You should choose either Windows 95 or Windows 2000. Surprisingly, 2000 seems to run faster than 98. The fastest one is 95, which can from time to time make you forget that you are running an emulator :)
If you own both Win95 and win98/winme, then 98lite (from http://www.litepc.com) might be worth trying. It decouples Internet Explorer from operating system and replaces it with original Windows 95 Explorer. It also enables you to do a minimal Windows installation, without all the bloat you normally cannot disable. This might be the best option, because you get the smallest, fastest and most stable Windows this way.
Creating the hard disk image
To run qemu you will probably need a hard disk image. This is a file which stores the contents of the emulated hard disk.
Use the command:
qemu-img create -f qcow2 win.qcow 4G
to create the image file named "win.qcow". The "4G" parameter specifies the size of the disk - in this case 4 GB. You can use suffix M for megabytes (for example "256M"). You shouldn't worry too much about the size of the disk - the qcow2 format compresses the image so that the empty space doesn't add up to the size of the file.
Preparing the installation media
The installation CD-ROM/floppy shouldn't be mounted, because Qemu accesses the media directly. It is a good idea to dump CD-ROM and/or floppy to a file, because it both improves performance and doesn't require you to have direct access to the devices (that is, you can run Qemu as a regular user). For example, if the CD-ROM device node is named "/dev/cdrom", you can dump it to a file with the command:
dd if=/dev/cdrom of=win98icd.iso
Do the same for floppies:
dd if=/dev/fd of=win95d1.img ...
When you need to replace floppies within qemu, just copy the contents of one floppy over another. For this reason, it is useful to create a special file that will hold the current floppy:
Installing the operating system
This is the first time you will need to start the emulator. One thing to keep in mind: when you click inside qemu window, the mouse pointer is grabbed. To release it press Ctrl+Alt.
If you need to use a bootable floppy, run Qemu with:
qemu -cdrom [[cdrom''image]] -fda [[floppy''image]] -boot a [[hd_image]]
or if you are on a x86_64 system (will avoid many problems afterwards):
qemu-system-x86_64 -cdrom [[cdrom''image]] -fda [[floppy''image]] -boot a [[hd_image]]
If your CD-ROM is bootable or you are using iso files, run Qemu with:
qemu -cdrom [[cdrom''image]] -boot d [[hd''image]]
or if you are on a x86_64 system (will avoid many problems afterwards):
qemu-system-x86_64 -cdrom [[cdrom''image]] -boot d [[hd''image]]
Now partition the virtual hard disk, format the partitions and install the OS.
A few hints:
- If you are using Windows 95 boot floppy, then choosing SAMSUNG as the type of CD-ROM seems to work
- There are problems when installing Windows 2000. Windows setup will generate a lot of edb*.log files, one after the other containing nothing but blank spaces in C:\WINNT\SECURITY which quickly fill the virtual harddisk. A workaround is to open a Windows command prompt as early as possible during setup (by pressing Shift-F10) which will allow you to remove these log files as they appear by typing :
Running the system
To run the system simply type:
A good idea is to use overlay images. This way you can create hard disk image once and tell Qemu to store changes in external file. You get rid of all the instability, because it is so easy to revert to previous system state :)
To create an overlay image, type:
qemu-img create -b [[base''image]] -f qcow [[overlay''image]]2
Substitute the hard disk image for base_image (in our case win.qcow). After that you can run qemu with:
or if you are on a x86_64 system:
and the original image will be left untouched. One hitch, the base image cannot be renamed or moved, the overlay remembers the base's full path.
Moving data between host and guest OS
If you have servers on your host OS they will be accessible with the ip-address 10.0.2.2 without any further configuration. So you could just FTP or SSH, etc to 10.0.2.2 from windows to share data, or if you would like to use samba:
Qemu supports SAMBA which allows you to mount host directories during the emulation. It seems that there is an incompatibility with SAMBA 3.x. and some versions of qemu. But at least with a current snapshot of qemu it should be working.
First, you need to have a working samba installation. Then add the following section to your smb.conf:
[qemu] comment = Temporary file space path = /tmp read only = no public = yes
Now start qemu with:
qemu [hd_image] -smb qemu
Then you should be able to access your host's smb-server with the ip-address 10.0.2.2. If you're running Win9x as guest OS, you may need to add
to c:\windows\lmhosts (Win9x has Lmhosts.sam as a SAMple, rename it!).
Mounting the hard disk image
Fortunately there is a way to mount the hard disk image with a loopback device. Login as root, make a temporary directory and mount the image with the command:
mount -o loop,offset=32256 [[hd''image]] [[tmp''dir]]
Now you can copy data in both directions. When you are done, umount with:
The drawback of this solution is that you cannot use it with qcow images (including overlay images). So you need to create you images without \"-f qcow\" option. Tip: create a second, raw harddrive image. This way you'll be able to transfer data easily and use qcow overlay images for the primary drive.
REMEMBER: never run qemu when the image is mounted!
Using any real partition as the single primary partition of a hard disk image
Sometimes, you may wish to use one of your system partition from within qemu (for instance, if you wish booting both your real machine or qemu using a given partition as root). You can do this using software RAID in linear mode (you need the linear.ko kernel driver) and a loopback device: the trick is to dynamically prepend a master boot record (MBR) to the real partition you wish to embed in a qemu raw disk image.
Suppose you have a plain, unmounted /dev/hdaN partition with some filesystem on it you wish to make part of a qemu disk image. First, you create some small file to hold the MBR:
dd if=/dev/zero of=/path/to/mbr count=32
Here, a 16 KB (32 * 512 bytes) file is created. It is important not to make it too small (even if the MBR only needs a single 512 bytes block), since the smaller it will be, the smaller the chunk size of the software RAID device will have to be, which could have an impact on performance. Then, you setup a loopback device to the MBR file:
losetup -f /path/to/mbr
Let's assume the resulting device is /dev/loop0, because we woudn't already have been using other loopbacks. Next step is to create the "merged" MBR + /dev/hdaN disk image using software RAID:
modprobe linear mdadm --build --verbose /dev/md0 --chunk=16 --level=linear --raid-devices=2 /dev/loop0 /dev/hdaN
The resulting /dev/md0 is what you will use as a qemu raw disk image (don't forget to set the permissions so that the emulator can access it). The last (and somewhat tricky) step is to set the disk configuration (disk geometry and partitions table) so that the primary partition start point in the MBR matches the one of /dev/hdaN inside /dev/md0 (an offset of exactly 16 * 512 = 16384 bytes in this example). Do this using fdisk on the host machine, not in the emulator: the default raw disc detection routine from qemu often results in non kilobyte-roundable offsets (such as 31.5 KB, as in the previous section) that cannot be managed by the software RAID code. Hence, from the the host:
Press 'x' to enter the expert menu. Set number of 's'ectors per track so that the size of one cylinder matches the size of your mbr file. For two heads and the sector size is 512, the number of sectors per track should be 16, so we get cylinders of size 2x16x512=16k. Now, press 'r' to return to the main menu. Press 'p' and check that now the cylinder size is 16k. Now, create a single primary partition corresponding to /dev/hdaN. It should start at cylinder 2 and end at the end of the disk (note that the number of cylinders now differs from what it was when you entered fdisk. Finally, 'w'rite the result to the file: you are done. You know have a partition you can mount directly from your host, as well as part of a qemu disk image:
qemu -hdc /dev/md0 [...]
You can of course safely set any bootloader on this disk image using qemu, provided the original /boot/hdaN partition contains the necessary tools.
Optimizing Windows 9x CPU usage
Windows 9x doesn't use hlt instruction, so the emulator always eats up 100% CPU even if no computation is being done. Grab the file http://www.user.cityline.ru/~maxamn/amnhltm.zip, unpack it, copy it to the image and run the .bat file.
Using the QEmu Accelerator Module
The developers of qemu have created an optional kernel module to accelerate qemu to sometimes near native levels. This should be loaded with the option
to automate the creation of the required /dev/kqemu device. The following command
echo "options kqemu major=0" >> /etc/modprobe.d/modprobe.conf
will amend modprobe.conf to ensure that the module option is added every time the module is loaded.
Append kqemu to the list of modules in /etc/rc.conf to have it loaded the next time the your system starts. To load it now without rebooting, do the following as root
If you are using Linux, Windows 2000 or Windows XP as guest OS, start qemu with the command line option
qemu [...] -kernel-kqemu
or, if you are on a x86_64 system (will not work otherwise):
qemu-system-x86_64 [...] -kernel-kqemu
This enables full virtualization and thus improves speed considerably.
Using the Kernel-based Virtual Machine
Kvm is a full virtualization solution for Linux on x86 hardware containing virtualization extensions (Intel VT or AMD-V). It consists of a loadable kernel module, kvm.ko, that provides the core virtualization infrastructure and a processor specific module, kvm-intel.ko or kvm-amd.ko. Using Kvm, one can run multiple virtual machines running unmodified Linux or Windows images. Each virtual machine has private virtualized hardware: a network card, disk, graphics adapter, etc.
This technology requires an x86 machine running a recent Linux kernel on an Intel processor with VT (virtualization technology) extensions, or an AMD processor with SVM extensions. It is included in the mainline linux kernel since 2.6.20 and is enabled by default in the Arch Linux kernel.
Even though qemu in recent versions do have initial KVM support (qemu --enable-kvm), it is not recommended to use this, as many KVM-related functions still haven't been implemented in upstream qemu. Instead, you should go for the qemu-kvm package in extra, which is released by the KVM development team and contain all of the latest features (and bugfixes) of KVM userspace. Please refer to the Kvm page itself, for more information on using QEMU with KVM on Arch Linux.
To take advantage of Kvm, you simply need a compatible processor (the following command must return something on screen)
egrep '^flags.*(vmx|svm)' /proc/cpuinfo
And load the appropriate module from your rc.conf
- For Intel® processors add this module to your MODULES array in /etc/rc.conf
- for AMD® processors add this module to your MODULES array in /etc/rc.conf
Also, you will need to yourself to the group 'kvm'.
To add basic networking to your virtual machine, you may have to simply load qemu with those options: -net nic,vlan=1 -net user,vlan=1. For example, to load a cdrom, you could use:
qemu -kernel-kqemu -no-acpi -net nic,vlan=1 -net user,vlan=1 -cdrom dsl-4.3rc1.iso
Note that this only supports the TCP and UDP protocols. In particular ICMP and thus ping will not work.
Tap Networking with QEMU
Tap networking in QEMU lets virtual machines register themselves as though with separate ethernet adapters and have their traffic bridged directly onto your local area network. This is sometimes very desireable, if you want your virtual machines to be able to talk to each other, or for other machines on your LAN to talk to virtual machines.
You probably should not use this networking method if your host Arch machine is directly on the Internet. It can expose your virtual machines directly to attack!
In general, Arch disclaims any responsibility for security implications (or implications of any kind, really) from following these instructions.
To set all this up, you'll need to install the following packages:
bridge-utils (for brctl, to manipulate bridges) uml_utilities (for tunctl, to manipulate taps) sudo (for manipulating bridges and tunnels as root)
# pacman -S bridge-utils uml_utilities sudo
We will replace the normal ethernet adapter with a bridge adapter and bind the normal ethernet adapter to it. See http://en.gentoo-wiki.com/wiki/KVM#Networking_2 .
Take the following steps:
tun to your
MODULES line in
MODULES=( ... bridge tun)
2. Configure your bridge
br0 to have your real ethernet adapter (herein assumed
eth0) in it, in
3. Change your networking configuration so that you just bring up your real ethernet adapter without configuring it, allowing real configuration to happen on the bridge interface. In
eth0="eth0 up" br0="dhcp" INTERFACES=(eth0 br0)
Remember, especially if you're doing DHCP, it's essential that the bridge comes up AFTER the real adapter, otherwise the bridge won't be able to talk to anything to get a DHCP address!
If DHCP does not work, try with a static IP address in
eth0="eth0 0.0.0.0" br0="br0 192.168.0.3 netmask 255.255.255.0 broadcast 192.168.0.255" INTERFACES=(eth0 br0) gateway="default gw 192.168.0.1" ROUTES=(gateway)
and then in
domain lan nameserver 192.168.0.1
4. Install the script that QEMU uses to bring up the tap adapter in
/etc/qemu-ifup with root:kvm 750 permissions:
#!/bin/sh echo "Executing /etc/qemu-ifup" echo "Bringing up $1 for bridged mode..." sudo /sbin/ifconfig $1 0.0.0.0 promisc up echo "Adding $1 to br0..." sudo /usr/sbin/brctl addif br0 $1 sleep 2
visudo to add the following to your
Cmnd_Alias QEMU=/sbin/ifconfig,/sbin/modprobe,/usr/sbin/brctl,/usr/bin/tunctl %kvm ALL=NOPASSWD: QEMU
6. Make sure the user(s) wishing to use this new functionality are in the kvm group. Exit and log in again if necessary.
7. You launch qemu using the following
USERID=`whoami` IFACE=`sudo tunctl -b -u $USERID` qemu-kvm -net nic -net tap,ifname="$IFACE" $* sudo tunctl -d $IFACE &> /dev/null
8. If you can't get a DHCP address in the host, it might be because the iptables are up by default in the bridge. In that case (from http://www.linux-kvm.org/page/Networking ):
- cd /proc/sys/net/bridge
bridge-nf-call-arptables bridge-nf-call-iptables bridge-nf-call-ip6tables bridge-nf-filter-vlan-tagged
- for f in bridge-nf-*; do echo 0 > $f; done
Front-ends for Qemu
There are a few GUI Front-ends for Qemu:
Keyboard seems broken / Arrow keys don't work
Should you find that some of your keys do not work or "press" the wrong key (in particular, the arrow keys), you likely need to specify your keyboard layout as an option. The keyboard layouts can be found in /usr/share/qemu/keymaps.
qemu -k [keymap] [disk_image]