From ArchWiki
Revision as of 13:52, 20 September 2011 by Eigrad (talk | contribs)
Jump to: navigation, search

This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.

Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어

External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

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 Template:Codeline 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.

Get the packages

Arch Linux kernel 2.6.22 and newer now provide the appropriate Template:Codeline modules. You could check if your kernel supports KVM with the following command:

modprobe -l '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 Template:Codeline package in the [extra] repository (recommended)

pacman -S qemu-kvm

2. If you also need to use QEMU, you can choose to install Template:Codeline >= 0.9.0 instead, which conflicts with the Template:Codeline package. However, Template:Codeline now provides a Template:Codeline executable (Template:Codeline) that takes advantage of this technology.

pacman -S qemu

Setup kernel modules

You should check if your computer supports KVM hardware acceleration with the following command. It must return something.

egrep '^flags.*(vmx|svm)' /proc/cpuinfo

Firstly, you need to add your user into the Template:Codeline group to use the Template:Filename device.

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 Template:Codeline and Template:Codeline modules.

modprobe kvm
modprobe kvm-intel

2. If you have AMD's AMD-V extensions, modprobe the Template:Codeline and Template:Codeline modules.

modprobe kvm
modprobe kvm-amd

If modprobing Template:Codeline succeeds, but modprobing Template:Codeline or Template:Codeline fails (but Template:Filename claims that hardware acceleration is supported), check your BIOS settings. Some vendors (especially laptop vendors) disable these processor extensions by default.

If you want these modules to persist, add them to Template:Filename or Template:Filename.

How to use KVM

  1. Create a guest OS image
    $ qemu-img create -f qcow2 <Image_Name> <size>
  2. 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
  3. Running the system
    $ qemu-kvm -hda <Image_Name> -m 512 -vga std
Note: The default amount of main memory assigned to KVM guests is 128 MB. If that is not sufficient, add the "-m" argument and the desired amount of main memory specified in megabytes (e.g. Template:Codeline). Also note that recent Windows operating systems (tested with Vista and Windows 7) require the Template:Codeline disk image format. Other disk image formats may give a 0x80070057 error during the installation.

See QEMU for more information, and the Using the Kernel-based Virtual Machine section.

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: [1]

A virtio block device requires the option Template:Codeline instead of the simple Template:Codeline plus Template:Codeline:

$ qemu-kvm -drive file=drive.img,if=virtio,boot=on

(ps: Template:Codeline is absolutely required when you want to boot from it. There is no auto-detection as with Template:Codeline ...)

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: Template:Codeline, Template:Codeline, Template:Codeline, Template:Codeline, and Template:Codeline (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 Template:Filename 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 Template:Filename and Template:Filename (when booting from a virtio disk). When using grub-pc which references disks by UUID's, nothing has to be done.

Edit or create Template:Filename:

(hd0) /dev/vda

Note: The following may be outdated since a new official installation ISO has been released (2011.08.19).

To enable virtio at Arch Linux installation time, manual GRUB installation is required (current arch-release-media 2010.05) Though AIF correctly detects the virtio disks and sets up the right prefixes, the Template:Filename file must be created before configuring the bootloader.

So when installing Arch Linux you can install GRUB by switching to another virtual terminal (Ctrl+Alt+F2) and running the following commands.

# grub
> device (hd0) /dev/vda
> root (hd0,0)
> setup (hd0)
> quit
Note: (hd0,0) numbering may change depending on your configuration. Reference: http://lists.mandriva.com/bugs/2009-08/msg03424.php

Once you have installed GRUB, switch back to the main terminal with Ctrl+Alt+F1.

Further information on paravirtualization with KVM can be found here: [2] section in the German qemu-book: [3]

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-mm34.iso

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 Template:Codeline driver.

qemu-kvm -drive file=windows.img,if=virtio,boot=on -m 512
Note: If you encounter the Blue Screen of Death, make sure you did not forget the Template:Codeline parameter.

Resizing the image

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 Template:Codeline 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

Enabling KSM

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 a version of Template:Codeline installed which is at least 0.12.

# pacman -Qi qemu-kvm | grep Version
Version        :

Also ensure that your kernel is at least version 2.6.32.

# uname -r

If this is the case there should be a Template:Filename directory containing several files. You can turn KSM on or off by echoing a 1 or 0 to Template:Filename.

# 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 Template:Filename should be non-zero. From the kernel documentation in Template:Filename

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 the Template:Codeline package has been installed, you can use a GUI tool, such as Template:Codeline for simple use or Template:Codeline for particle control, to manage your virtual machine.

You need to change Template:Codeline in the configure item "QEMU start command" to Template:Codeline or leave the "QEMU start command" as Template:Codeline and append Template:Codeline to the additional start options. With newer versions of Template:Codeline it might not be necessary to append Template:Codeline as the Template:Codeline executable will detect that KVM is running and start in the corresponding 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

See also QEMU#Tap_Networking_with_QEMU and QEMU#Networking_with_VDE2.

pacman -S bridge-utils

Save this script in Template:Filename

echo "Executing /etc/qemu-ifup"
echo "Bringing up $1 for bridged mode..."
sudo /sbin/ifconfig $1 promisc up
echo "Adding $1 to br0..."
sudo /usr/sbin/brctl addif br0 $1
sleep 2

chmod 755 the script

chmod 755 /etc/qemu-ifup

Then use this script to start KVM. Adjust the Template:Codeline line to suit your requirements.

ARGS="-hda win2k.img -boot c -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=/etc/qemu-ifup -m 256 -localtime"
echo "Starting QEMU with..."
echo $ARGS
echo "...."
exec qemu $ARGS

Now the VM should get an IP address from your DHCP server and you can access it using that IP address from your LAN.

If you are using Template:Codeline, 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
# sysctl -p /etc/sysctl.conf

See the libvirt wiki and Fedora bug 512206

Alternatively, you can configure Template:Codeline to allow all traffic to be forwarded across the bridge by adding a rule like this:

-I FORWARD -m physdev --physdev-is-bridged -j ACCEPT

Mouse integration

To prevent the mouse from being grabbed when clicking on the guest operating system's windows, add the option Template:Codeline. 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

Here: QEMU#Starting_qemu_virtual_machines_on_boot