KVM, Kernel-based Virtual Machine, is a hypervisor built right into the 2.6 (and 3.X) Linux kernel for kernels newer than 2.6.20. It is similar to Xen in purpose but much simpler to get running. To start using the hypervisor, just load the appropriate
kvm kernel modules and the hypervisor is up. As with Xen's full virtualization, in order for KVM to work, you must have a processor that supports Intel's VT-x extensions or AMD's AMD-V extensions.
Using KVM, one can run multiple virtual machines running unmodified GNU/Linux, Windows, or any other operating system. (See Guest Support Status). Each virtual machine has private virtualized hardware: a network card, disk, graphics adapter, etc. See KVM Howto
Differences among KVM, Xen, VMware, and QEMU can be found at the KVM FAQ.
- 1 Get the packages
- 2 Setup kernel modules
- 3 How to use KVM
- 4 Paravirtualized guests (virtio)
- 5 Resizing the image
- 6 Enabling KSM
- 7 Easy to Use for New User
- 8 Bridged Networking
- 9 Mouse integration
- 10 Mounting the QEMU image
- 11 Starting KVM virtual machines on boot up
- 12 Tips and tricks
Get the packages
Arch Linux kernels >= 2.6.22 provide the appropriate kernel modules to support KVM. You can check if your kernel supports KVM with the following command (assuming your kernel is built with CONFIG_IKCONFIG_PROC):
zgrep KVM /proc/config.gz
KVM requires that the virtual machine host's processor has virtualization support. You can check whether your processor supports hardware virtualization with the following command:
grep -E "(vmx|svm)" --color=always /proc/cpuinfo
If nothing is displayed after running that command, then your processor does not support hardware virtualization, and you will not be able to use QEMU-KVM.
KVM also requires a modified QEMU to launch and manage virtual machines. You can choose one of the following according to your needs:
1. The official repositories (recommended).package is available in the
2. If you also need to use QEMU, you can choose to install
qemu-kvm executable (
qemu -enable-kvm) that takes advantage of this technology.
Setup kernel modules
First, you need to add your user account into the
kvm group to use the
gpasswd -a <Your_Login_Name> kvm
Secondly, you have to choose one of the following depending on the manufacturer of your CPU.
1. If you have Intel's VT-x extensions, modprobe the
modprobe kvm modprobe kvm-intel
2. If you have AMD's AMD-V (code name "Pacifica") extensions, modprobe the
modprobe kvm modprobe kvm-amd
kvm succeeds, but modprobing
kvm-amd fails (but
/proc/cpuinfo claims that hardware acceleration is supported), check your BIOS settings. Some vendors (especially laptop vendors) disable these processor extensions by default. To determine whether there's no hardware support or there is but the extensions are disabled in BIOS, the output from
dmesg after having failed to modprobe will tell.
If you want these modules to persist, add them to
How to use KVM
- Create a guest OS image:
$ qemu-img create -f qcow2 <Image_Name> <size>
- Install the guest OS:
A CD/DVD image (ISO file) can be used for the installation.
$ qemu-kvm -hda <Image_Name> -m 512 -cdrom /path/to/the/ISO/image -boot d -vga std
- Running the system:
$ qemu-kvm -hda <Image_Name> -m 512 -vga std
Paravirtualized guests (virtio)
KVM offers guests the ability to use paravirtualized block and network devices, which leads to better performance and lower overhead. Linux has had this ability with its virtio-modules since kernel 2.6.25. For Windows, a paravirtualized network driver can be obtained here: 
A virtio block device requires the option
-drive instead of the simple
$ qemu-kvm -drive file=drive.img,if=virtio,boot=on
boot=on is absolutely required when you want to boot from it. There is no auto-detection as with
Almost the same goes for the network:
$ qemu-kvm -net nic,model=virtio
Preparing an (Arch) Linux guest
To use virtio devices after an Arch Linux guest has been installed, the following modules can be loaded in the guest:
virtio_ring (for 32-bit guests, the specific "virtio" module is not necessary).
If you want to boot from a virtio disk, the initial ramdisk must be rebuilt. Add the appropriate modules in
/etc/mkinitcpio.conf like this:
MODULES="virtio_blk virtio_pci virtio_net"
and rebuild the initial ramdisk:
# mkinitcpio -p linux
Virtio disks are recognized with the prefix v (e.g. vda, vdb, etc.); therefore, changes must be made in at least
/boot/grub/menu.lst when booting from a virtio disk. When using grub-pc which references disks by UUID's, nothing has to be done.
Edit or create
To enable virtio at Arch Linux installation time, manual GRUB installation is required (for arch-release-media 2010.05)
Though AIF correctly detects the virtio disks and sets up the right prefixes, the
/boot/grub/device.map file must be created before configuring the bootloader.
So when installing Arch Linux, you can install GRUB by switching to another virtual terminal (Template:Keypress) and running the following commands.
# grub > device (hd0) /dev/vda > root (hd0,0) > setup (hd0) > quit
Once you have installed GRUB, switch back to the main terminal with Template:Keypress.
Preparing a Windows guest
Preparing a Windows guest for running with a virtio disk driver is a bit tricky.
In your KVM host (running Arch Linux), download the virtio disk driver from the Fedora repository.
Now you need to create a new disk image, which fill force Windows to search for the driver. To do it, stop the virtual machine if its running and issue the following command:
qemu-img create -f qcow2 fake.img 1G
Run the original Windows guest (still in the IDE mode). Add the fake disk and a CD-ROM with the driver.
qemu-kvm -drive file=windows.img,if=ide,boot=on -m 512 -drive file=fake.img,if=virtio -cdrom virtio-win-0.1-15.iso -vga std
Windows will detect the fake disk and try to find a driver for it. If it fails, go to Device Manager, locate the SCSI drive with an exclamation mark icon (should be open), click "Update driver" and browse for the proper directory on the virtual CD-ROM.
When the installation is successful, you can turn off the virtual machine and launch it again, now with the
qemu-kvm -drive file=windows.img,if=virtio,boot=on -m 512 -vga std
Resizing the image
Since version 0.13.0 of
qemu-img executable, the
resize option. By this switch is possible to resize a qcow2 image directly, with no need to pass through raw conversion. I.e., this command will increase my_image.qcow2 image space by 10 Gigabytes
qemu-img resize my_image.qcow2 +10G
It is possible to increase the size of a qcow2 image later, at least with ext3. Convert it to a raw image, expand its size with dd, convert it back to qcow2, replace the partition with a larger one, do a
fsck and resize the filesystem.
$ qemu-img convert -O raw image.qcow2 image.img $ dd if=/dev/zero of=image.img bs=1G count=0 seek=[NUMBER_OF_GB] $ qemu-img convert -O qcow2 -o cluster_size=64K image.img imageplus.qcow2 $ qemu-kvm -hda imageplus.qcow2 -m 512 -cdrom </Path/to/the/ISO/Image> -boot d -vga std $ fdisk /dev/sda [delete the partition, create new one occupying whole disk] $ e2fsck -f /dev/sda1 $ resize2fs /dev/sda1
Kernel Samepage Merging (KSM) is a feature of the Linux kernel introduced in the 2.6.32 kernel. KSM allows for an application to register with the kernel to have its pages merged with other processes that also register to have their pages merged. For KVM, the KSM mechanism allows for guest virtual machines to share pages with each other. In an environment where many of the guest operating systems are similar, this can result in significant memory savings.
To enable KSM, first ensure that you have installed>= 0.12.0.
# pacman -Qi qemu-kvm | grep Version Version : 0.15.0-2
Also ensure that your kernel is at least version 2.6.32.
# uname -r 3.0-ARCH
If this is the case there should be a
/sys/kernel/mm/ksm/ directory containing several files. You can turn KSM on or off by echoing a 1 or 0 to
# echo 1 > /sys/kernel/mm/ksm/run
If KSM is running, and there are pages to be merged (i.e. more than one similar VM is running), then
/sys/kernel/mm/ksm/pages_shared should be non-zero. From the kernel documentation in
The effectiveness of KSM and MADV_MERGEABLE is shown in /sys/kernel/mm/ksm/: pages_shared - how many shared unswappable kernel pages KSM is using pages_sharing - how many more sites are sharing them i.e. how much saved pages_unshared - how many pages unique but repeatedly checked for merging pages_volatile - how many pages changing too fast to be placed in a tree full_scans - how many times all mergeable areas have been scanned A high ratio of pages_sharing to pages_shared indicates good sharing, but a high ratio of pages_unshared to pages_sharing indicates wasted effort. pages_volatile embraces several different kinds of activity, but a high proportion there would also indicate poor use of madvise MADV_MERGEABLE.
An easy way to see how well KSM is performing is to simply print the contents of all the files in that directory.
# for ii in /sys/kernel/mm/ksm/* ; do echo -n "$ii: " ; cat $ii ; done /sys/kernel/mm/ksm/full_scans: 151 /sys/kernel/mm/ksm/max_kernel_pages: 246793 /sys/kernel/mm/ksm/pages_shared: 92112 /sys/kernel/mm/ksm/pages_sharing: 131355 /sys/kernel/mm/ksm/pages_to_scan: 100 /sys/kernel/mm/ksm/pages_unshared: 123942 /sys/kernel/mm/ksm/pages_volatile: 1182 /sys/kernel/mm/ksm/run: 1 /sys/kernel/mm/ksm/sleep_millisecs: 20
Easy to Use for New User
If thepackage has been installed, you can use a GUI tool, such as for simple use or for particle control, to manage your virtual machine.
You need to change
qemu in the configure item "QEMU start command" to
qemu-kvm or leave the "QEMU start command" as
qemu and append
-enable-kvm to the additional start options. With newer versions of , it might not be necessary to append
-enable-kvm as the
qemu executable will detect that KVM is running and start in the correct mode.
If you start your VM with a GUI tool and installation is very slow, you should check for proper KVM support, as QEMU may be falling back to pure software emulation.
Bridged networking is used when you want your VM to be on the same network as your host machine. This will allow it to get a static or DHCP IP address on your network, and then you can access it using that IP address from anywhere on your LAN. The preferred method for setting up bridged networking for KVM is to use thepackage. You will also need to install .
If you are using, it is recommended for performance and security reasons to disable the firewall on the bridge:
# cat >> /etc/sysctl.conf <<EOF net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-arptables = 0 EOF # sysctl -p /etc/sysctl.conf
Alternatively, you can configureto allow all traffic to be forwarded across the bridge by adding a rule like this:
-I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
To prevent the mouse from being grabbed when clicking on the guest operating system's windows, add the option
-usbdevice tablet. This means QEMU is able to report the mouse position without having to grab the mouse. This also overrides PS/2 mouse emulation when activated.
$ qemu-kvm -hda <Image_Name> -m 512 -vga std -usbdevice tablet
Mounting the QEMU image
modprobe nbd max_part=63 qemu-nbd -c /dev/nbd0 [image.img] mount /dev/nbd0p1 [/mnt/qemu]
Starting KVM virtual machines on boot up
If you use virt-manager and virsh as your VM tools then this is very simple. At the commandline to set a VM to autostart:
virsh autostart <domain>
To disable autostarting:
virsh autostart --disable <domain>
Virt-manager is equally easy having an autostart check box in the boot options of the VM.
Note VMs started by QEMU or KVM from the command line are not then manageable by virt-manager.
For an alternative check here: QEMU#Starting_QEMU_virtual_machines_on_boot
Tips and tricks
Poor Man's Networking
Setting up bridged networking can be a bit of a hassle sometimes. If the sole purpose of the VM is experimentation, one strategy to connect the host and the guests is to use SSH tunneling.
The basic steps are as follows:
- Setup an SSH server in the host OS
- (optional) Create a designated user used for the tunneling (e.g. tunneluser)
- Install SSH in the VM
- Setup authentication
When using the default user network stack, the host is reachable at address 10.0.2.2.
If everything works and you can SSH into the host, simply add something like the following to your /etc/rc.local
# Local SSH Server echo "Starting SSH tunnel" sudo -u vmuser ssh firstname.lastname@example.org -N -R 2213:127.0.0.1:22 -f # Random remote port (e.g. from another VM) echo "Starting random tunnel" sudo -u vmuser ssh email@example.com -N -L 2345:127.0.0.1:2345 -f
In this example a tunnel is created to the SSH server of the VM and an arbitrary port of the host is pulled into the VM.
This is a quite basic strategy to do networking with VMs. However, it is very robust and should be quite sufficient most of the time.