https://wiki.archlinux.org/api.php?action=feedcontributions&user=Elizacat&feedformat=atomArchWiki - User contributions [en]2024-03-19T02:17:05ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=KVM&diff=203136KVM2012-05-29T04:10:30Z<p>Elizacat: /* Preparing a FreeBSD guest */ Make it a little more 'professional'</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[Category:Kernel]]<br />
{{i18n|KVM}}<br />
<br />
'''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 {{Ic|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.<br />
<br />
Using KVM, one can run multiple virtual machines running unmodified GNU/Linux, Windows, or any other operating system. (See [http://www.linux-kvm.org/page/Guest_Support_Status Guest Support Status]). Each virtual machine has private virtualized hardware: a network card, disk, graphics adapter, etc. See [http://www.linux-kvm.org/page/HOWTO KVM Howto]<br />
<br />
Differences among KVM, Xen, VMware, and QEMU can be found at the [http://www.linux-kvm.org/page/FAQ#General_KVM_information KVM FAQ].<br />
<br />
== Get the packages ==<br />
<br />
Arch Linux kernels >= 2.6.22 provide the appropriate [[Kernel_modules|kernel modules]] to support KVM.<br />
You can check if your kernel supports KVM with the following command (assuming your kernel is built with CONFIG_IKCONFIG_PROC):<br />
zgrep KVM /proc/config.gz<br />
<br />
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:<br />
grep -E "(vmx|svm)" --color=always /proc/cpuinfo<br />
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.<br />
<br />
KVM also requires a modified QEMU to launch and manage virtual machines. You can choose one of the following according to your needs:<br />
<br />
1. The {{Pkg|qemu-kvm}} package is available in the [[Official Repositories|official repositories]] ''(recommended)''.<br />
<br />
2. If you also need to use QEMU, you can choose to install {{Pkg|qemu}} >= 0.9.0 instead, which conflicts with the {{Pkg|qemu-kvm}} package. However, {{Pkg|qemu}} now provides a {{Ic|qemu-kvm}} executable ({{Ic|qemu -enable-kvm}}) that takes advantage of this technology.<br />
<br />
== Setup kernel modules ==<br />
<br />
First, you need to add your user account into the {{Ic|kvm}} group to use the {{ic|/dev/kvm}} device.<br />
gpasswd -a <Your_Login_Name> kvm<br />
<br />
Secondly, you have to choose one of the following depending on the manufacturer of your CPU.<br />
<br />
1. If you have Intel's VT-x extensions, modprobe the {{Ic|kvm}} and {{Ic|kvm-intel}} modules.<br />
modprobe kvm<br />
modprobe kvm-intel<br />
<br />
2. If you have AMD's AMD-V (code name "Pacifica") extensions, modprobe the {{Ic|kvm}} and {{Ic|kvm-amd}} modules.<br />
modprobe kvm<br />
modprobe kvm-amd<br />
<br />
If modprobing {{Ic|kvm}} succeeds, but modprobing {{Ic|kvm-intel}} or {{Ic|kvm-amd}} fails (but {{ic|/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 {{Ic|dmesg}} after having failed to modprobe will tell.<br />
<br />
If you want these modules to persist, add them to {{ic|/etc/rc.conf}} or {{ic|/etc/mkinitcpio.conf}}.<br />
<br />
== How to use KVM ==<br />
<br />
# Create a guest OS image: {{bc|$ qemu-img create -f qcow2 <Image_Name> <size> }}<br />
# Install the guest OS:<br>A CD/DVD image (ISO file) can be used for the installation. {{bc|$ qemu-kvm -hda <Image_Name> -m 512 -cdrom /path/to/the/ISO/image -boot d -vga std }}<br />
# Running the system: {{bc|$ qemu-kvm -hda <Image_Name> -m 512 -vga std}}<br />
<br />
{{Note| you may want to assign multiple CPUs to the guest by using -smp X (where X - number of CPUs). The maximum number of assigned CPUs for one guest is 16.}} <br />
<br />
{{Note|The default amount of main memory assigned to KVM guests is 128 MB. If that is not sufficient, add the {{Ic|-m}} argument and the desired amount of main memory specified in megabytes (e.g. {{Ic|-m 1024}}). Also note that recent Windows operating systems (tested with Windows Vista and Windows 7) require the {{Ic|qcow2}} disk image format. Other disk image formats may give a 0x80070057 error during the installation.}}<br />
<br />
See '''[[QEMU]]''' for more information, and the ''[[QEMU#Using_the_Kernel-based_Virtual_Machine|Using the Kernel-based Virtual Machine]]'' section.<br />
<br />
== Paravirtualized guests (virtio) ==<br />
<br />
KVM offers guests the ability to use paravirtualized block and network devices, which leads to better performance and lower overhead.<br />
Linux has had this ability with its virtio-modules since kernel 2.6.25.<br />
For Windows, a paravirtualized network driver can be obtained here: [http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers].<br />
FreeBSD has the ability to use virtio drivers since 10.0 (unreleased). A backport of the drivers are available in the port {{ic|emulators/virtio-kmod}} for FreeBSD 8.3 and 9.0.<br />
<br />
A virtio block device requires the option {{Ic|-drive}} instead of the simple {{Ic|-hd*}} plus {{Ic|<nowiki>if=virtio</nowiki>}}:<br />
$ qemu-kvm -boot order=c -drive file=drive.img,if=virtio<br />
(ps: {{Ic|<nowiki>-boot order=c</nowiki>}} is absolutely required when you want to boot from it. There is no auto-detection as with {{Ic|-hd*}} ...)<br />
<br />
Almost the same goes for the network:<br />
$ qemu-kvm -net nic,model=virtio<br />
<br />
=== Preparing an (Arch) Linux guest ===<br />
{{Note|The arch setup scripts for the installer does not handle vd* disk devices correctly and required additional steps as detailed in this post https://bbs.archlinux.org/viewtopic.php?pid&#61;1042283}}<br />
<br />
To use virtio devices after an Arch Linux guest has been installed, the following modules can be loaded in the guest: {{Ic|virtio}}, {{Ic|virtio_pci}}, {{Ic|virtio_blk}}, {{Ic|virtio_net}}, and {{Ic|virtio_ring}} (for 32-bit guests, the specific "virtio" module is not necessary).<br />
<br />
If you want to boot from a virtio disk, the initial ramdisk must be [[mkinitcpio|rebuilt]]. Add the appropriate modules in {{ic|/etc/mkinitcpio.conf}} like this:<br />
MODULES="virtio_blk virtio_pci virtio_net"<br />
and rebuild the initial ramdisk:<br />
# mkinitcpio -p linux<br />
<br />
Virtio disks are recognized with the prefix '''''v''''' (e.g. ''v''da, ''v''db, etc.); therefore, changes must be made in at least {{ic|/etc/fstab}} and {{ic|/boot/grub/menu.lst}} when booting from a virtio disk. When using grub-pc which references disks by [[Persistent_block_device_naming#By-uuid|UUID's]], nothing has to be done.<br />
<br />
Edit or create {{ic|/boot/grub/device.map}}:<br />
(hd0) /dev/vda<br />
<br />
{{Note|The following may be outdated since a new official installation ISO has been released (2011.08.19).}}<br />
To enable virtio at Arch Linux installation time, manual GRUB installation is required (for arch-release-media 2010.05)<br />
Though AIF correctly detects the virtio disks and sets up the right prefixes, the {{ic|/boot/grub/device.map}} file must be created before configuring the bootloader.<br />
<br />
So when installing Arch Linux, you can install GRUB by switching to another virtual terminal ({{Keypress|Ctrl+Alt+F2}}) and running the following commands.<br />
# grub<br />
> device (hd0) /dev/vda<br />
> root (hd0,0)<br />
> setup (hd0)<br />
> quit<br />
<br />
{{Note|(hd0,0) numbering may change depending on your configuration. Reference: http://lists.mandriva.com/bugs/2009-08/msg03424.php}}<br />
<br />
Once you have installed GRUB, switch back to the main terminal with {{Keypress|Ctrl+Alt+F1}}.<br />
<br />
Further information on paravirtualization with KVM can be found here:<br />
[http://www.linux-kvm.org/page/Boot_from_virtio_block_device]<br />
section in the German qemu-book: [http://qemu-buch.de/de/index.php/QEMU-KVM-Buch/_Virtuelle_Hardware/_Paravirtualisierte_Ger%C3%A4tetreiber]<br />
<br />
=== Preparing a Windows guest ===<br />
Preparing a Windows guest for running with a virtio disk driver is a bit tricky.<br />
<br />
In your KVM host (running Arch Linux), download the virtio disk driver from the [http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers Fedora repository].<br />
<br />
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:<br />
qemu-img create -f qcow2 fake.img 1G<br />
Run the original Windows guest (still in the IDE mode). Add the fake disk and a CD-ROM with the driver.<br />
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<br />
<br />
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.<br />
<br />
When the installation is successful, you can turn off the virtual machine and launch it again, now with the {{Ic|virtio}} driver.<br />
<br />
qemu-kvm -drive file=windows.img,if=virtio,boot=on -m 512 -vga std<br />
<br />
{{Note|If you encounter the Blue Screen of Death, make sure you did not forget the {{Ic|-m}} parameter.}}<br />
<br />
=== Preparing a FreeBSD guest ===<br />
Install the {{ic|emulators/virtio-kmod}} port if you are using FreeBSD 8.3 or later up until 10.0-CURRENT where they are included into the kernel. After installation, add the following to your {{ic|/boot/loader.conf}} file:<br />
<br />
{{bc|<nowiki><br />
virtio_loader="YES"<br />
virtio_pci_load="YES"<br />
virtio_blk_load="YES"<br />
if_vtnet_load="YES"<br />
virtio_balloon_load="YES"<br />
</nowiki>}}<br />
<br />
Then modify your /etc/fstab by doing the following:<br />
<br />
{{bc|<nowiki><br />
sed -i/etc/fstab.bak "s/ad/vtbd/g" /etc/fstab<br />
</nowiki>}}<br />
<br />
And verify that /etc/fstab is consistent. If anything goes wrong, just boot into a rescue cd and copy /etc/fstab.bak back to /etc.fstab.<br />
<br />
== Resizing the image ==<br />
{{Warning| resizing an image containing an ntfs boot filesystem, could make the VM installed on it unbootable. One solution (really tricky and for expert users only), is shown here along with a deep explanation of the problem. http://tjworld.net/wiki/Howto/ResizeQemuDiskImages}}<br />
<br />
=== Up-to-date way ===<br />
Since version 0.13.0 of {{pkg|qemu}}, a new option has been added to {{ic|qemu-img}} executable, the {{ic|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 <br />
{{bc|qemu-img resize my_image.qcow2 +10G}}<br />
<br />
=== Old way ===<br />
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 {{Ic|fsck}} and resize the filesystem.<br />
<br />
{{bc|<nowiki>$ qemu-img convert -O raw image.qcow2 image.img<br />
$ dd if=/dev/zero of=image.img bs=1G count=0 seek=[NUMBER_OF_GB]<br />
$ qemu-img convert -O qcow2 -o cluster_size=64K image.img imageplus.qcow2<br />
$ qemu-kvm -hda imageplus.qcow2 -m 512 -cdrom </Path/to/the/ISO/Image> -boot d -vga std<br />
$ fdisk /dev/sda [delete the partition, create new one occupying whole disk]<br />
$ e2fsck -f /dev/sda1<br />
$ resize2fs /dev/sda1</nowiki><br />
}}<br />
<br />
== Enabling KSM ==<br />
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.<br />
<br />
To enable KSM, first ensure that you have installed {{Pkg|qemu-kvm}} >= 0.12.0.<br />
# pacman -Qi qemu-kvm | grep Version<br />
Version : 0.15.0-2<br />
Also ensure that your kernel is at least version 2.6.32.<br />
# uname -r<br />
3.0-ARCH<br />
If this is the case there should be a {{ic|/sys/kernel/mm/ksm/}} directory containing several files. You can turn KSM on or off by echoing a 1 or 0 to {{ic|/sys/kernel/mm/ksm/run}}.<br />
# echo 1 > /sys/kernel/mm/ksm/run<br />
If KSM is running, and there are pages to be merged (i.e. more than one similar VM is running), then {{ic|/sys/kernel/mm/ksm/pages_shared}} should be non-zero. From the kernel documentation in {{ic|Documentation/vm/ksm.txt}}:<br />
The effectiveness of KSM and MADV_MERGEABLE is shown in /sys/kernel/mm/ksm/:<br />
<br />
pages_shared - how many shared unswappable kernel pages KSM is using<br />
pages_sharing - how many more sites are sharing them i.e. how much saved<br />
pages_unshared - how many pages unique but repeatedly checked for merging<br />
pages_volatile - how many pages changing too fast to be placed in a tree<br />
full_scans - how many times all mergeable areas have been scanned<br />
<br />
A high ratio of pages_sharing to pages_shared indicates good sharing, but<br />
a high ratio of pages_unshared to pages_sharing indicates wasted effort.<br />
pages_volatile embraces several different kinds of activity, but a high<br />
proportion there would also indicate poor use of madvise MADV_MERGEABLE.<br />
<br />
An easy way to see how well KSM is performing is to simply print the contents of all the files in that directory.<br />
<br />
# for ii in /sys/kernel/mm/ksm/* ; do echo -n "$ii: " ; cat $ii ; done<br />
/sys/kernel/mm/ksm/full_scans: 151<br />
/sys/kernel/mm/ksm/max_kernel_pages: 246793<br />
/sys/kernel/mm/ksm/pages_shared: 92112<br />
/sys/kernel/mm/ksm/pages_sharing: 131355<br />
/sys/kernel/mm/ksm/pages_to_scan: 100<br />
/sys/kernel/mm/ksm/pages_unshared: 123942<br />
/sys/kernel/mm/ksm/pages_volatile: 1182<br />
/sys/kernel/mm/ksm/run: 1<br />
/sys/kernel/mm/ksm/sleep_millisecs: 20<br />
<br />
== Easy to Use for New User ==<br />
If the {{Pkg|qemu}} package has been installed, you can use a GUI tool, such as {{Pkg|qtemu}} for simple use or {{Pkg|qemu-launcher}} for particle control, to manage your virtual machine.<br />
<br />
You need to change {{Ic|qemu}} in the configure item "QEMU start command" to {{Ic|qemu-kvm}} or leave the "QEMU start command" as {{Ic|qemu}} and append {{Ic|-enable-kvm}} to the additional start options. With newer versions of {{Pkg|qemu}}, it might not be necessary to append {{Ic|-enable-kvm}} as the {{Ic|qemu}} executable will detect that KVM is running and start in the correct mode.<br />
<br />
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.<br />
<br />
== Bridged Networking ==<br />
=== Using Netcfg ===<br />
<br />
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 the {{Pkg|netcfg}} package. You will also need to install {{Pkg|bridge-utils}}.<br />
<br />
[[Netcfg#Configuring_a_bridge_for_use_with_virtual_machines_.28VMs.29]]<br />
<br />
=== Additional notes ===<br />
<br />
Other information can be found here: [[QEMU#Tap_Networking_with_QEMU]] and [[QEMU#Networking_with_VDE2]]<br />
<br />
If you are using {{Pkg|iptables}}, it is recommended for performance and security reasons to disable the firewall on the bridge:<br />
# cat >> /etc/sysctl.conf <<EOF<br />
net.bridge.bridge-nf-call-ip6tables = 0<br />
net.bridge.bridge-nf-call-iptables = 0<br />
net.bridge.bridge-nf-call-arptables = 0<br />
EOF<br />
# sysctl -p /etc/sysctl.conf<br />
<br />
See the [http://wiki.libvirt.org/page/Networking#Creating_network_initscripts libvirt wiki] and [https://bugzilla.redhat.com/show_bug.cgi?id=512206 Fedora bug 512206]<br />
<br />
Alternatively, you can configure {{Pkg|iptables}} to allow all traffic to be forwarded across the bridge by adding a rule like this:<br />
-I FORWARD -m physdev --physdev-is-bridged -j ACCEPT<br />
<br />
== Mouse integration ==<br />
To prevent the mouse from being grabbed when clicking on the guest operating system's windows, add the option {{Ic|-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.<br />
$ qemu-kvm -hda <Image_Name> -m 512 -vga std -usbdevice tablet<br />
<br />
== Mounting the QEMU image ==<br />
<br />
modprobe nbd max_part=63<br />
qemu-nbd -c /dev/nbd0 [image.img]<br />
mount /dev/nbd0p1 [/mnt/qemu]<br />
<br />
== Starting KVM virtual machines on boot up==<br />
<br />
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:<br />
<br />
virsh autostart <domain><br />
<br />
To disable autostarting:<br />
<br />
virsh autostart --disable <domain><br />
<br />
Virt-manager is equally easy having an autostart check box in the boot options of the VM.<br />
<br />
Note VMs started by QEMU or KVM from the command line are not then manageable by virt-manager. <br />
<br />
For an alternative check here: [[QEMU#Starting_QEMU_virtual_machines_on_boot]]<br />
<br />
== Tips and tricks ==<br />
=== Poor Man's Networking ===<br />
<br />
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.<br />
<br />
The basic steps are as follows:<br />
* Setup an SSH server in the host OS<br />
* (optional) Create a designated user used for the tunneling (e.g. tunneluser)<br />
* Install SSH in the VM<br />
* Setup authentication<br />
<br />
See: [[SSH]] for the setup of SSH, especially [[SSH#Forwarding_Other_Ports]]<br />
<br />
When using the default user network stack, the host is reachable at address 10.0.2.2.<br />
<br />
If everything works and you can SSH into the host, simply add something like the following to your /etc/rc.local<br />
# Local SSH Server<br />
echo "Starting SSH tunnel"<br />
sudo -u vmuser ssh tunneluser@10.0.2.2 -N -R 2213:127.0.0.1:22 -f<br />
# Random remote port (e.g. from another VM)<br />
echo "Starting random tunnel"<br />
sudo -u vmuser ssh tunneluser@10.0.2.2 -N -L 2345:127.0.0.1:2345 -f<br />
<br />
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.<br />
<br />
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.</div>Elizacathttps://wiki.archlinux.org/index.php?title=KVM&diff=203135KVM2012-05-29T03:46:41Z<p>Elizacat: /* Preparing a FreeBSD guest */ Trim whitespace</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[Category:Kernel]]<br />
{{i18n|KVM}}<br />
<br />
'''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 {{Ic|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.<br />
<br />
Using KVM, one can run multiple virtual machines running unmodified GNU/Linux, Windows, or any other operating system. (See [http://www.linux-kvm.org/page/Guest_Support_Status Guest Support Status]). Each virtual machine has private virtualized hardware: a network card, disk, graphics adapter, etc. See [http://www.linux-kvm.org/page/HOWTO KVM Howto]<br />
<br />
Differences among KVM, Xen, VMware, and QEMU can be found at the [http://www.linux-kvm.org/page/FAQ#General_KVM_information KVM FAQ].<br />
<br />
== Get the packages ==<br />
<br />
Arch Linux kernels >= 2.6.22 provide the appropriate [[Kernel_modules|kernel modules]] to support KVM.<br />
You can check if your kernel supports KVM with the following command (assuming your kernel is built with CONFIG_IKCONFIG_PROC):<br />
zgrep KVM /proc/config.gz<br />
<br />
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:<br />
grep -E "(vmx|svm)" --color=always /proc/cpuinfo<br />
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.<br />
<br />
KVM also requires a modified QEMU to launch and manage virtual machines. You can choose one of the following according to your needs:<br />
<br />
1. The {{Pkg|qemu-kvm}} package is available in the [[Official Repositories|official repositories]] ''(recommended)''.<br />
<br />
2. If you also need to use QEMU, you can choose to install {{Pkg|qemu}} >= 0.9.0 instead, which conflicts with the {{Pkg|qemu-kvm}} package. However, {{Pkg|qemu}} now provides a {{Ic|qemu-kvm}} executable ({{Ic|qemu -enable-kvm}}) that takes advantage of this technology.<br />
<br />
== Setup kernel modules ==<br />
<br />
First, you need to add your user account into the {{Ic|kvm}} group to use the {{ic|/dev/kvm}} device.<br />
gpasswd -a <Your_Login_Name> kvm<br />
<br />
Secondly, you have to choose one of the following depending on the manufacturer of your CPU.<br />
<br />
1. If you have Intel's VT-x extensions, modprobe the {{Ic|kvm}} and {{Ic|kvm-intel}} modules.<br />
modprobe kvm<br />
modprobe kvm-intel<br />
<br />
2. If you have AMD's AMD-V (code name "Pacifica") extensions, modprobe the {{Ic|kvm}} and {{Ic|kvm-amd}} modules.<br />
modprobe kvm<br />
modprobe kvm-amd<br />
<br />
If modprobing {{Ic|kvm}} succeeds, but modprobing {{Ic|kvm-intel}} or {{Ic|kvm-amd}} fails (but {{ic|/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 {{Ic|dmesg}} after having failed to modprobe will tell.<br />
<br />
If you want these modules to persist, add them to {{ic|/etc/rc.conf}} or {{ic|/etc/mkinitcpio.conf}}.<br />
<br />
== How to use KVM ==<br />
<br />
# Create a guest OS image: {{bc|$ qemu-img create -f qcow2 <Image_Name> <size> }}<br />
# Install the guest OS:<br>A CD/DVD image (ISO file) can be used for the installation. {{bc|$ qemu-kvm -hda <Image_Name> -m 512 -cdrom /path/to/the/ISO/image -boot d -vga std }}<br />
# Running the system: {{bc|$ qemu-kvm -hda <Image_Name> -m 512 -vga std}}<br />
<br />
{{Note| you may want to assign multiple CPUs to the guest by using -smp X (where X - number of CPUs). The maximum number of assigned CPUs for one guest is 16.}} <br />
<br />
{{Note|The default amount of main memory assigned to KVM guests is 128 MB. If that is not sufficient, add the {{Ic|-m}} argument and the desired amount of main memory specified in megabytes (e.g. {{Ic|-m 1024}}). Also note that recent Windows operating systems (tested with Windows Vista and Windows 7) require the {{Ic|qcow2}} disk image format. Other disk image formats may give a 0x80070057 error during the installation.}}<br />
<br />
See '''[[QEMU]]''' for more information, and the ''[[QEMU#Using_the_Kernel-based_Virtual_Machine|Using the Kernel-based Virtual Machine]]'' section.<br />
<br />
== Paravirtualized guests (virtio) ==<br />
<br />
KVM offers guests the ability to use paravirtualized block and network devices, which leads to better performance and lower overhead.<br />
Linux has had this ability with its virtio-modules since kernel 2.6.25.<br />
For Windows, a paravirtualized network driver can be obtained here: [http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers].<br />
FreeBSD has the ability to use virtio drivers since 10.0 (unreleased). A backport of the drivers are available in the port {{ic|emulators/virtio-kmod}} for FreeBSD 8.3 and 9.0.<br />
<br />
A virtio block device requires the option {{Ic|-drive}} instead of the simple {{Ic|-hd*}} plus {{Ic|<nowiki>if=virtio</nowiki>}}:<br />
$ qemu-kvm -boot order=c -drive file=drive.img,if=virtio<br />
(ps: {{Ic|<nowiki>-boot order=c</nowiki>}} is absolutely required when you want to boot from it. There is no auto-detection as with {{Ic|-hd*}} ...)<br />
<br />
Almost the same goes for the network:<br />
$ qemu-kvm -net nic,model=virtio<br />
<br />
=== Preparing an (Arch) Linux guest ===<br />
{{Note|The arch setup scripts for the installer does not handle vd* disk devices correctly and required additional steps as detailed in this post https://bbs.archlinux.org/viewtopic.php?pid&#61;1042283}}<br />
<br />
To use virtio devices after an Arch Linux guest has been installed, the following modules can be loaded in the guest: {{Ic|virtio}}, {{Ic|virtio_pci}}, {{Ic|virtio_blk}}, {{Ic|virtio_net}}, and {{Ic|virtio_ring}} (for 32-bit guests, the specific "virtio" module is not necessary).<br />
<br />
If you want to boot from a virtio disk, the initial ramdisk must be [[mkinitcpio|rebuilt]]. Add the appropriate modules in {{ic|/etc/mkinitcpio.conf}} like this:<br />
MODULES="virtio_blk virtio_pci virtio_net"<br />
and rebuild the initial ramdisk:<br />
# mkinitcpio -p linux<br />
<br />
Virtio disks are recognized with the prefix '''''v''''' (e.g. ''v''da, ''v''db, etc.); therefore, changes must be made in at least {{ic|/etc/fstab}} and {{ic|/boot/grub/menu.lst}} when booting from a virtio disk. When using grub-pc which references disks by [[Persistent_block_device_naming#By-uuid|UUID's]], nothing has to be done.<br />
<br />
Edit or create {{ic|/boot/grub/device.map}}:<br />
(hd0) /dev/vda<br />
<br />
{{Note|The following may be outdated since a new official installation ISO has been released (2011.08.19).}}<br />
To enable virtio at Arch Linux installation time, manual GRUB installation is required (for arch-release-media 2010.05)<br />
Though AIF correctly detects the virtio disks and sets up the right prefixes, the {{ic|/boot/grub/device.map}} file must be created before configuring the bootloader.<br />
<br />
So when installing Arch Linux, you can install GRUB by switching to another virtual terminal ({{Keypress|Ctrl+Alt+F2}}) and running the following commands.<br />
# grub<br />
> device (hd0) /dev/vda<br />
> root (hd0,0)<br />
> setup (hd0)<br />
> quit<br />
<br />
{{Note|(hd0,0) numbering may change depending on your configuration. Reference: http://lists.mandriva.com/bugs/2009-08/msg03424.php}}<br />
<br />
Once you have installed GRUB, switch back to the main terminal with {{Keypress|Ctrl+Alt+F1}}.<br />
<br />
Further information on paravirtualization with KVM can be found here:<br />
[http://www.linux-kvm.org/page/Boot_from_virtio_block_device]<br />
section in the German qemu-book: [http://qemu-buch.de/de/index.php/QEMU-KVM-Buch/_Virtuelle_Hardware/_Paravirtualisierte_Ger%C3%A4tetreiber]<br />
<br />
=== Preparing a Windows guest ===<br />
Preparing a Windows guest for running with a virtio disk driver is a bit tricky.<br />
<br />
In your KVM host (running Arch Linux), download the virtio disk driver from the [http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers Fedora repository].<br />
<br />
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:<br />
qemu-img create -f qcow2 fake.img 1G<br />
Run the original Windows guest (still in the IDE mode). Add the fake disk and a CD-ROM with the driver.<br />
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<br />
<br />
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.<br />
<br />
When the installation is successful, you can turn off the virtual machine and launch it again, now with the {{Ic|virtio}} driver.<br />
<br />
qemu-kvm -drive file=windows.img,if=virtio,boot=on -m 512 -vga std<br />
<br />
{{Note|If you encounter the Blue Screen of Death, make sure you did not forget the {{Ic|-m}} parameter.}}<br />
<br />
=== Preparing a FreeBSD guest ===<br />
Install the {{ic|emulators/virtio-kmod}} port if you are using FreeBSD 8.3 or later up until 10.0-CURRENT where they are included into the kernel. After installation, add the following to your {{ic|/boot/loader.conf}} file:<br />
<br />
{{bc|<nowiki><br />
virtio_loader="YES"<br />
virtio_pci_load="YES"<br />
virtio_blk_load="YES"<br />
if_vtnet_load="YES"<br />
virtio_balloon_load="YES"<br />
</nowiki>}}<br />
<br />
Then modify your /etc/fstab by doing the following:<br />
<br />
{{bc|<nowiki><br />
sed -i/etc/fstab.bak "s/ad/vtbd/g" /etc/fstab<br />
</nowiki>}}<br />
<br />
And verify that /etc/fstab is kosher. If anything goes wrong, just boot into a rescue cd and copy /etc/fstab.bak back to /etc.fstab.<br />
<br />
== Resizing the image ==<br />
{{Warning| resizing an image containing an ntfs boot filesystem, could make the VM installed on it unbootable. One solution (really tricky and for expert users only), is shown here along with a deep explanation of the problem. http://tjworld.net/wiki/Howto/ResizeQemuDiskImages}}<br />
<br />
=== Up-to-date way ===<br />
Since version 0.13.0 of {{pkg|qemu}}, a new option has been added to {{ic|qemu-img}} executable, the {{ic|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 <br />
{{bc|qemu-img resize my_image.qcow2 +10G}}<br />
<br />
=== Old way ===<br />
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 {{Ic|fsck}} and resize the filesystem.<br />
<br />
{{bc|<nowiki>$ qemu-img convert -O raw image.qcow2 image.img<br />
$ dd if=/dev/zero of=image.img bs=1G count=0 seek=[NUMBER_OF_GB]<br />
$ qemu-img convert -O qcow2 -o cluster_size=64K image.img imageplus.qcow2<br />
$ qemu-kvm -hda imageplus.qcow2 -m 512 -cdrom </Path/to/the/ISO/Image> -boot d -vga std<br />
$ fdisk /dev/sda [delete the partition, create new one occupying whole disk]<br />
$ e2fsck -f /dev/sda1<br />
$ resize2fs /dev/sda1</nowiki><br />
}}<br />
<br />
== Enabling KSM ==<br />
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.<br />
<br />
To enable KSM, first ensure that you have installed {{Pkg|qemu-kvm}} >= 0.12.0.<br />
# pacman -Qi qemu-kvm | grep Version<br />
Version : 0.15.0-2<br />
Also ensure that your kernel is at least version 2.6.32.<br />
# uname -r<br />
3.0-ARCH<br />
If this is the case there should be a {{ic|/sys/kernel/mm/ksm/}} directory containing several files. You can turn KSM on or off by echoing a 1 or 0 to {{ic|/sys/kernel/mm/ksm/run}}.<br />
# echo 1 > /sys/kernel/mm/ksm/run<br />
If KSM is running, and there are pages to be merged (i.e. more than one similar VM is running), then {{ic|/sys/kernel/mm/ksm/pages_shared}} should be non-zero. From the kernel documentation in {{ic|Documentation/vm/ksm.txt}}:<br />
The effectiveness of KSM and MADV_MERGEABLE is shown in /sys/kernel/mm/ksm/:<br />
<br />
pages_shared - how many shared unswappable kernel pages KSM is using<br />
pages_sharing - how many more sites are sharing them i.e. how much saved<br />
pages_unshared - how many pages unique but repeatedly checked for merging<br />
pages_volatile - how many pages changing too fast to be placed in a tree<br />
full_scans - how many times all mergeable areas have been scanned<br />
<br />
A high ratio of pages_sharing to pages_shared indicates good sharing, but<br />
a high ratio of pages_unshared to pages_sharing indicates wasted effort.<br />
pages_volatile embraces several different kinds of activity, but a high<br />
proportion there would also indicate poor use of madvise MADV_MERGEABLE.<br />
<br />
An easy way to see how well KSM is performing is to simply print the contents of all the files in that directory.<br />
<br />
# for ii in /sys/kernel/mm/ksm/* ; do echo -n "$ii: " ; cat $ii ; done<br />
/sys/kernel/mm/ksm/full_scans: 151<br />
/sys/kernel/mm/ksm/max_kernel_pages: 246793<br />
/sys/kernel/mm/ksm/pages_shared: 92112<br />
/sys/kernel/mm/ksm/pages_sharing: 131355<br />
/sys/kernel/mm/ksm/pages_to_scan: 100<br />
/sys/kernel/mm/ksm/pages_unshared: 123942<br />
/sys/kernel/mm/ksm/pages_volatile: 1182<br />
/sys/kernel/mm/ksm/run: 1<br />
/sys/kernel/mm/ksm/sleep_millisecs: 20<br />
<br />
== Easy to Use for New User ==<br />
If the {{Pkg|qemu}} package has been installed, you can use a GUI tool, such as {{Pkg|qtemu}} for simple use or {{Pkg|qemu-launcher}} for particle control, to manage your virtual machine.<br />
<br />
You need to change {{Ic|qemu}} in the configure item "QEMU start command" to {{Ic|qemu-kvm}} or leave the "QEMU start command" as {{Ic|qemu}} and append {{Ic|-enable-kvm}} to the additional start options. With newer versions of {{Pkg|qemu}}, it might not be necessary to append {{Ic|-enable-kvm}} as the {{Ic|qemu}} executable will detect that KVM is running and start in the correct mode.<br />
<br />
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.<br />
<br />
== Bridged Networking ==<br />
=== Using Netcfg ===<br />
<br />
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 the {{Pkg|netcfg}} package. You will also need to install {{Pkg|bridge-utils}}.<br />
<br />
[[Netcfg#Configuring_a_bridge_for_use_with_virtual_machines_.28VMs.29]]<br />
<br />
=== Additional notes ===<br />
<br />
Other information can be found here: [[QEMU#Tap_Networking_with_QEMU]] and [[QEMU#Networking_with_VDE2]]<br />
<br />
If you are using {{Pkg|iptables}}, it is recommended for performance and security reasons to disable the firewall on the bridge:<br />
# cat >> /etc/sysctl.conf <<EOF<br />
net.bridge.bridge-nf-call-ip6tables = 0<br />
net.bridge.bridge-nf-call-iptables = 0<br />
net.bridge.bridge-nf-call-arptables = 0<br />
EOF<br />
# sysctl -p /etc/sysctl.conf<br />
<br />
See the [http://wiki.libvirt.org/page/Networking#Creating_network_initscripts libvirt wiki] and [https://bugzilla.redhat.com/show_bug.cgi?id=512206 Fedora bug 512206]<br />
<br />
Alternatively, you can configure {{Pkg|iptables}} to allow all traffic to be forwarded across the bridge by adding a rule like this:<br />
-I FORWARD -m physdev --physdev-is-bridged -j ACCEPT<br />
<br />
== Mouse integration ==<br />
To prevent the mouse from being grabbed when clicking on the guest operating system's windows, add the option {{Ic|-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.<br />
$ qemu-kvm -hda <Image_Name> -m 512 -vga std -usbdevice tablet<br />
<br />
== Mounting the QEMU image ==<br />
<br />
modprobe nbd max_part=63<br />
qemu-nbd -c /dev/nbd0 [image.img]<br />
mount /dev/nbd0p1 [/mnt/qemu]<br />
<br />
== Starting KVM virtual machines on boot up==<br />
<br />
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:<br />
<br />
virsh autostart <domain><br />
<br />
To disable autostarting:<br />
<br />
virsh autostart --disable <domain><br />
<br />
Virt-manager is equally easy having an autostart check box in the boot options of the VM.<br />
<br />
Note VMs started by QEMU or KVM from the command line are not then manageable by virt-manager. <br />
<br />
For an alternative check here: [[QEMU#Starting_QEMU_virtual_machines_on_boot]]<br />
<br />
== Tips and tricks ==<br />
=== Poor Man's Networking ===<br />
<br />
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.<br />
<br />
The basic steps are as follows:<br />
* Setup an SSH server in the host OS<br />
* (optional) Create a designated user used for the tunneling (e.g. tunneluser)<br />
* Install SSH in the VM<br />
* Setup authentication<br />
<br />
See: [[SSH]] for the setup of SSH, especially [[SSH#Forwarding_Other_Ports]]<br />
<br />
When using the default user network stack, the host is reachable at address 10.0.2.2.<br />
<br />
If everything works and you can SSH into the host, simply add something like the following to your /etc/rc.local<br />
# Local SSH Server<br />
echo "Starting SSH tunnel"<br />
sudo -u vmuser ssh tunneluser@10.0.2.2 -N -R 2213:127.0.0.1:22 -f<br />
# Random remote port (e.g. from another VM)<br />
echo "Starting random tunnel"<br />
sudo -u vmuser ssh tunneluser@10.0.2.2 -N -L 2345:127.0.0.1:2345 -f<br />
<br />
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.<br />
<br />
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.</div>Elizacathttps://wiki.archlinux.org/index.php?title=KVM&diff=203134KVM2012-05-29T03:45:24Z<p>Elizacat: oops.</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[Category:Kernel]]<br />
{{i18n|KVM}}<br />
<br />
'''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 {{Ic|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.<br />
<br />
Using KVM, one can run multiple virtual machines running unmodified GNU/Linux, Windows, or any other operating system. (See [http://www.linux-kvm.org/page/Guest_Support_Status Guest Support Status]). Each virtual machine has private virtualized hardware: a network card, disk, graphics adapter, etc. See [http://www.linux-kvm.org/page/HOWTO KVM Howto]<br />
<br />
Differences among KVM, Xen, VMware, and QEMU can be found at the [http://www.linux-kvm.org/page/FAQ#General_KVM_information KVM FAQ].<br />
<br />
== Get the packages ==<br />
<br />
Arch Linux kernels >= 2.6.22 provide the appropriate [[Kernel_modules|kernel modules]] to support KVM.<br />
You can check if your kernel supports KVM with the following command (assuming your kernel is built with CONFIG_IKCONFIG_PROC):<br />
zgrep KVM /proc/config.gz<br />
<br />
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:<br />
grep -E "(vmx|svm)" --color=always /proc/cpuinfo<br />
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.<br />
<br />
KVM also requires a modified QEMU to launch and manage virtual machines. You can choose one of the following according to your needs:<br />
<br />
1. The {{Pkg|qemu-kvm}} package is available in the [[Official Repositories|official repositories]] ''(recommended)''.<br />
<br />
2. If you also need to use QEMU, you can choose to install {{Pkg|qemu}} >= 0.9.0 instead, which conflicts with the {{Pkg|qemu-kvm}} package. However, {{Pkg|qemu}} now provides a {{Ic|qemu-kvm}} executable ({{Ic|qemu -enable-kvm}}) that takes advantage of this technology.<br />
<br />
== Setup kernel modules ==<br />
<br />
First, you need to add your user account into the {{Ic|kvm}} group to use the {{ic|/dev/kvm}} device.<br />
gpasswd -a <Your_Login_Name> kvm<br />
<br />
Secondly, you have to choose one of the following depending on the manufacturer of your CPU.<br />
<br />
1. If you have Intel's VT-x extensions, modprobe the {{Ic|kvm}} and {{Ic|kvm-intel}} modules.<br />
modprobe kvm<br />
modprobe kvm-intel<br />
<br />
2. If you have AMD's AMD-V (code name "Pacifica") extensions, modprobe the {{Ic|kvm}} and {{Ic|kvm-amd}} modules.<br />
modprobe kvm<br />
modprobe kvm-amd<br />
<br />
If modprobing {{Ic|kvm}} succeeds, but modprobing {{Ic|kvm-intel}} or {{Ic|kvm-amd}} fails (but {{ic|/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 {{Ic|dmesg}} after having failed to modprobe will tell.<br />
<br />
If you want these modules to persist, add them to {{ic|/etc/rc.conf}} or {{ic|/etc/mkinitcpio.conf}}.<br />
<br />
== How to use KVM ==<br />
<br />
# Create a guest OS image: {{bc|$ qemu-img create -f qcow2 <Image_Name> <size> }}<br />
# Install the guest OS:<br>A CD/DVD image (ISO file) can be used for the installation. {{bc|$ qemu-kvm -hda <Image_Name> -m 512 -cdrom /path/to/the/ISO/image -boot d -vga std }}<br />
# Running the system: {{bc|$ qemu-kvm -hda <Image_Name> -m 512 -vga std}}<br />
<br />
{{Note| you may want to assign multiple CPUs to the guest by using -smp X (where X - number of CPUs). The maximum number of assigned CPUs for one guest is 16.}} <br />
<br />
{{Note|The default amount of main memory assigned to KVM guests is 128 MB. If that is not sufficient, add the {{Ic|-m}} argument and the desired amount of main memory specified in megabytes (e.g. {{Ic|-m 1024}}). Also note that recent Windows operating systems (tested with Windows Vista and Windows 7) require the {{Ic|qcow2}} disk image format. Other disk image formats may give a 0x80070057 error during the installation.}}<br />
<br />
See '''[[QEMU]]''' for more information, and the ''[[QEMU#Using_the_Kernel-based_Virtual_Machine|Using the Kernel-based Virtual Machine]]'' section.<br />
<br />
== Paravirtualized guests (virtio) ==<br />
<br />
KVM offers guests the ability to use paravirtualized block and network devices, which leads to better performance and lower overhead.<br />
Linux has had this ability with its virtio-modules since kernel 2.6.25.<br />
For Windows, a paravirtualized network driver can be obtained here: [http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers].<br />
FreeBSD has the ability to use virtio drivers since 10.0 (unreleased). A backport of the drivers are available in the port {{ic|emulators/virtio-kmod}} for FreeBSD 8.3 and 9.0.<br />
<br />
A virtio block device requires the option {{Ic|-drive}} instead of the simple {{Ic|-hd*}} plus {{Ic|<nowiki>if=virtio</nowiki>}}:<br />
$ qemu-kvm -boot order=c -drive file=drive.img,if=virtio<br />
(ps: {{Ic|<nowiki>-boot order=c</nowiki>}} is absolutely required when you want to boot from it. There is no auto-detection as with {{Ic|-hd*}} ...)<br />
<br />
Almost the same goes for the network:<br />
$ qemu-kvm -net nic,model=virtio<br />
<br />
=== Preparing an (Arch) Linux guest ===<br />
{{Note|The arch setup scripts for the installer does not handle vd* disk devices correctly and required additional steps as detailed in this post https://bbs.archlinux.org/viewtopic.php?pid&#61;1042283}}<br />
<br />
To use virtio devices after an Arch Linux guest has been installed, the following modules can be loaded in the guest: {{Ic|virtio}}, {{Ic|virtio_pci}}, {{Ic|virtio_blk}}, {{Ic|virtio_net}}, and {{Ic|virtio_ring}} (for 32-bit guests, the specific "virtio" module is not necessary).<br />
<br />
If you want to boot from a virtio disk, the initial ramdisk must be [[mkinitcpio|rebuilt]]. Add the appropriate modules in {{ic|/etc/mkinitcpio.conf}} like this:<br />
MODULES="virtio_blk virtio_pci virtio_net"<br />
and rebuild the initial ramdisk:<br />
# mkinitcpio -p linux<br />
<br />
Virtio disks are recognized with the prefix '''''v''''' (e.g. ''v''da, ''v''db, etc.); therefore, changes must be made in at least {{ic|/etc/fstab}} and {{ic|/boot/grub/menu.lst}} when booting from a virtio disk. When using grub-pc which references disks by [[Persistent_block_device_naming#By-uuid|UUID's]], nothing has to be done.<br />
<br />
Edit or create {{ic|/boot/grub/device.map}}:<br />
(hd0) /dev/vda<br />
<br />
{{Note|The following may be outdated since a new official installation ISO has been released (2011.08.19).}}<br />
To enable virtio at Arch Linux installation time, manual GRUB installation is required (for arch-release-media 2010.05)<br />
Though AIF correctly detects the virtio disks and sets up the right prefixes, the {{ic|/boot/grub/device.map}} file must be created before configuring the bootloader.<br />
<br />
So when installing Arch Linux, you can install GRUB by switching to another virtual terminal ({{Keypress|Ctrl+Alt+F2}}) and running the following commands.<br />
# grub<br />
> device (hd0) /dev/vda<br />
> root (hd0,0)<br />
> setup (hd0)<br />
> quit<br />
<br />
{{Note|(hd0,0) numbering may change depending on your configuration. Reference: http://lists.mandriva.com/bugs/2009-08/msg03424.php}}<br />
<br />
Once you have installed GRUB, switch back to the main terminal with {{Keypress|Ctrl+Alt+F1}}.<br />
<br />
Further information on paravirtualization with KVM can be found here:<br />
[http://www.linux-kvm.org/page/Boot_from_virtio_block_device]<br />
section in the German qemu-book: [http://qemu-buch.de/de/index.php/QEMU-KVM-Buch/_Virtuelle_Hardware/_Paravirtualisierte_Ger%C3%A4tetreiber]<br />
<br />
=== Preparing a Windows guest ===<br />
Preparing a Windows guest for running with a virtio disk driver is a bit tricky.<br />
<br />
In your KVM host (running Arch Linux), download the virtio disk driver from the [http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers Fedora repository].<br />
<br />
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:<br />
qemu-img create -f qcow2 fake.img 1G<br />
Run the original Windows guest (still in the IDE mode). Add the fake disk and a CD-ROM with the driver.<br />
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<br />
<br />
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.<br />
<br />
When the installation is successful, you can turn off the virtual machine and launch it again, now with the {{Ic|virtio}} driver.<br />
<br />
qemu-kvm -drive file=windows.img,if=virtio,boot=on -m 512 -vga std<br />
<br />
{{Note|If you encounter the Blue Screen of Death, make sure you did not forget the {{Ic|-m}} parameter.}}<br />
<br />
=== Preparing a FreeBSD guest ===<br />
Install the {{ic|emulators/virtio-kmod}} port if you are using FreeBSD 8.3 or later up until 10.0-CURRENT where they are included into the kernel. After installation, add the following to your {{ic|/boot/loader.conf}} file:<br />
<br />
{{bc|<nowiki><br />
virtio_loader="YES"<br />
virtio_pci_load="YES"<br />
virtio_blk_load="YES"<br />
if_vtnet_load="YES"<br />
virtio_balloon_load="YES"<br />
</nowiki>}}<br />
<br />
Then modify your /etc/fstab by doing the following:<br />
<br />
{{bc|<nowiki><br />
sed -i/etc/fstab.bak "s/ad/vtbd/g" /etc/fstab<br />
</nowiki>}}<br />
<br />
And verify that /etc/fstab is kosher. If anything goes wrong, just boot into a rescue cd and copy /etc/fstab.bak back to /etc.fstab.<br />
<br />
<br />
== Resizing the image ==<br />
{{Warning| resizing an image containing an ntfs boot filesystem, could make the VM installed on it unbootable. One solution (really tricky and for expert users only), is shown here along with a deep explanation of the problem. http://tjworld.net/wiki/Howto/ResizeQemuDiskImages}}<br />
<br />
=== Up-to-date way ===<br />
Since version 0.13.0 of {{pkg|qemu}}, a new option has been added to {{ic|qemu-img}} executable, the {{ic|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 <br />
{{bc|qemu-img resize my_image.qcow2 +10G}}<br />
<br />
=== Old way ===<br />
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 {{Ic|fsck}} and resize the filesystem.<br />
<br />
{{bc|<nowiki>$ qemu-img convert -O raw image.qcow2 image.img<br />
$ dd if=/dev/zero of=image.img bs=1G count=0 seek=[NUMBER_OF_GB]<br />
$ qemu-img convert -O qcow2 -o cluster_size=64K image.img imageplus.qcow2<br />
$ qemu-kvm -hda imageplus.qcow2 -m 512 -cdrom </Path/to/the/ISO/Image> -boot d -vga std<br />
$ fdisk /dev/sda [delete the partition, create new one occupying whole disk]<br />
$ e2fsck -f /dev/sda1<br />
$ resize2fs /dev/sda1</nowiki><br />
}}<br />
<br />
== Enabling KSM ==<br />
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.<br />
<br />
To enable KSM, first ensure that you have installed {{Pkg|qemu-kvm}} >= 0.12.0.<br />
# pacman -Qi qemu-kvm | grep Version<br />
Version : 0.15.0-2<br />
Also ensure that your kernel is at least version 2.6.32.<br />
# uname -r<br />
3.0-ARCH<br />
If this is the case there should be a {{ic|/sys/kernel/mm/ksm/}} directory containing several files. You can turn KSM on or off by echoing a 1 or 0 to {{ic|/sys/kernel/mm/ksm/run}}.<br />
# echo 1 > /sys/kernel/mm/ksm/run<br />
If KSM is running, and there are pages to be merged (i.e. more than one similar VM is running), then {{ic|/sys/kernel/mm/ksm/pages_shared}} should be non-zero. From the kernel documentation in {{ic|Documentation/vm/ksm.txt}}:<br />
The effectiveness of KSM and MADV_MERGEABLE is shown in /sys/kernel/mm/ksm/:<br />
<br />
pages_shared - how many shared unswappable kernel pages KSM is using<br />
pages_sharing - how many more sites are sharing them i.e. how much saved<br />
pages_unshared - how many pages unique but repeatedly checked for merging<br />
pages_volatile - how many pages changing too fast to be placed in a tree<br />
full_scans - how many times all mergeable areas have been scanned<br />
<br />
A high ratio of pages_sharing to pages_shared indicates good sharing, but<br />
a high ratio of pages_unshared to pages_sharing indicates wasted effort.<br />
pages_volatile embraces several different kinds of activity, but a high<br />
proportion there would also indicate poor use of madvise MADV_MERGEABLE.<br />
<br />
An easy way to see how well KSM is performing is to simply print the contents of all the files in that directory.<br />
<br />
# for ii in /sys/kernel/mm/ksm/* ; do echo -n "$ii: " ; cat $ii ; done<br />
/sys/kernel/mm/ksm/full_scans: 151<br />
/sys/kernel/mm/ksm/max_kernel_pages: 246793<br />
/sys/kernel/mm/ksm/pages_shared: 92112<br />
/sys/kernel/mm/ksm/pages_sharing: 131355<br />
/sys/kernel/mm/ksm/pages_to_scan: 100<br />
/sys/kernel/mm/ksm/pages_unshared: 123942<br />
/sys/kernel/mm/ksm/pages_volatile: 1182<br />
/sys/kernel/mm/ksm/run: 1<br />
/sys/kernel/mm/ksm/sleep_millisecs: 20<br />
<br />
== Easy to Use for New User ==<br />
If the {{Pkg|qemu}} package has been installed, you can use a GUI tool, such as {{Pkg|qtemu}} for simple use or {{Pkg|qemu-launcher}} for particle control, to manage your virtual machine.<br />
<br />
You need to change {{Ic|qemu}} in the configure item "QEMU start command" to {{Ic|qemu-kvm}} or leave the "QEMU start command" as {{Ic|qemu}} and append {{Ic|-enable-kvm}} to the additional start options. With newer versions of {{Pkg|qemu}}, it might not be necessary to append {{Ic|-enable-kvm}} as the {{Ic|qemu}} executable will detect that KVM is running and start in the correct mode.<br />
<br />
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.<br />
<br />
== Bridged Networking ==<br />
=== Using Netcfg ===<br />
<br />
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 the {{Pkg|netcfg}} package. You will also need to install {{Pkg|bridge-utils}}.<br />
<br />
[[Netcfg#Configuring_a_bridge_for_use_with_virtual_machines_.28VMs.29]]<br />
<br />
=== Additional notes ===<br />
<br />
Other information can be found here: [[QEMU#Tap_Networking_with_QEMU]] and [[QEMU#Networking_with_VDE2]]<br />
<br />
If you are using {{Pkg|iptables}}, it is recommended for performance and security reasons to disable the firewall on the bridge:<br />
# cat >> /etc/sysctl.conf <<EOF<br />
net.bridge.bridge-nf-call-ip6tables = 0<br />
net.bridge.bridge-nf-call-iptables = 0<br />
net.bridge.bridge-nf-call-arptables = 0<br />
EOF<br />
# sysctl -p /etc/sysctl.conf<br />
<br />
See the [http://wiki.libvirt.org/page/Networking#Creating_network_initscripts libvirt wiki] and [https://bugzilla.redhat.com/show_bug.cgi?id=512206 Fedora bug 512206]<br />
<br />
Alternatively, you can configure {{Pkg|iptables}} to allow all traffic to be forwarded across the bridge by adding a rule like this:<br />
-I FORWARD -m physdev --physdev-is-bridged -j ACCEPT<br />
<br />
== Mouse integration ==<br />
To prevent the mouse from being grabbed when clicking on the guest operating system's windows, add the option {{Ic|-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.<br />
$ qemu-kvm -hda <Image_Name> -m 512 -vga std -usbdevice tablet<br />
<br />
== Mounting the QEMU image ==<br />
<br />
modprobe nbd max_part=63<br />
qemu-nbd -c /dev/nbd0 [image.img]<br />
mount /dev/nbd0p1 [/mnt/qemu]<br />
<br />
== Starting KVM virtual machines on boot up==<br />
<br />
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:<br />
<br />
virsh autostart <domain><br />
<br />
To disable autostarting:<br />
<br />
virsh autostart --disable <domain><br />
<br />
Virt-manager is equally easy having an autostart check box in the boot options of the VM.<br />
<br />
Note VMs started by QEMU or KVM from the command line are not then manageable by virt-manager. <br />
<br />
For an alternative check here: [[QEMU#Starting_QEMU_virtual_machines_on_boot]]<br />
<br />
== Tips and tricks ==<br />
=== Poor Man's Networking ===<br />
<br />
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.<br />
<br />
The basic steps are as follows:<br />
* Setup an SSH server in the host OS<br />
* (optional) Create a designated user used for the tunneling (e.g. tunneluser)<br />
* Install SSH in the VM<br />
* Setup authentication<br />
<br />
See: [[SSH]] for the setup of SSH, especially [[SSH#Forwarding_Other_Ports]]<br />
<br />
When using the default user network stack, the host is reachable at address 10.0.2.2.<br />
<br />
If everything works and you can SSH into the host, simply add something like the following to your /etc/rc.local<br />
# Local SSH Server<br />
echo "Starting SSH tunnel"<br />
sudo -u vmuser ssh tunneluser@10.0.2.2 -N -R 2213:127.0.0.1:22 -f<br />
# Random remote port (e.g. from another VM)<br />
echo "Starting random tunnel"<br />
sudo -u vmuser ssh tunneluser@10.0.2.2 -N -L 2345:127.0.0.1:2345 -f<br />
<br />
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.<br />
<br />
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.</div>Elizacathttps://wiki.archlinux.org/index.php?title=KVM&diff=203133KVM2012-05-29T03:40:54Z<p>Elizacat: Mention FreeBSD and give instructions</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[Category:Kernel]]<br />
{{i18n|KVM}}<br />
<br />
'''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 {{Ic|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.<br />
<br />
Using KVM, one can run multiple virtual machines running unmodified GNU/Linux, Windows, or any other operating system. (See [http://www.linux-kvm.org/page/Guest_Support_Status Guest Support Status]). Each virtual machine has private virtualized hardware: a network card, disk, graphics adapter, etc. See [http://www.linux-kvm.org/page/HOWTO KVM Howto]<br />
<br />
Differences among KVM, Xen, VMware, and QEMU can be found at the [http://www.linux-kvm.org/page/FAQ#General_KVM_information KVM FAQ].<br />
<br />
== Get the packages ==<br />
<br />
Arch Linux kernels >= 2.6.22 provide the appropriate [[Kernel_modules|kernel modules]] to support KVM.<br />
You can check if your kernel supports KVM with the following command (assuming your kernel is built with CONFIG_IKCONFIG_PROC):<br />
zgrep KVM /proc/config.gz<br />
<br />
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:<br />
grep -E "(vmx|svm)" --color=always /proc/cpuinfo<br />
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.<br />
<br />
KVM also requires a modified QEMU to launch and manage virtual machines. You can choose one of the following according to your needs:<br />
<br />
1. The {{Pkg|qemu-kvm}} package is available in the [[Official Repositories|official repositories]] ''(recommended)''.<br />
<br />
2. If you also need to use QEMU, you can choose to install {{Pkg|qemu}} >= 0.9.0 instead, which conflicts with the {{Pkg|qemu-kvm}} package. However, {{Pkg|qemu}} now provides a {{Ic|qemu-kvm}} executable ({{Ic|qemu -enable-kvm}}) that takes advantage of this technology.<br />
<br />
== Setup kernel modules ==<br />
<br />
First, you need to add your user account into the {{Ic|kvm}} group to use the {{ic|/dev/kvm}} device.<br />
gpasswd -a <Your_Login_Name> kvm<br />
<br />
Secondly, you have to choose one of the following depending on the manufacturer of your CPU.<br />
<br />
1. If you have Intel's VT-x extensions, modprobe the {{Ic|kvm}} and {{Ic|kvm-intel}} modules.<br />
modprobe kvm<br />
modprobe kvm-intel<br />
<br />
2. If you have AMD's AMD-V (code name "Pacifica") extensions, modprobe the {{Ic|kvm}} and {{Ic|kvm-amd}} modules.<br />
modprobe kvm<br />
modprobe kvm-amd<br />
<br />
If modprobing {{Ic|kvm}} succeeds, but modprobing {{Ic|kvm-intel}} or {{Ic|kvm-amd}} fails (but {{ic|/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 {{Ic|dmesg}} after having failed to modprobe will tell.<br />
<br />
<br />
<br />
If you want these modules to persist, add them to {{ic|/etc/rc.conf}} or {{ic|/etc/mkinitcpio.conf}}.<br />
<br />
== How to use KVM ==<br />
<br />
# Create a guest OS image: {{bc|$ qemu-img create -f qcow2 <Image_Name> <size> }}<br />
# Install the guest OS:<br>A CD/DVD image (ISO file) can be used for the installation. {{bc|$ qemu-kvm -hda <Image_Name> -m 512 -cdrom /path/to/the/ISO/image -boot d -vga std }}<br />
# Running the system: {{bc|$ qemu-kvm -hda <Image_Name> -m 512 -vga std}}<br />
<br />
{{Note| you may want to assign multiple CPUs to the guest by using -smp X (where X - number of CPUs). The maximum number of assigned CPUs for one guest is 16.}} <br />
<br />
{{Note|The default amount of main memory assigned to KVM guests is 128 MB. If that is not sufficient, add the {{Ic|-m}} argument and the desired amount of main memory specified in megabytes (e.g. {{Ic|-m 1024}}). Also note that recent Windows operating systems (tested with Windows Vista and Windows 7) require the {{Ic|qcow2}} disk image format. Other disk image formats may give a 0x80070057 error during the installation.}}<br />
<br />
See '''[[QEMU]]''' for more information, and the ''[[QEMU#Using_the_Kernel-based_Virtual_Machine|Using the Kernel-based Virtual Machine]]'' section.<br />
<br />
== Paravirtualized guests (virtio) ==<br />
<br />
KVM offers guests the ability to use paravirtualized block and network devices, which leads to better performance and lower overhead.<br />
Linux has had this ability with its virtio-modules since kernel 2.6.25.<br />
For Windows, a paravirtualized network driver can be obtained here: [http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers].<br />
FreeBSD has the ability to use virtio drivers since 10.0 (unreleased). A backport of the drivers are available in the port {{ic|emulators/virtio-kmod}} for FreeBSD 8.3 and 9.0.<br />
<br />
A virtio block device requires the option {{Ic|-drive}} instead of the simple {{Ic|-hd*}} plus {{Ic|<nowiki>if=virtio</nowiki>}}:<br />
$ qemu-kvm -boot order=c -drive file=drive.img,if=virtio<br />
(ps: {{Ic|<nowiki>-boot order=c</nowiki>}} is absolutely required when you want to boot from it. There is no auto-detection as with {{Ic|-hd*}} ...)<br />
<br />
Almost the same goes for the network:<br />
$ qemu-kvm -net nic,model=virtio<br />
<br />
=== Preparing an (Arch) Linux guest ===<br />
{{Note|The arch setup scripts for the installer does not handle vd* disk devices correctly and required additional steps as detailed in this post https://bbs.archlinux.org/viewtopic.php?pid&#61;1042283}}<br />
<br />
To use virtio devices after an Arch Linux guest has been installed, the following modules can be loaded in the guest: {{Ic|virtio}}, {{Ic|virtio_pci}}, {{Ic|virtio_blk}}, {{Ic|virtio_net}}, and {{Ic|virtio_ring}} (for 32-bit guests, the specific "virtio" module is not necessary).<br />
<br />
If you want to boot from a virtio disk, the initial ramdisk must be [[mkinitcpio|rebuilt]]. Add the appropriate modules in {{ic|/etc/mkinitcpio.conf}} like this:<br />
MODULES="virtio_blk virtio_pci virtio_net"<br />
and rebuild the initial ramdisk:<br />
# mkinitcpio -p linux<br />
<br />
Virtio disks are recognized with the prefix '''''v''''' (e.g. ''v''da, ''v''db, etc.); therefore, changes must be made in at least {{ic|/etc/fstab}} and {{ic|/boot/grub/menu.lst}} when booting from a virtio disk. When using grub-pc which references disks by [[Persistent_block_device_naming#By-uuid|UUID's]], nothing has to be done.<br />
<br />
Edit or create {{ic|/boot/grub/device.map}}:<br />
(hd0) /dev/vda<br />
<br />
{{Note|The following may be outdated since a new official installation ISO has been released (2011.08.19).}}<br />
To enable virtio at Arch Linux installation time, manual GRUB installation is required (for arch-release-media 2010.05)<br />
Though AIF correctly detects the virtio disks and sets up the right prefixes, the {{ic|/boot/grub/device.map}} file must be created before configuring the bootloader.<br />
<br />
So when installing Arch Linux, you can install GRUB by switching to another virtual terminal ({{Keypress|Ctrl+Alt+F2}}) and running the following commands.<br />
# grub<br />
> device (hd0) /dev/vda<br />
> root (hd0,0)<br />
> setup (hd0)<br />
> quit<br />
<br />
{{Note|(hd0,0) numbering may change depending on your configuration. Reference: http://lists.mandriva.com/bugs/2009-08/msg03424.php}}<br />
<br />
Once you have installed GRUB, switch back to the main terminal with {{Keypress|Ctrl+Alt+F1}}.<br />
<br />
Further information on paravirtualization with KVM can be found here:<br />
[http://www.linux-kvm.org/page/Boot_from_virtio_block_device]<br />
section in the German qemu-book: [http://qemu-buch.de/de/index.php/QEMU-KVM-Buch/_Virtuelle_Hardware/_Paravirtualisierte_Ger%C3%A4tetreiber]<br />
<br />
=== Preparing a Windows guest ===<br />
Preparing a Windows guest for running with a virtio disk driver is a bit tricky.<br />
<br />
In your KVM host (running Arch Linux), download the virtio disk driver from the [http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers Fedora repository].<br />
<br />
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:<br />
qemu-img create -f qcow2 fake.img 1G<br />
Run the original Windows guest (still in the IDE mode). Add the fake disk and a CD-ROM with the driver.<br />
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<br />
<br />
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.<br />
<br />
When the installation is successful, you can turn off the virtual machine and launch it again, now with the {{Ic|virtio}} driver.<br />
<br />
qemu-kvm -drive file=windows.img,if=virtio,boot=on -m 512 -vga std<br />
<br />
{{Note|If you encounter the Blue Screen of Death, make sure you did not forget the {{Ic|-m}} parameter.}}<br />
<br />
{{Warning| resizing an image containing an ntfs boot filesystem, could make the VM installed on it unbootable. One solution (really tricky and for expert users only), is shown here along with a deep explanation of the problem. http://tjworld.net/wiki/Howto/ResizeQemuDiskImages}}<br />
<br />
=== Preparing a FreeBSD guest ===<br />
Install the {{ic|emulators/virtio-kmod}} port if you are using FreeBSD 8.3 or later up until 10.0-CURRENT where they are included into the kernel. After installation, add the following to your {{ic|/boot/loader.conf}} file:<br />
<br />
{{bc|<nowiki><br />
virtio_loader="YES"<br />
virtio_pci_load="YES"<br />
virtio_blk_load="YES"<br />
if_vtnet_load="YES"<br />
virtio_balloon_load="YES"<br />
</nowiki>}}<br />
<br />
Then modify your /etc/fstab by doing the following:<br />
<br />
{{bc|<nowiki><br />
sed -i/etc/fstab.bak "s/ad/vtbd/g" /etc/fstab<br />
</nowiki>}}<br />
<br />
And verify that /etc/fstab is kosher. If anything goes wrong, just boot into a rescue cd and copy /etc/fstab.bak back to /etc.fstab.<br />
<br />
=== Up-to-date way ===<br />
Since version 0.13.0 of {{pkg|qemu}}, a new option has been added to {{ic|qemu-img}} executable, the {{ic|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 <br />
{{bc|qemu-img resize my_image.qcow2 +10G}}<br />
<br />
=== Old way ===<br />
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 {{Ic|fsck}} and resize the filesystem.<br />
<br />
{{bc|<nowiki>$ qemu-img convert -O raw image.qcow2 image.img<br />
$ dd if=/dev/zero of=image.img bs=1G count=0 seek=[NUMBER_OF_GB]<br />
$ qemu-img convert -O qcow2 -o cluster_size=64K image.img imageplus.qcow2<br />
$ qemu-kvm -hda imageplus.qcow2 -m 512 -cdrom </Path/to/the/ISO/Image> -boot d -vga std<br />
$ fdisk /dev/sda [delete the partition, create new one occupying whole disk]<br />
$ e2fsck -f /dev/sda1<br />
$ resize2fs /dev/sda1</nowiki><br />
}}<br />
<br />
== Enabling KSM ==<br />
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.<br />
<br />
To enable KSM, first ensure that you have installed {{Pkg|qemu-kvm}} >= 0.12.0.<br />
# pacman -Qi qemu-kvm | grep Version<br />
Version : 0.15.0-2<br />
Also ensure that your kernel is at least version 2.6.32.<br />
# uname -r<br />
3.0-ARCH<br />
If this is the case there should be a {{ic|/sys/kernel/mm/ksm/}} directory containing several files. You can turn KSM on or off by echoing a 1 or 0 to {{ic|/sys/kernel/mm/ksm/run}}.<br />
# echo 1 > /sys/kernel/mm/ksm/run<br />
If KSM is running, and there are pages to be merged (i.e. more than one similar VM is running), then {{ic|/sys/kernel/mm/ksm/pages_shared}} should be non-zero. From the kernel documentation in {{ic|Documentation/vm/ksm.txt}}:<br />
The effectiveness of KSM and MADV_MERGEABLE is shown in /sys/kernel/mm/ksm/:<br />
<br />
pages_shared - how many shared unswappable kernel pages KSM is using<br />
pages_sharing - how many more sites are sharing them i.e. how much saved<br />
pages_unshared - how many pages unique but repeatedly checked for merging<br />
pages_volatile - how many pages changing too fast to be placed in a tree<br />
full_scans - how many times all mergeable areas have been scanned<br />
<br />
A high ratio of pages_sharing to pages_shared indicates good sharing, but<br />
a high ratio of pages_unshared to pages_sharing indicates wasted effort.<br />
pages_volatile embraces several different kinds of activity, but a high<br />
proportion there would also indicate poor use of madvise MADV_MERGEABLE.<br />
<br />
An easy way to see how well KSM is performing is to simply print the contents of all the files in that directory.<br />
<br />
# for ii in /sys/kernel/mm/ksm/* ; do echo -n "$ii: " ; cat $ii ; done<br />
/sys/kernel/mm/ksm/full_scans: 151<br />
/sys/kernel/mm/ksm/max_kernel_pages: 246793<br />
/sys/kernel/mm/ksm/pages_shared: 92112<br />
/sys/kernel/mm/ksm/pages_sharing: 131355<br />
/sys/kernel/mm/ksm/pages_to_scan: 100<br />
/sys/kernel/mm/ksm/pages_unshared: 123942<br />
/sys/kernel/mm/ksm/pages_volatile: 1182<br />
/sys/kernel/mm/ksm/run: 1<br />
/sys/kernel/mm/ksm/sleep_millisecs: 20<br />
<br />
== Easy to Use for New User ==<br />
If the {{Pkg|qemu}} package has been installed, you can use a GUI tool, such as {{Pkg|qtemu}} for simple use or {{Pkg|qemu-launcher}} for particle control, to manage your virtual machine.<br />
<br />
You need to change {{Ic|qemu}} in the configure item "QEMU start command" to {{Ic|qemu-kvm}} or leave the "QEMU start command" as {{Ic|qemu}} and append {{Ic|-enable-kvm}} to the additional start options. With newer versions of {{Pkg|qemu}}, it might not be necessary to append {{Ic|-enable-kvm}} as the {{Ic|qemu}} executable will detect that KVM is running and start in the correct mode.<br />
<br />
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.<br />
<br />
== Bridged Networking ==<br />
=== Using Netcfg ===<br />
<br />
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 the {{Pkg|netcfg}} package. You will also need to install {{Pkg|bridge-utils}}.<br />
<br />
[[Netcfg#Configuring_a_bridge_for_use_with_virtual_machines_.28VMs.29]]<br />
<br />
=== Additional notes ===<br />
<br />
Other information can be found here: [[QEMU#Tap_Networking_with_QEMU]] and [[QEMU#Networking_with_VDE2]]<br />
<br />
If you are using {{Pkg|iptables}}, it is recommended for performance and security reasons to disable the firewall on the bridge:<br />
# cat >> /etc/sysctl.conf <<EOF<br />
net.bridge.bridge-nf-call-ip6tables = 0<br />
net.bridge.bridge-nf-call-iptables = 0<br />
net.bridge.bridge-nf-call-arptables = 0<br />
EOF<br />
# sysctl -p /etc/sysctl.conf<br />
<br />
See the [http://wiki.libvirt.org/page/Networking#Creating_network_initscripts libvirt wiki] and [https://bugzilla.redhat.com/show_bug.cgi?id=512206 Fedora bug 512206]<br />
<br />
Alternatively, you can configure {{Pkg|iptables}} to allow all traffic to be forwarded across the bridge by adding a rule like this:<br />
-I FORWARD -m physdev --physdev-is-bridged -j ACCEPT<br />
<br />
== Mouse integration ==<br />
To prevent the mouse from being grabbed when clicking on the guest operating system's windows, add the option {{Ic|-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.<br />
$ qemu-kvm -hda <Image_Name> -m 512 -vga std -usbdevice tablet<br />
<br />
== Mounting the QEMU image ==<br />
<br />
modprobe nbd max_part=63<br />
qemu-nbd -c /dev/nbd0 [image.img]<br />
mount /dev/nbd0p1 [/mnt/qemu]<br />
<br />
== Starting KVM virtual machines on boot up==<br />
<br />
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:<br />
<br />
virsh autostart <domain><br />
<br />
To disable autostarting:<br />
<br />
virsh autostart --disable <domain><br />
<br />
Virt-manager is equally easy having an autostart check box in the boot options of the VM.<br />
<br />
Note VMs started by QEMU or KVM from the command line are not then manageable by virt-manager. <br />
<br />
For an alternative check here: [[QEMU#Starting_QEMU_virtual_machines_on_boot]]<br />
<br />
== Tips and tricks ==<br />
=== Poor Man's Networking ===<br />
<br />
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.<br />
<br />
The basic steps are as follows:<br />
* Setup an SSH server in the host OS<br />
* (optional) Create a designated user used for the tunneling (e.g. tunneluser)<br />
* Install SSH in the VM<br />
* Setup authentication<br />
<br />
See: [[SSH]] for the setup of SSH, especially [[SSH#Forwarding_Other_Ports]]<br />
<br />
When using the default user network stack, the host is reachable at address 10.0.2.2.<br />
<br />
If everything works and you can SSH into the host, simply add something like the following to your /etc/rc.local<br />
# Local SSH Server<br />
echo "Starting SSH tunnel"<br />
sudo -u vmuser ssh tunneluser@10.0.2.2 -N -R 2213:127.0.0.1:22 -f<br />
# Random remote port (e.g. from another VM)<br />
echo "Starting random tunnel"<br />
sudo -u vmuser ssh tunneluser@10.0.2.2 -N -L 2345:127.0.0.1:2345 -f<br />
<br />
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.<br />
<br />
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.</div>Elizacathttps://wiki.archlinux.org/index.php?title=Android_tethering&diff=153409Android tethering2011-08-26T12:33:35Z<p>Elizacat: Clean up some english</p>
<hr />
<div>[[fr:Modem attache Android]]<br />
[[Category:Networking (English)]]<br />
==What is Tethering==<br />
<br />
Tethering is a way to have Internet access on your PC through your smartphone using it's network connection.<br />
Usb and wifi access point tethering is natively supported from Android Froyo ( 2.2 ). Older versions of the Android OS, mostly unofficial roms<br />
have this option enabled.<br />
<br />
== Wifi access point ==<br />
Using an android phone as a WiFi access point (using 3G) has been accessible by default since Froyo (Android 2.2) without needing to root the phone. Moreover, this method will not discharge the battery rapidly, unlike USB.<br />
See : '''menu/wireless & networks/Internet tethering/Wifi access point'''<br />
<br />
== USB tethering ==<br />
<br />
===Tools Needed===<br />
* Root access to the phone (for old Android versions, Froyo (Android 2.2) and beyond can do it natively)<br />
* Usb connection cable from your phone to pc<br />
<br />
=== Procedure ===<br />
*Disconnect your pc from for current wifi or ethernet network<br />
*Connect the phone to your pc using the usb cable<br />
*Enable the the tethering option from your phone. This is usually done from Settings --> Wireless & Networks --> Internet tethering<br />
<br />
'''(The following step may not be needed. usbnet module may not be necessary, do it only if you don't see a usb0 interface in the ifconfig step)'''<br />
*Load the usbnet module(if it's not already loaded). You will need root access to do that<br />
<pre><br />
modprobe usbnet<br />
</pre><br />
*Make sure that the usb interface is recognized by the system by using the following command<br />
<pre><br />
ifconfig -a<br />
</pre><br />
you should be able to see a usb0 device listed like this(notice the usb0 device):<br />
<pre><br />
root@arch:~# ifconfig -a<br />
eth0 Link encap:Ethernet HWaddr 00:16:36:FA:3E:31 <br />
UP BROADCAST MULTICAST MTU:1500 Metric:1<br />
RX packets:0 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:1000 <br />
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)<br />
<br />
lo Link encap:Local Loopback <br />
inet addr:127.0.0.1 Mask:255.0.0.0<br />
inet6 addr: ::1/128 Scope:Host<br />
UP LOOPBACK RUNNING MTU:16436 Metric:1<br />
RX packets:316435 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:316435 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:0 <br />
RX bytes:22875193 (21.8 Mb) TX bytes:22875193 (21.8 Mb)<br />
<br />
usb0 Link encap:Ethernet HWaddr C2:5A:11:8D:43:F5 <br />
BROADCAST MULTICAST MTU:1500 Metric:1<br />
RX packets:0 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:1000 <br />
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)<br />
<br />
<br />
</pre><br />
*Configure the new network device via dhcp using the following command<br />
<pre><br />
ifconfig usb0 up && dhcpcd usb0<br />
</pre><br />
To stop the network sharing, issue the command<br />
<pre><br />
dhcpcd -x usb0<br />
</pre><br />
<br />
==USB tethering with openvpn==<br />
This method works for any old Android version and does not requires root access nor modifications in the phone (it is also suitable for Android 2.2 and later, but no longer required).<br />
<br />
It does not requires changes to your browser; in fact transparently handles all network traffic for any PC application (except ICMP pings). It is somewhat CPU intensive in the phone at high usage rates (a 500 kbyte/sec data transfer rate may take more than 50% of phone CPU on a powerful Acer Liquid).<br />
<br />
===Tools Needed===<br />
In Arch you need to install the [https://www.archlinux.org/packages/?q=openvpn openvpn] package. Is is also required the Android SDK installed (which can be obtained [http://developer.android.com/sdk/index.html here]). In the phone, the [http://code.google.com/p/azilink/ azilink] application, a Java-based NAT that will communicate with OpenVPN in your computer.<br />
<br />
====Configuring the phone connection in Arch Linux====<br />
<br />
Once installed the Android SDK, in order to use the provided tools your phone must be properly setup in udev and your linux user need to be granted rights. Otherwise you may need root privileges to use the Android SDK, which is non recommended. To perform this configuration, turn on USB debugging on the phone (usually in Settings -> Applications -> Development -> USB debugging), connect it to the PC by the USB cable and run the '''lsusb''' command. The device should be listed. Example output for the Acer Liquid phone:<br />
<br />
Bus 001 Device 006: ID '''0502''':3202 Acer, Inc. <br />
<br />
Then, create the following file, replacing ''ciri'' by your own Linux user name, and '''0502''' by the vendor ID of your own phone:<br />
<br />
{{File|name=/etc/udev/rules.d/50-android.rules|content=<br />
<nowiki>SUBSYSTEM=="usb", SYSFS(idVendor)=="0502", MODE="0666" OWNER="ciri"</nowiki> <br />
}}<br />
<br />
As root run the '''udevadm control restart''' command (or reboot your computer) to make the change effective.<br />
Now run in your linux PC the '''adb shell''' command from the Android SDK as plain (non root) user: you should get a unix prompt ''in your phone''.<br />
<br />
===Procedure===<br />
Run the AziLink application in the phone and select "About" at the bottom to receive instruccions, which basically are:<br />
<br />
# You'll have to enable USB debugging on the phone if it was not already enabled (usually in Settings -> Applications -> Development -> USB debugging).<br />
# Connect the phone with the USB cable to the PC.<br />
# Run AziLink and make sure that the '''Service active''' option at the top is checked.<br />
# Run the following commands in your linux PC:<br />
##As plain user: '''adb forward tcp:41927 tcp:41927''' (requires Android SDK installed)<br />
##As root: '''openvpn AziLink.ovpn'''<br />
<br />
{{File|name=AziLink.ovpn|content=<br />
<nowiki>dev tun<br />
remote 127.0.0.1 41927 tcp-client<br />
ifconfig 192.168.56.2 192.168.56.1<br />
route 0.0.0.0 128.0.0.0<br />
route 128.0.0.0 128.0.0.0<br />
socket-flags TCP_NODELAY<br />
keepalive 10 30<br />
dhcp-option DNS 192.168.56.1</nowiki> <br />
}}<br />
<br />
==Tethering with proxy==<br />
<br />
With this method tethering is achieved by port forwarding from the phone to the pc. This is suitable<br />
only for browsing. For firefox, you should set '''network.proxy.socks_remote_dns''' to '''true''' in '''about:config''' ( adress bar )<br />
<br />
===Tools Needed===<br />
* Root access to the PC<br />
* Android SDK which can be obtained [http://developer.android.com/sdk/index.html here]<br />
* Usb connection cable from your phone to pc<br />
* Proxoid application(free download from the Android market)<br />
<br />
<br />
===Instructions===<br />
Follow the instructions demonstrated in the following [http://androidcommunity.com/forums/f23/android-usb-tethering-for-linux-using-proxoid-24875/ link]</div>Elizacat