Qemu-KVM
I am a big fan of VMware. Ever since pre-ordering their Workstation V1.0 offering for Linux in 1999, I have been purchasing their upgrades over the years — the use of VM technology on a workstation for me was a no-brainer. And even though other VM technologies have emerged, there was this decent community-edition VMware Player, which made it even easier to distribute VMs to run on workstations.
Over the past couple of years, I have tinkered with qemu from the command-line to test-drive “live” media on ISO files. It was the easiest thing to do, not particularly fast, but very convenient and it ran entirely in userspace. No need to worry about matching VM drivers with the kernel, or worse, having to boot-up the machine with a Xen-enabled kernel. Yes, we live in a Right Now era.
With Fedora 12 installed, I have found that qemu and associated tools have matured a lot. There is even this newer invocation, qemu-kvm, which leverages KVM (loaded as a dynamic kernel module) for wider and improved access to host hardware. And since my workstation supports Virtualization Technology, I should expect even better speeds from qemu’s FAST! compiler.
Well, after creating a new Windows XP Professional guest using virt-manager, I was not too impressed by its speed. It was usable, mind you, but it did not compare with what I was getting from VMware Player. Curious though, other blog writers were writing about their successes and how excited they were with the results. Could it be my expectations were too high because of what I was getting from VMware and Xen?
Well, this required a little digging just to make certain.
$ lsmod | grep kvm
kvm 163952 0
Eh??! Checking the boot log revealed that my processors VT extensions were NOT enabled in BIOS:
$ dmesg | grep kvm
Shocking!! Re-booting and finding the darn BIOS setting to enable VT was all I needed to do. After which, booting up Fedora 12 and launching the WinXP guest, I can now see the kernel module in use:
$ lsmod | grep kvm kvm_intel 48184 4 kvm 163952 1 kvm_intel
… and the speed is simply wonderful from what it was earlier. Woot!
While virt-manager is an easy tool to manage a variety of VM guests, I wanted it even simpler to invoke. I made this Avant Window Navigator launcher icon that runs this script simply as: winxp.sh start
$ cat bin/winxp.sh
#!/bin/sh
# ...what virt-manager does... #qemu-kvm -S -M pc-0.11 -cpu qemu32 -m 1024 -smp 2 -name WinXP \ # -uuid a71bb397-7edf-a068-bc36-96c6ec6df713 \ # -monitor unix:/var/lib/libvirt/qemu/WinXP.monitor,server,nowait \ # -localtime -boot c \ # -drivefile=/media/Tank/virt/winxp.img,if=ide,index=0,boot=on \ # -drivefile=,if=ide,media=cdrom,index=2 \ # -net nic,macaddr=52:54:00:4c:bc:aa,vlan=0,name=nic.0 \ # -net tap,fd=20,vlan=0,name=tap.0 -serial pty-parallelnone \ # -usb -usbdevice tablet -vnc 127.0.0.1:0 \ # -k en-us -vga cirrus -soundhw es1370
# ... let's use the management interface instead ... [ -n "$1" ] && sudo virsh -c qemu:///system $1 WinXP sudo virt-viewer WinXP &
And if I were to accidentally close down the VNC window to the WinXP guest without first shutting down the guest OS, I can also run this script as: winxp.sh shutdown
After my first re-boot, however, this launcher script did not work. Running it from a shell showed it failed with a cryptic message that the virbr0 device did not exist. Being familiar with Xen and its virtual bridge networking requirements, I hunted down where the libvirt daemon configuration is kept in /etc/libvirtd with the expected autostart subdirectories. Inspecting man virsh revealed the ‘right way’ of configuring virtual network adapters to startup after a re-boot:
$ virsh -c qemu:///system net-autostart default
Fini.
