KVM - User contributions [en]

HOWTO

2013-05-09T11:30:35Z

Mjt: add link to gentoo wiki page, probably need to delete local KvmOnGentoo

= Howto's =

== General ==
* [http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/kvminstall/liaaikvminstallstart.htm IBM Linux Blueprint: Quick Start Guide for installing and running KVM]
* [[HOWTO1 | Getting KVM to run on your machine]]
* [[choose the right kvm & kernel version]]
* [[How To Migrate From Vmware To KVM]]
* [http://www.basicsedv.de/bthesis.html Migrating User Mode Linux to Xen and KVM]

== Network related ==

* [[Networking| Setting guest network]]
* [[NetConsole| set up a network console]]

== Hardware related ==

* [[How to assign devices with VT-d in KVM]]
* [[Enable VT-X on Mac Pro (Early 2008)]]

=== USB ===
* [[USB Host Device Assigned to Guest]]
* [[usb related]]

=== Ethernet ===
* [[ethernet_related]]

=== PCI ===
* [[hotadd pci devices]]

=== Sound ===
* Using [[Sound]] in the guest

=== Display ===
* Using qxl and [[SPICE]] in the guest

=== virtio ===

* [[boot from virtio block device]]
* [[Using VirtIO NIC|use virtio_net interface]] in the guest (Debian)

=== vhost ===
* [[UsingVhost|Using vhost]]

=== cdrom ===
* [[Change cdrom| Changing disks in the cdrom drive]]

=== sharing files with the host ===
* Using [[9p virtio]] to share files between host and guest

== Operating System related ==

=== Gentoo ===
* Gentoo has [http://wiki.gentoo.org/wiki/QEMU good page about qemu/kvm in their wiki].
* [[KvmOnGentoo|KVM on Gentoo hosts]]

=== Ubuntu ===
* [http://www.howtoforge.com/using-kvm-on-ubuntu-gutsy-gibbon using-kvm-on-ubuntu-gutsy-gibbon]
* [[AnthonyLiguori/Networking| Setting up NAT with KVM in Ubuntu]]
* [https://help.ubuntu.com/community/KVM Running Guest Systems on Ubuntu 7.04 Feisty Fawn]
* [http://www.howtoforge.com/virtualization-with-kvm-on-ubuntu-9.04 Virtualization With KVM On Ubuntu 9.04 Jaunty]

=== Fedora ===
* [http://fedoraproject.org/wiki/Virtualization_Quick_Start Fedora Virt Quick Start]

=== ArchLinux ===
* [http://wiki.archlinux.org/index.php/Kvm Setting up KVM on ArchLinux]
* [http://wiki.archlinux.org/index.php/Qemu Detailed QEMU Tutorial ]

=== BSD ===
* [http://www.linux-kvm.org/page/BSD KVM on BSD, FreeBSD]

=== Windows ===
* [[WindowsGuestDrivers|Information about guest drivers]]
* [[Windows7Install|Install Windows 7]]
* [http://wp.libpf.com/?p=186 Windows 7 as guest on Debian squeeze] - with libvirt's virt-install recipe and virtio disk driver step-by-step instructions

=== Windows Vista ===
* [[Vista Networking Workaround]]

== Scripting & Software ==
* [[HowToConfigScript|Configuration Script for KVM]] - a complete management utility, configuration file format, and init script.
* [http://www.roessner-net.com/?p=219 Another script for KVM] - Init scripts for kvm, using it with time scheduled start order (German)
* [[simple shell script to manage your virtual machine with bridged networking]]
* [http://www.papercut.com/blog/chris/2008/11/14/using-kvm-to-securely-host-servers-in-a-dmz/ Hosting your VMs in a DMZ] - a management and configuration script to assist with setting up a VM in a semi-secured demilitarized zone.
* [http://pve.proxmox.com/wiki/Bare-metal_ISO_Installer Bare-metal] installer with KVM
* [[kvmtools|Python scripts to manage qemu-kvm guest from cmdline]] - yet another qemu-kvm script

=== libvirt ===

* [[Running libvirt with KVM]]

== Other ==

* [[HOWTO VMGL]] - OpenGL support for Linux guests

Networking

2013-05-08T10:27:17Z

Mjt: Added "Compatibility" part

= Setting guest network =

Guest (VM) networking in kvm is the same as in qemu, so it is possible to refer to other documentations about networking for qemu. This page will try to explain how to configure the most frequent types of network needed.

== User Networking ==

'''Use case:'''
* You want a simple way for your virtual machine to access to the host, to the internet or to resources available on your local network.
* You don't need to access your guest from the network or from another guest.
* You are ready to take a huge performance hit.
* Warning: User networking does not support a number of networking features like ICMP. Certain applications (like ping) may not function properly.

'''Prerequisites:'''
* You need kvm up and running
* If you don't want to run as root, the user you want to use needs to have rw access to /dev/kvm
* If you want to be able to access the internet or a local network, your host system must be able to access the internet or the local network

'''Solution:'''
* simply run your guest without specifying network parameters, which by default will create user-lever (a.k.a slirp) networking:
qemu-system-x86_64 -hda /path/to/hda.img

'''Notes:'''
* The IP address can be automatically assigned to the guest thanks to the DHCP service integrated in QEMU
* If you run multiple guests on the host, you don't need to specify a different MAC address for each guest
* The default is equivalent to this explicit setup:
qemu-system-x86_64 -hda /path/to/hda.img -netdev user,id=user.0 -device e1000,netdev=user.0
* user.0 identifier above is just to connect the two halves into one, you may use any identifier you wish, such as "n" or "net0".
* Use rtl8139 instead of e1000 to get 8139-series NIC.
* You can still access one specific port on the guest using the "hostfwd" option. This means e.g. if you want to transport a file with scp from host to guest, start the guest with "-device e1000,netdev=user.0 -netdev user,id=user.0,hostfwd=tcp::5555-:22". Now you are forwarding the host port 5555 to the guest port 22. After starting up the guest, you can transport a file with e.g. "scp -P 5555 file.txt root@localhost:/tmp" from host to guest. Or you can also use other address of the host to connect to.

== private virtual bridge ==

'''Use case:'''
* You want to set up a private network between 2 or more virtual machines. This network won't be seen from the other virtual machines nor from the real network.

'''Prerequisites:'''
* You need kvm up and running
* If you don't want to run as root, the user you want to use needs to have rw access to /dev/kvm
* You need the following commands installed on your system, and if you don't want to run as root, the user you want to use needs to be able to sudo the following command:
/sbin/ip
/usr/sbin/brctl
/usr/sbin/tunctl

'''Solution:'''

* You need to create a bridge, e-g:
sudo /usr/sbin/brctl addbr br0

* You need a qemu-ifup script containing the following:
#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
/usr/bin/sudo /usr/sbin/tunctl -u `whoami` -t $1
/usr/bin/sudo /sbin/ip link set $1 up
sleep 0.5s
/usr/bin/sudo /usr/sbin/brctl addif $switch $1
exit 0
else
echo "Error: no interface specified"
exit 1
fi

* Generate a MAC address, either manually or using:
#!/bin/bash
# generate a random mac address for the qemu nic
printf 'DE:AD:BE:EF:%02X:%02X\n' $((RANDOM%256)) $((RANDOM%256))

* Run each guest with the following, replacing $macaddress with the value from the previous step
qemu-system-x86_64 -hda /path/to/hda.img -device e1000,netdev=net0,mac=$macaddress -netdev tap,id=net0

'''Notes:'''
* If you don't want to run as root, the qemu-ifup must be executable by the user you want to use
* You can either create a system-wide qemu-ifup in /etc/qemu-ifup or use another one. In the latter case, run
qemu-system-x86_64 -hda /path/to/hda.img -device e1000,netdev=net0,mac=$macaddress -netdev tap,id=net0,script=/path/to/qemu-ifup

* Each guest on the private virtual network must have a different MAC address

== public bridge ==

'''WARNING:''' The here shown method, will not work with most(all?) wireless drivers, as these do not support bridging.

'''Use case:'''

* You want to assign an IP address to your virtual machines and make them accessible from your local network
* You also want performance out of your virtual machine.

'''Prerequisites:'''
* You need kvm up and running
* If you don't want to run as root, the user you want to use needs to have rw access to /dev/kvm
* You need the following commands installed on your system, and if you don't want to run as root, the user you want to use needs to be able to sudo the following command:
/sbin/ip
/usr/sbin/brctl
/usr/sbin/tunctl

* Your host system must be able to access the internet or the local network

'''Solution 1: using distro sysconfig script'''
{|border="1"
!RedHat's way
!Debian's way
!SuSE's way
|-
|
* Edit /etc/sysconfig/network-scripts/ifcfg-eth0
** comment out BOOTPROTO
** Add BRIDGE=br0
* Create /etc/sysconfig/network-scripts/ifcfg-br0
** The content should be:
DEVICE=br0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Bridge
|
/etc/network/interfaces

# Replace old eth0 config with br0
auto <strike>eth0</strike> br0

# Use old eth0 config for br0, plus bridge stuff
iface br0 inet dhcp
bridge_ports eth0
bridge_stp off
bridge_maxwait 0
bridge_fd 0

|
* Start YaST
* Go to Network Configuration
* Add new device -> Bridge
* Tick your existing network device
* done
|}

* /etc/init.d/networking restart
* The bridge br0 should get the ip address (either static/dhcp) while the physical eth0 is left without ip address.

'''VLANs'''

Please note that the rtl8139 virtual network interface driver does not support VLANs. If you want to use VLANs with your virtual machine, you must use another virtual network interface like virtio.

When using VLANs on a setup like this and no traffic is getting through to your guest(s), you might want to do:
# cd /proc/sys/net/bridge
# ls
bridge-nf-call-arptables bridge-nf-call-iptables
bridge-nf-call-ip6tables bridge-nf-filter-vlan-tagged
# for f in bridge-nf-*; do echo 0 > $f; done

'''Solution 2: manual'''

* You need to create a bridge, e-g:
sudo /usr/sbin/brctl addbr br0

* Add one of your physical interface to the bridge, e-g for eth0:
sudo /usr/sbin/brctl addif br0 eth0

* You need a qemu-ifup script containing the following:

#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
/usr/bin/sudo /usr/sbin/tunctl -u `whoami` -t $1
/usr/bin/sudo /sbin/ip link set $1 up
sleep 0.5s
/usr/bin/sudo /usr/sbin/brctl addif $switch $1
exit 0
else
echo "Error: no interface specified"
exit 1
fi

* Generate a MAC address, either manually or using:

#!/bin/sh
# generate a random mac address for the qemu nic
printf 'DE:AD:BE:EF:%02X:%02X\n' $((RANDOM%256)) $((RANDOM%256))

* Run each guest with the following, replacing $macaddress with the value from the previous step
qemu-system-x86_64 -hda /path/to/hda.img -device e1000,netdev=net0,mac=$macaddress -netdev tap,id=net0

'''Notes:'''
* If you don't want to run as root, the qemu-ifup must be executable by the user you want to use
* You can either create a system-wide qemu-ifup in /etc/qemu-ifup or use another one. In the latter case, run
qemu-system-x86_64 -hda /path/to/hda.img -device e1000,netdev=net0,mac=$macaddress -netdev tap,id=net0,script=/path/to/qemu-ifup

* Each guest on the network must have a different MAC address

== iptables/routing ==

you can also connect your guest vm to a tap in your host. then setting iptables rules in your host to become a router + firewall for your vm.

Routing would be done simply by creating the default route on the client to the IP of the host (and allowing IP forwarding) and setting a route to the tap? device of the client on the host.

Test the setup beforehand:

*Hostside: Allow IPv4 forwarding and add route to client (could be put in a script - route has to be added after the client has started):

sysctl -w net.ipv4.ip_forward=1 # allow forwarding of IPv4
route add -host <ip-of-client> dev <tap-device> # add route to the client

*Clientside: Default GW of the client is of course then the host (<ip-of-host> has to be in same subnet as <ip-of-client> ...):

route add default gw <ip-of-host>

*Clientside v2: If you host IP is not on the same subnet as <ip-of-client>, then you must manually add the route to host before you create default route:

route add -host <ip-of-host> dev <network-interface>
route add default gw <ip-of-host>

== vde ==

Another option is using vde (virtual distributed ethernet).

== performance ==

Data on benchmarking results should go in here.
There's now a page dedicated to ideas for improving
[[Networking Performance]].

== Compatibility ==

There's another, old and obsolete syntax of specifying network for virtual machines. Above examples uses -netdev..-device model, old way used -net..-net pairs. For example,

-netdev tap,id=net0 -device e1000,netdev=net0,mac=52:54:00:12:34:56

is about the same as old

-net tap,vlan=0 -net nic,vlan=0,model=e1000,macaddr=52:54:00:12:34:56

(note mac => macaddr parameter change as well; vlan=0 is the default).

Old way used the notion of "VLANs" - these are QEMU VLANS, which has nothing to do with 802.1q VLANs. Qemu VLANs are numbered starting with 0, and it's possible to connect one or more devices (either host side, like -net tap, or guest side, like -net nic) to each VLAN, and, in particular, it's possible to connect more than 2 devices to a VLAN. Each device in a VLAN gets all traffic received by every device in it. This model was very confusing for the user (especially when a guest has more than one NIC).

In new model, each host side correspond to just one guest side, forming a pair of devices based on -netdev id= and -device netdev= parameters. It is less confusing, it is faster (because it's always 1:1 pair), and it supports more parameters than old -net..-net way.

However, -net..-net is still supported, used widely, and mentioned in lots of various HOWTOs and guides around the world. It is also a bit shorter and so faster to type.

Networking

2013-05-08T10:17:10Z

Mjt: another place with -net..-net converted to -netdev..-device

Networking

2013-05-08T10:14:44Z

Mjt: rearranged a bit

= Setting guest network =

Guest (VM) networking in kvm is the same as in qemu, so it is possible to refer to other documentations about networking for qemu. This page will try to explain how to configure the most frequent types of network needed.

== User Networking ==

'''Use case:'''
* You want a simple way for your virtual machine to access to the host, to the internet or to resources available on your local network.
* You don't need to access your guest from the network or from another guest.
* You are ready to take a huge performance hit.
* Warning: User networking does not support a number of networking features like ICMP. Certain applications (like ping) may not function properly.

'''Prerequisites:'''
* You need kvm up and running
* If you don't want to run as root, the user you want to use needs to have rw access to /dev/kvm
* If you want to be able to access the internet or a local network, your host system must be able to access the internet or the local network

'''Solution:'''
* simply run your guest without specifying network parameters, which by default will create user-lever (a.k.a slirp) networking:
qemu-system-x86_64 -hda /path/to/hda.img

'''Notes:'''
* The IP address can be automatically assigned to the guest thanks to the DHCP service integrated in QEMU
* If you run multiple guests on the host, you don't need to specify a different MAC address for each guest
* The default is equivalent to this explicit setup:
qemu-system-x86_64 -hda /path/to/hda.img -netdev user,id=user.0 -device e1000,netdev=user.0
* user.0 identifier above is just to connect the two halves into one, you may use any identifier you wish, such as "n" or "net0".
* Use rtl8139 instead of e1000 to get 8139-series NIC.
* You can still access one specific port on the guest using the "hostfwd" option. This means e.g. if you want to transport a file with scp from host to guest, start the guest with "-device e1000,netdev=user.0 -netdev user,id=user.0,hostfwd=tcp::5555-:22". Now you are forwarding the host port 5555 to the guest port 22. After starting up the guest, you can transport a file with e.g. "scp -P 5555 file.txt root@localhost:/tmp" from host to guest. Or you can also use other address of the host to connect to.

== private virtual bridge ==

'''Use case:'''
* You want to set up a private network between 2 or more virtual machines. This network won't be seen from the other virtual machines nor from the real network.

'''Prerequisites:'''
* You need kvm up and running
* If you don't want to run as root, the user you want to use needs to have rw access to /dev/kvm
* You need the following commands installed on your system, and if you don't want to run as root, the user you want to use needs to be able to sudo the following command:
/sbin/ip
/usr/sbin/brctl
/usr/sbin/tunctl

'''Solution:'''

* You need to create a bridge, e-g:
sudo /usr/sbin/brctl addbr br0

* You need a qemu-ifup script containing the following:
#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
/usr/bin/sudo /usr/sbin/tunctl -u `whoami` -t $1
/usr/bin/sudo /sbin/ip link set $1 up
sleep 0.5s
/usr/bin/sudo /usr/sbin/brctl addif $switch $1
exit 0
else
echo "Error: no interface specified"
exit 1
fi

* Generate a MAC address, either manually or using:
#!/bin/bash
# generate a random mac address for the qemu nic
printf 'DE:AD:BE:EF:%02X:%02X\n' $((RANDOM%256)) $((RANDOM%256))

* Run each guest with the following, replacing $macaddress with the value from the previous step
qemu-system-x86_64 -hda /path/to/hda.img -device e1000,netdev=net0,mac=$macaddress -netdev tap,id=net0

'''Notes:'''
* If you don't want to run as root, the qemu-ifup must be executable by the user you want to use
* You can either create a system-wide qemu-ifup in /etc/qemu-ifup or use another one. In the latter case, run
qemu-system-x86_64 -hda /path/to/hda.img -device e1000,netdev=net0,mac=$macaddress -netdev tap,id=net0,script=/path/to/qemu-ifup

* Each guest on the private virtual network must have a different MAC address

== public bridge ==

'''WARNING:''' The here shown method, will not work with most(all?) wireless drivers, as these do not support bridging.

'''Use case:'''

* You want to assign an IP address to your virtual machines and make them accessible from your local network
* You also want performance out of your virtual machine.

'''Prerequisites:'''
* You need kvm up and running
* If you don't want to run as root, the user you want to use needs to have rw access to /dev/kvm
* You need the following commands installed on your system, and if you don't want to run as root, the user you want to use needs to be able to sudo the following command:
/sbin/ip
/usr/sbin/brctl
/usr/sbin/tunctl

* Your host system must be able to access the internet or the local network

'''Solution 1: using distro sysconfig script'''
{|border="1"
!RedHat's way
!Debian's way
!SuSE's way
|-
|
* Edit /etc/sysconfig/network-scripts/ifcfg-eth0
** comment out BOOTPROTO
** Add BRIDGE=br0
* Create /etc/sysconfig/network-scripts/ifcfg-br0
** The content should be:
DEVICE=br0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Bridge
|
/etc/network/interfaces

# Replace old eth0 config with br0
auto <strike>eth0</strike> br0

# Use old eth0 config for br0, plus bridge stuff
iface br0 inet dhcp
bridge_ports eth0
bridge_stp off
bridge_maxwait 0
bridge_fd 0

|
* Start YaST
* Go to Network Configuration
* Add new device -> Bridge
* Tick your existing network device
* done
|}

* /etc/init.d/networking restart
* The bridge br0 should get the ip address (either static/dhcp) while the physical eth0 is left without ip address.

'''VLANs'''

Please note that the rtl8139 virtual network interface driver does not support VLANs. If you want to use VLANs with your virtual machine, you must use another virtual network interface like virtio.

When using VLANs on a setup like this and no traffic is getting through to your guest(s), you might want to do:
# cd /proc/sys/net/bridge
# ls
bridge-nf-call-arptables bridge-nf-call-iptables
bridge-nf-call-ip6tables bridge-nf-filter-vlan-tagged
# for f in bridge-nf-*; do echo 0 > $f; done

'''Solution 2: manual'''

* You need to create a bridge, e-g:
sudo /usr/sbin/brctl addbr br0

* Add one of your physical interface to the bridge, e-g for eth0:
sudo /usr/sbin/brctl addif br0 eth0

* You need a qemu-ifup script containing the following:

#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
/usr/bin/sudo /usr/sbin/tunctl -u `whoami` -t $1
/usr/bin/sudo /sbin/ip link set $1 up
sleep 0.5s
/usr/bin/sudo /usr/sbin/brctl addif $switch $1
exit 0
else
echo "Error: no interface specified"
exit 1
fi

* Generate a MAC address, either manually or using:

#!/bin/sh
# generate a random mac address for the qemu nic
printf 'DE:AD:BE:EF:%02X:%02X\n' $((RANDOM%256)) $((RANDOM%256))

* Run each guest with the following, replacing $macaddress with the value from the previous step
qemu-system-x86_64 -hda /path/to/hda.img -net nic,macaddr=$macaddress -net tap

'''Notes:'''
* If you don't want to run as root, the qemu-ifup must be executable by the user you want to use
* You can either create a system-wide qemu-ifup in /etc/qemu-ifup or use another one. In the latter case, run
qemu-system-x86_64 -hda /path/to/hda.img -net nic,macaddr=$macaddress -net tap,script=/path/to/qemu-ifup

* Each guest on the network must have a different MAC address

== iptables/routing ==

you can also connect your guest vm to a tap in your host. then setting iptables rules in your host to become a router + firewall for your vm.

Routing would be done simply by creating the default route on the client to the IP of the host (and allowing IP forwarding) and setting a route to the tap? device of the client on the host.

Test the setup beforehand:

*Hostside: Allow IPv4 forwarding and add route to client (could be put in a script - route has to be added after the client has started):

sysctl -w net.ipv4.ip_forward=1 # allow forwarding of IPv4
route add -host <ip-of-client> dev <tap-device> # add route to the client

*Clientside: Default GW of the client is of course then the host (<ip-of-host> has to be in same subnet as <ip-of-client> ...):

route add default gw <ip-of-host>

*Clientside v2: If you host IP is not on the same subnet as <ip-of-client>, then you must manually add the route to host before you create default route:

route add -host <ip-of-host> dev <network-interface>
route add default gw <ip-of-host>

== vde ==

Another option is using vde (virtual distributed ethernet).

== performance ==

Data on benchmarking results should go in here.
There's now a page dedicated to ideas for improving
[[Networking Performance]].

Networking

2013-05-08T10:12:10Z

Mjt: net => netdev in bridge

= Setting guest network =

Guest (VM) networking in kvm is the same as in qemu, so it is possible to refer to other documentations about networking for qemu. This page will try to explain how to configure the most frequent types of network needed.

== User Networking ==

'''Use case:'''
* You want a simple way for your virtual machine to access to the host, to the internet or to resources available on your local network.
* You don't need to access your guest from the network or from another guest.
* You are ready to take a huge performance hit.
* Warning: User networking does not support a number of networking features like ICMP. Certain applications (like ping) may not function properly.

'''Prerequisites:'''
* You need kvm up and running
* If you don't want to run as root, the user you want to use needs to have rw access to /dev/kvm
* If you want to be able to access the internet or a local network, your host system must be able to access the internet or the local network

'''Solution:'''
* simply run your guest without specifying network parameters, which by default will create user-lever (a.k.a slirp) networking:
qemu-system-x86_64 -hda /path/to/hda.img

This is equivalent of this explicit setup:
qemu-system-x86_64 -hda /path/to/hda.img -netdev user,id=user.0 -device e1000,netdev=user.0

(user.0 identifier is just to connect the two halves into one; specify rtl8139 instead of e1000 to get 8139-series NIC)

'''Notes:'''
* The IP address can be automatically assigned to the guest thanks to the DHCP service integrated in QEMU
* If you run multiple guests on the host, you don't need to specify a different MAC address for each guest
* You can still access one specific port on the guest using the "hostfwd" option. This means e.g. if you want to transport a file with scp from host to guest, start the guest with "-device e1000,netdev=user.0 -netdev user,id=user.0,hostfwd=tcp::5555-:22". Now you are forwarding the host port 5555 to the guest port 22. After starting up the guest, you can transport a file with e.g. "scp -P 5555 file.txt root@localhost:/tmp" from host to guest. Or you can also use other address of the host to connect to.

== private virtual bridge ==

'''Use case:'''
* You want to set up a private network between 2 or more virtual machines. This network won't be seen from the other virtual machines nor from the real network.

'''Prerequisites:'''
* You need kvm up and running
* If you don't want to run as root, the user you want to use needs to have rw access to /dev/kvm
* You need the following commands installed on your system, and if you don't want to run as root, the user you want to use needs to be able to sudo the following command:
/sbin/ip
/usr/sbin/brctl
/usr/sbin/tunctl

'''Solution:'''

* You need to create a bridge, e-g:
sudo /usr/sbin/brctl addbr br0

* You need a qemu-ifup script containing the following:
#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
/usr/bin/sudo /usr/sbin/tunctl -u `whoami` -t $1
/usr/bin/sudo /sbin/ip link set $1 up
sleep 0.5s
/usr/bin/sudo /usr/sbin/brctl addif $switch $1
exit 0
else
echo "Error: no interface specified"
exit 1
fi

* Generate a MAC address, either manually or using:
#!/bin/bash
# generate a random mac address for the qemu nic
printf 'DE:AD:BE:EF:%02X:%02X\n' $((RANDOM%256)) $((RANDOM%256))

* Run each guest with the following, replacing $macaddress with the value from the previous step
qemu-system-x86_64 -hda /path/to/hda.img -device e1000,netdev=net0,mac=$macaddress -netdev tap,id=net0

'''Notes:'''
* If you don't want to run as root, the qemu-ifup must be executable by the user you want to use
* You can either create a system-wide qemu-ifup in /etc/qemu-ifup or use another one. In the latter case, run
qemu-system-x86_64 -hda /path/to/hda.img -device e1000,netdev=net0,mac=$macaddress -netdev tap,id=net0,script=/path/to/qemu-ifup

* Each guest on the private virtual network must have a different MAC address

== public bridge ==

'''WARNING:''' The here shown method, will not work with most(all?) wireless drivers, as these do not support bridging.

'''Use case:'''

* You want to assign an IP address to your virtual machines and make them accessible from your local network
* You also want performance out of your virtual machine.

'''Prerequisites:'''
* You need kvm up and running
* If you don't want to run as root, the user you want to use needs to have rw access to /dev/kvm
* You need the following commands installed on your system, and if you don't want to run as root, the user you want to use needs to be able to sudo the following command:
/sbin/ip
/usr/sbin/brctl
/usr/sbin/tunctl

* Your host system must be able to access the internet or the local network

'''Solution 1: using distro sysconfig script'''
{|border="1"
!RedHat's way
!Debian's way
!SuSE's way
|-
|
* Edit /etc/sysconfig/network-scripts/ifcfg-eth0
** comment out BOOTPROTO
** Add BRIDGE=br0
* Create /etc/sysconfig/network-scripts/ifcfg-br0
** The content should be:
DEVICE=br0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Bridge
|
/etc/network/interfaces

# Replace old eth0 config with br0
auto <strike>eth0</strike> br0

# Use old eth0 config for br0, plus bridge stuff
iface br0 inet dhcp
bridge_ports eth0
bridge_stp off
bridge_maxwait 0
bridge_fd 0

|
* Start YaST
* Go to Network Configuration
* Add new device -> Bridge
* Tick your existing network device
* done
|}

* /etc/init.d/networking restart
* The bridge br0 should get the ip address (either static/dhcp) while the physical eth0 is left without ip address.

'''VLANs'''

Please note that the rtl8139 virtual network interface driver does not support VLANs. If you want to use VLANs with your virtual machine, you must use another virtual network interface like virtio.

When using VLANs on a setup like this and no traffic is getting through to your guest(s), you might want to do:
# cd /proc/sys/net/bridge
# ls
bridge-nf-call-arptables bridge-nf-call-iptables
bridge-nf-call-ip6tables bridge-nf-filter-vlan-tagged
# for f in bridge-nf-*; do echo 0 > $f; done

'''Solution 2: manual'''

* You need to create a bridge, e-g:
sudo /usr/sbin/brctl addbr br0

* Add one of your physical interface to the bridge, e-g for eth0:
sudo /usr/sbin/brctl addif br0 eth0

* You need a qemu-ifup script containing the following:

#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
/usr/bin/sudo /usr/sbin/tunctl -u `whoami` -t $1
/usr/bin/sudo /sbin/ip link set $1 up
sleep 0.5s
/usr/bin/sudo /usr/sbin/brctl addif $switch $1
exit 0
else
echo "Error: no interface specified"
exit 1
fi

* Generate a MAC address, either manually or using:

#!/bin/sh
# generate a random mac address for the qemu nic
printf 'DE:AD:BE:EF:%02X:%02X\n' $((RANDOM%256)) $((RANDOM%256))

* Run each guest with the following, replacing $macaddress with the value from the previous step
qemu-system-x86_64 -hda /path/to/hda.img -net nic,macaddr=$macaddress -net tap

'''Notes:'''
* If you don't want to run as root, the qemu-ifup must be executable by the user you want to use
* You can either create a system-wide qemu-ifup in /etc/qemu-ifup or use another one. In the latter case, run
qemu-system-x86_64 -hda /path/to/hda.img -net nic,macaddr=$macaddress -net tap,script=/path/to/qemu-ifup

* Each guest on the network must have a different MAC address

== iptables/routing ==

you can also connect your guest vm to a tap in your host. then setting iptables rules in your host to become a router + firewall for your vm.

Routing would be done simply by creating the default route on the client to the IP of the host (and allowing IP forwarding) and setting a route to the tap? device of the client on the host.

Test the setup beforehand:

*Hostside: Allow IPv4 forwarding and add route to client (could be put in a script - route has to be added after the client has started):

sysctl -w net.ipv4.ip_forward=1 # allow forwarding of IPv4
route add -host <ip-of-client> dev <tap-device> # add route to the client

*Clientside: Default GW of the client is of course then the host (<ip-of-host> has to be in same subnet as <ip-of-client> ...):

route add default gw <ip-of-host>

*Clientside v2: If you host IP is not on the same subnet as <ip-of-client>, then you must manually add the route to host before you create default route:

route add -host <ip-of-host> dev <network-interface>
route add default gw <ip-of-host>

== vde ==

Another option is using vde (virtual distributed ethernet).

== performance ==

Data on benchmarking results should go in here.
There's now a page dedicated to ideas for improving
[[Networking Performance]].

Networking

2013-05-08T10:10:12Z

Mjt: more -net => -netdev for slirp

= Setting guest network =

Guest (VM) networking in kvm is the same as in qemu, so it is possible to refer to other documentations about networking for qemu. This page will try to explain how to configure the most frequent types of network needed.

== User Networking ==

'''Use case:'''
* You want a simple way for your virtual machine to access to the host, to the internet or to resources available on your local network.
* You don't need to access your guest from the network or from another guest.
* You are ready to take a huge performance hit.
* Warning: User networking does not support a number of networking features like ICMP. Certain applications (like ping) may not function properly.

'''Prerequisites:'''
* You need kvm up and running
* If you don't want to run as root, the user you want to use needs to have rw access to /dev/kvm
* If you want to be able to access the internet or a local network, your host system must be able to access the internet or the local network

'''Solution:'''
* simply run your guest without specifying network parameters, which by default will create user-lever (a.k.a slirp) networking:
qemu-system-x86_64 -hda /path/to/hda.img

This is equivalent of this explicit setup:
qemu-system-x86_64 -hda /path/to/hda.img -netdev user,id=user.0 -device e1000,netdev=user.0

(user.0 identifier is just to connect the two halves into one; specify rtl8139 instead of e1000 to get 8139-series NIC)

'''Notes:'''
* The IP address can be automatically assigned to the guest thanks to the DHCP service integrated in QEMU
* If you run multiple guests on the host, you don't need to specify a different MAC address for each guest
* You can still access one specific port on the guest using the "hostfwd" option. This means e.g. if you want to transport a file with scp from host to guest, start the guest with "-device e1000,netdev=user.0 -netdev user,id=user.0,hostfwd=tcp::5555-:22". Now you are forwarding the host port 5555 to the guest port 22. After starting up the guest, you can transport a file with e.g. "scp -P 5555 file.txt root@localhost:/tmp" from host to guest. Or you can also use other address of the host to connect to.

== private virtual bridge ==

'''Use case:'''
* You want to set up a private network between 2 or more virtual machines. This network won't be seen from the other virtual machines nor from the real network.

'''Prerequisites:'''
* You need kvm up and running
* If you don't want to run as root, the user you want to use needs to have rw access to /dev/kvm
* You need the following commands installed on your system, and if you don't want to run as root, the user you want to use needs to be able to sudo the following command:
/sbin/ip
/usr/sbin/brctl
/usr/sbin/tunctl

'''Solution:'''

* You need to create a bridge, e-g:
sudo /usr/sbin/brctl addbr br0

* You need a qemu-ifup script containing the following:
#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
/usr/bin/sudo /usr/sbin/tunctl -u `whoami` -t $1
/usr/bin/sudo /sbin/ip link set $1 up
sleep 0.5s
/usr/bin/sudo /usr/sbin/brctl addif $switch $1
exit 0
else
echo "Error: no interface specified"
exit 1
fi

* Generate a MAC address, either manually or using:
#!/bin/bash
# generate a random mac address for the qemu nic
printf 'DE:AD:BE:EF:%02X:%02X\n' $((RANDOM%256)) $((RANDOM%256))

* Run each guest with the following, replacing $macaddress with the value from the previous step
qemu-system-x86_64 -hda /path/to/hda.img -net nic,macaddr=$macaddress -net tap

'''Notes:'''
* If you don't want to run as root, the qemu-ifup must be executable by the user you want to use
* You can either create a system-wide qemu-ifup in /etc/qemu-ifup or use another one. In the latter case, run
qemu-system-x86_64 -hda /path/to/hda.img -net nic,macaddr=$macaddress -net tap,script=/path/to/qemu-ifup

* Each guest on the private virtual network must have a different MAC address

== public bridge ==

'''WARNING:''' The here shown method, will not work with most(all?) wireless drivers, as these do not support bridging.

'''Use case:'''

* You want to assign an IP address to your virtual machines and make them accessible from your local network
* You also want performance out of your virtual machine.

'''Prerequisites:'''
* You need kvm up and running
* If you don't want to run as root, the user you want to use needs to have rw access to /dev/kvm
* You need the following commands installed on your system, and if you don't want to run as root, the user you want to use needs to be able to sudo the following command:
/sbin/ip
/usr/sbin/brctl
/usr/sbin/tunctl

* Your host system must be able to access the internet or the local network

'''Solution 1: using distro sysconfig script'''
{|border="1"
!RedHat's way
!Debian's way
!SuSE's way
|-
|
* Edit /etc/sysconfig/network-scripts/ifcfg-eth0
** comment out BOOTPROTO
** Add BRIDGE=br0
* Create /etc/sysconfig/network-scripts/ifcfg-br0
** The content should be:
DEVICE=br0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Bridge
|
/etc/network/interfaces

# Replace old eth0 config with br0
auto <strike>eth0</strike> br0

# Use old eth0 config for br0, plus bridge stuff
iface br0 inet dhcp
bridge_ports eth0
bridge_stp off
bridge_maxwait 0
bridge_fd 0

|
* Start YaST
* Go to Network Configuration
* Add new device -> Bridge
* Tick your existing network device
* done
|}

* /etc/init.d/networking restart
* The bridge br0 should get the ip address (either static/dhcp) while the physical eth0 is left without ip address.

'''VLANs'''

Please note that the rtl8139 virtual network interface driver does not support VLANs. If you want to use VLANs with your virtual machine, you must use another virtual network interface like virtio.

When using VLANs on a setup like this and no traffic is getting through to your guest(s), you might want to do:
# cd /proc/sys/net/bridge
# ls
bridge-nf-call-arptables bridge-nf-call-iptables
bridge-nf-call-ip6tables bridge-nf-filter-vlan-tagged
# for f in bridge-nf-*; do echo 0 > $f; done

'''Solution 2: manual'''

* You need to create a bridge, e-g:
sudo /usr/sbin/brctl addbr br0

* Add one of your physical interface to the bridge, e-g for eth0:
sudo /usr/sbin/brctl addif br0 eth0

* You need a qemu-ifup script containing the following:

#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
/usr/bin/sudo /usr/sbin/tunctl -u `whoami` -t $1
/usr/bin/sudo /sbin/ip link set $1 up
sleep 0.5s
/usr/bin/sudo /usr/sbin/brctl addif $switch $1
exit 0
else
echo "Error: no interface specified"
exit 1
fi

* Generate a MAC address, either manually or using:

#!/bin/sh
# generate a random mac address for the qemu nic
printf 'DE:AD:BE:EF:%02X:%02X\n' $((RANDOM%256)) $((RANDOM%256))

* Run each guest with the following, replacing $macaddress with the value from the previous step
qemu-system-x86_64 -hda /path/to/hda.img -net nic,macaddr=$macaddress -net tap

'''Notes:'''
* If you don't want to run as root, the qemu-ifup must be executable by the user you want to use
* You can either create a system-wide qemu-ifup in /etc/qemu-ifup or use another one. In the latter case, run
qemu-system-x86_64 -hda /path/to/hda.img -net nic,macaddr=$macaddress -net tap,script=/path/to/qemu-ifup

* Each guest on the network must have a different MAC address

== iptables/routing ==

you can also connect your guest vm to a tap in your host. then setting iptables rules in your host to become a router + firewall for your vm.

Routing would be done simply by creating the default route on the client to the IP of the host (and allowing IP forwarding) and setting a route to the tap? device of the client on the host.

Test the setup beforehand:

*Hostside: Allow IPv4 forwarding and add route to client (could be put in a script - route has to be added after the client has started):

sysctl -w net.ipv4.ip_forward=1 # allow forwarding of IPv4
route add -host <ip-of-client> dev <tap-device> # add route to the client

*Clientside: Default GW of the client is of course then the host (<ip-of-host> has to be in same subnet as <ip-of-client> ...):

route add default gw <ip-of-host>

*Clientside v2: If you host IP is not on the same subnet as <ip-of-client>, then you must manually add the route to host before you create default route:

route add -host <ip-of-host> dev <network-interface>
route add default gw <ip-of-host>

== vde ==

Another option is using vde (virtual distributed ethernet).

== performance ==

Data on benchmarking results should go in here.
There's now a page dedicated to ideas for improving
[[Networking Performance]].

Networking

2013-05-08T10:06:13Z

Mjt: -net user is the default, and use -netdev..device in first -net nic,user

= Setting guest network =

Guest (VM) networking in kvm is the same as in qemu, so it is possible to refer to other documentations about networking for qemu. This page will try to explain how to configure the most frequent types of network needed.

== User Networking ==

'''Use case:'''
* You want a simple way for your virtual machine to access to the host, to the internet or to resources available on your local network.
* You don't need to access your guest from the network or from another guest.
* You are ready to take a huge performance hit.
* Warning: User networking does not support a number of networking features like ICMP. Certain applications (like ping) may not function properly.

'''Prerequisites:'''
* You need kvm up and running
* If you don't want to run as root, the user you want to use needs to have rw access to /dev/kvm
* If you want to be able to access the internet or a local network, your host system must be able to access the internet or the local network

'''Solution:'''
* simply run your guest without specifying network parameters, which by default will create user-lever (a.k.a slirp) networking:
qemu-system-x86_64 -hda /path/to/hda.img

This is equivalent of this explicit setup:
qemu-system-x86_64 -hda /path/to/hda.img -netdev user,id=user.0 -device e1000,netdev=user.0

(user.0 identifier is just to connect the two halves into one)

'''Notes:'''
* The IP address can be automatically assigned to the guest thanks to the DHCP service integrated in QEMU
* If you run multiple guests on the host, you don't need to specify a different MAC address for each guest
* You can still access one specific port on the guest using the "hostfwd" option. This means e.g. if you want to transport a file with scp from host to guest, start the guest with "-net nic -net user,hostfwd=tcp::5555-:22". Now you are forwarding the host port 5555 to the guest port 22. After starting up the guest, you can transport a file with e.g. "scp -P 5555 file.txt root@localhost:/tmp" from host to guest. Or you can also use other address of the host to connect to.

== private virtual bridge ==

'''Use case:'''
* You want to set up a private network between 2 or more virtual machines. This network won't be seen from the other virtual machines nor from the real network.

'''Prerequisites:'''
* You need kvm up and running
* If you don't want to run as root, the user you want to use needs to have rw access to /dev/kvm
* You need the following commands installed on your system, and if you don't want to run as root, the user you want to use needs to be able to sudo the following command:
/sbin/ip
/usr/sbin/brctl
/usr/sbin/tunctl

'''Solution:'''

* You need to create a bridge, e-g:
sudo /usr/sbin/brctl addbr br0

* You need a qemu-ifup script containing the following:
#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
/usr/bin/sudo /usr/sbin/tunctl -u `whoami` -t $1
/usr/bin/sudo /sbin/ip link set $1 up
sleep 0.5s
/usr/bin/sudo /usr/sbin/brctl addif $switch $1
exit 0
else
echo "Error: no interface specified"
exit 1
fi

* Generate a MAC address, either manually or using:
#!/bin/bash
# generate a random mac address for the qemu nic
printf 'DE:AD:BE:EF:%02X:%02X\n' $((RANDOM%256)) $((RANDOM%256))

* Run each guest with the following, replacing $macaddress with the value from the previous step
qemu-system-x86_64 -hda /path/to/hda.img -net nic,macaddr=$macaddress -net tap

'''Notes:'''
* If you don't want to run as root, the qemu-ifup must be executable by the user you want to use
* You can either create a system-wide qemu-ifup in /etc/qemu-ifup or use another one. In the latter case, run
qemu-system-x86_64 -hda /path/to/hda.img -net nic,macaddr=$macaddress -net tap,script=/path/to/qemu-ifup

* Each guest on the private virtual network must have a different MAC address

== public bridge ==

'''WARNING:''' The here shown method, will not work with most(all?) wireless drivers, as these do not support bridging.

'''Use case:'''

* You want to assign an IP address to your virtual machines and make them accessible from your local network
* You also want performance out of your virtual machine.

'''Prerequisites:'''
* You need kvm up and running
* If you don't want to run as root, the user you want to use needs to have rw access to /dev/kvm
* You need the following commands installed on your system, and if you don't want to run as root, the user you want to use needs to be able to sudo the following command:
/sbin/ip
/usr/sbin/brctl
/usr/sbin/tunctl

* Your host system must be able to access the internet or the local network

'''Solution 1: using distro sysconfig script'''
{|border="1"
!RedHat's way
!Debian's way
!SuSE's way
|-
|
* Edit /etc/sysconfig/network-scripts/ifcfg-eth0
** comment out BOOTPROTO
** Add BRIDGE=br0
* Create /etc/sysconfig/network-scripts/ifcfg-br0
** The content should be:
DEVICE=br0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Bridge
|
/etc/network/interfaces

# Replace old eth0 config with br0
auto <strike>eth0</strike> br0

# Use old eth0 config for br0, plus bridge stuff
iface br0 inet dhcp
bridge_ports eth0
bridge_stp off
bridge_maxwait 0
bridge_fd 0

|
* Start YaST
* Go to Network Configuration
* Add new device -> Bridge
* Tick your existing network device
* done
|}

* /etc/init.d/networking restart
* The bridge br0 should get the ip address (either static/dhcp) while the physical eth0 is left without ip address.

'''VLANs'''

Please note that the rtl8139 virtual network interface driver does not support VLANs. If you want to use VLANs with your virtual machine, you must use another virtual network interface like virtio.

When using VLANs on a setup like this and no traffic is getting through to your guest(s), you might want to do:
# cd /proc/sys/net/bridge
# ls
bridge-nf-call-arptables bridge-nf-call-iptables
bridge-nf-call-ip6tables bridge-nf-filter-vlan-tagged
# for f in bridge-nf-*; do echo 0 > $f; done

'''Solution 2: manual'''

* You need to create a bridge, e-g:
sudo /usr/sbin/brctl addbr br0

* Add one of your physical interface to the bridge, e-g for eth0:
sudo /usr/sbin/brctl addif br0 eth0

* You need a qemu-ifup script containing the following:

#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
/usr/bin/sudo /usr/sbin/tunctl -u `whoami` -t $1
/usr/bin/sudo /sbin/ip link set $1 up
sleep 0.5s
/usr/bin/sudo /usr/sbin/brctl addif $switch $1
exit 0
else
echo "Error: no interface specified"
exit 1
fi

* Generate a MAC address, either manually or using:

#!/bin/sh
# generate a random mac address for the qemu nic
printf 'DE:AD:BE:EF:%02X:%02X\n' $((RANDOM%256)) $((RANDOM%256))

* Run each guest with the following, replacing $macaddress with the value from the previous step
qemu-system-x86_64 -hda /path/to/hda.img -net nic,macaddr=$macaddress -net tap

'''Notes:'''
* If you don't want to run as root, the qemu-ifup must be executable by the user you want to use
* You can either create a system-wide qemu-ifup in /etc/qemu-ifup or use another one. In the latter case, run
qemu-system-x86_64 -hda /path/to/hda.img -net nic,macaddr=$macaddress -net tap,script=/path/to/qemu-ifup

* Each guest on the network must have a different MAC address

== iptables/routing ==

you can also connect your guest vm to a tap in your host. then setting iptables rules in your host to become a router + firewall for your vm.

Routing would be done simply by creating the default route on the client to the IP of the host (and allowing IP forwarding) and setting a route to the tap? device of the client on the host.

Test the setup beforehand:

*Hostside: Allow IPv4 forwarding and add route to client (could be put in a script - route has to be added after the client has started):

sysctl -w net.ipv4.ip_forward=1 # allow forwarding of IPv4
route add -host <ip-of-client> dev <tap-device> # add route to the client

*Clientside: Default GW of the client is of course then the host (<ip-of-host> has to be in same subnet as <ip-of-client> ...):

route add default gw <ip-of-host>

*Clientside v2: If you host IP is not on the same subnet as <ip-of-client>, then you must manually add the route to host before you create default route:

route add -host <ip-of-host> dev <network-interface>
route add default gw <ip-of-host>

== vde ==

Another option is using vde (virtual distributed ethernet).

== performance ==

Data on benchmarking results should go in here.
There's now a page dedicated to ideas for improving
[[Networking Performance]].

WindowsGuestDrivers/Download Drivers

2011-11-08T11:50:49Z

Mjt:

= Windows VirtIO Drivers =

The source for the Windows drivers is in a git repository on kernel.org

git://git.kernel.org/pub/scm/virt/kvm/kvm-guest-drivers-windows.git

[http://git.kernel.org/?p=virt/kvm/kvm-guest-drivers-windows.git;a=summary http://git.kernel.org/?p=virt/kvm/kvm-guest-drivers-windows.git;a=summary ]

== Binary Drivers ==

Binary drivers are provided by some Linux distributions including WHQL Certified drivers.

64-bit versions of Windows Vista and newer (this currently includes Windows Server 2008, Windows 7 and Windows Server 2008 R2) require the drivers to be [http://msdn.microsoft.com/en-us/windows/hardware/gg487332 digitally signed] to load.

If your distribution does not provide binary drivers for Windows, you can use the package from the Fedora Project. These drivers are digitally signed, and will work on 64-bit versions of Windows:

[http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/ Latest VirtIO drivers for Windows from Fedora ]

Note: as of this writing (2011-Nov-08), latest drivers are of version "15", dated "15-Jun-2011", with the CD image being virtio-win-0.1-mm34.iso. In that image, WindowsXP drivers does not seem to work, it is impossible to install them using regular winXP driver interface. But the previous drivers, version "14" as found on this [http://alt.fedoraproject.org/pub/alt/virtio-win/ Directory], dated "13-Jan-2011", from CD image named "virtio-win-1.1.16.iso", installs on winXP fine.

= Code signing drivers for the Windows 64bit platforms =
* Drivers should be signed for Windows 64bit platforms.
* Here are some links how to self sign and install self signed drivers:
** [http://msdn.microsoft.com/en-us/library/ff547649.aspx Installing Test-Signed Driver Packages]
** [http://www.microsoft.com/whdc/driver/tips/IFS_Signing.mspx How to Release-Sign File System Drivers]

WindowsGuestDrivers/Download Drivers

2011-11-08T11:50:16Z

Mjt:

= Windows VirtIO Drivers =

The source for the Windows drivers is in a git repository on kernel.org

git://git.kernel.org/pub/scm/virt/kvm/kvm-guest-drivers-windows.git

[http://git.kernel.org/?p=virt/kvm/kvm-guest-drivers-windows.git;a=summary http://git.kernel.org/?p=virt/kvm/kvm-guest-drivers-windows.git;a=summary ]

== Binary Drivers ==

Binary drivers are provided by some Linux distributions including WHQL Certified drivers.

64-bit versions of Windows Vista and newer (this currently includes Windows Server 2008, Windows 7 and Windows Server 2008 R2) require the drivers to be [http://msdn.microsoft.com/en-us/windows/hardware/gg487332 digitally signed] to load.

If your distribution does not provide binary drivers for Windows, you can use the package from the Fedora Project. These drivers are digitally signed, and will work on 64-bit versions of Windows:

[http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/ Latest VirtIO drivers for Windows from Fedora ]

Note: as of this writing (2011-Nov-08), latest drivers are of version "15", dated "15-Jun-2011", with the CD image being virtio-win-0.1-mm34.iso. In that image, WindowsXP drivers does not seem to work, it is impossible to install them using regular winXP driver interface. But the previous drivers, version "14" as found on this [[http://alt.fedoraproject.org/pub/alt/virtio-win/ Directory], dated "13-Jan-2011", from CD image named "virtio-win-1.1.16.iso", installs on winXP fine.

= Code signing drivers for the Windows 64bit platforms =
* Drivers should be signed for Windows 64bit platforms.
* Here are some links how to self sign and install self signed drivers:
** [http://msdn.microsoft.com/en-us/library/ff547649.aspx Installing Test-Signed Driver Packages]
** [http://www.microsoft.com/whdc/driver/tips/IFS_Signing.mspx How to Release-Sign File System Drivers]

WindowsGuestDrivers/Download Drivers

2011-11-08T11:49:56Z

Mjt:

= Windows VirtIO Drivers =

The source for the Windows drivers is in a git repository on kernel.org

git://git.kernel.org/pub/scm/virt/kvm/kvm-guest-drivers-windows.git

[http://git.kernel.org/?p=virt/kvm/kvm-guest-drivers-windows.git;a=summary http://git.kernel.org/?p=virt/kvm/kvm-guest-drivers-windows.git;a=summary ]

== Binary Drivers ==

Binary drivers are provided by some Linux distributions including WHQL Certified drivers.

64-bit versions of Windows Vista and newer (this currently includes Windows Server 2008, Windows 7 and Windows Server 2008 R2) require the drivers to be [http://msdn.microsoft.com/en-us/windows/hardware/gg487332 digitally signed] to load.

If your distribution does not provide binary drivers for Windows, you can use the package from the Fedora Project. These drivers are digitally signed, and will work on 64-bit versions of Windows:

[http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/ Latest VirtIO drivers for Windows from Fedora ]
Note: as of this writing (2011-Nov-08), latest drivers are of version "15", dated "15-Jun-2011", with the CD image being virtio-win-0.1-mm34.iso. In that image, WindowsXP drivers does not seem to work, it is impossible to install them using regular winXP driver interface. But the previous drivers, version "14" as found on this [[http://alt.fedoraproject.org/pub/alt/virtio-win/ Directory], dated "13-Jan-2011", from CD image named "virtio-win-1.1.16.iso", installs on winXP fine.

= Code signing drivers for the Windows 64bit platforms =
* Drivers should be signed for Windows 64bit platforms.
* Here are some links how to self sign and install self signed drivers:
** [http://msdn.microsoft.com/en-us/library/ff547649.aspx Installing Test-Signed Driver Packages]
** [http://www.microsoft.com/whdc/driver/tips/IFS_Signing.mspx How to Release-Sign File System Drivers]

Lists, IRC

2011-11-07T22:15:08Z

Mjt: despam (Enomer)

=Lists, IRC=

== Mailing Lists ==

{|
|-
! list
! topics
! subscribe
! archives
|-
| kvm@vger.kernel.org
| general and x86
| [mailto:majordomo@vger.kernel.org?body=subscribe%20kvm subscribe]
| [http://news.gmane.org/gmane.comp.emulators.kvm.devel Gmane], [http://www.spinics.net/lists/kvm spinics], [http://marc.info/?l=kvm MARC]
|-
| kvm-commits@vger.kernel.org
| kernel commit logs
| [mailto:majordomo@vger.kernel.org?body=subscribe%20kvm-commits subscribe]
| [http://news.gmane.org/gmane.comp.emulators.kvm.scm Gmane]
|-
| kvm-ia64@vger.kernel.org
| ia64
| [mailto:majordomo@vger.kernel.org?body=subscribe%20kvm-ia64 subscribe]
| [http://www.spinics.net/lists/kvm-ia64/ spinics]
|-
| kvm-ppc@vger.kernel.org
| PowerPC
| [mailto:majordomo@vger.kernel.org?body=subscribe%20kvm-ppc subscribe]
| [http://marc.info/?l=kvm-ppc-devel MARC]
|}

While the lists are used mainly for development, user queries are welcome. No need to subscribe for a one-off question, just send an email. You may also want to check the various qemu resources on the web, as kvm shares the qemu user interface and networking.

Please observe the usual mailing list etiquette: don't top-post, and trim excess quotations from the mail you are replying to.

Don't post to individual kvm developers directly.

== IRC ==

Join us on '''#kvm''' at [http://freenode.net Freenode]. Don't report serious bugs on IRC; they're liable to get lost. Use the list or the [[Bugs|bug tracker]].

== Blogs and related sites ==
Haydn Solomon's [http://www.linux-kvm.com linux-kvm] site, featuring forums and a blog

Avi Kivity's [http://avikivity.blogspot.com blog]

Anthony Liguori's [http://blog.codemonkey.ws blog]

[http://virt.kernelnewbies.org/ Linux virtualization] wiki

== Forums ==

[http://forums.meulie.net/viewforum.php?f=43 KVM forum]

Guest Support Status

2011-11-07T22:12:27Z

Mjt: Reverted edits by Enomer (Talk); changed back to last version by Tlambiris

=Guest Support Status=

- This page is obsolete. qemu/kvm have much newer versions and expected to run all production OSs.

== Windows Family ==
{|border=1
| '''Guest'''
| '''Guest bitness'''
| '''Host version'''
| '''Host cpu'''
| '''Host bitness'''
| '''Status'''
| '''Comments'''

|-
| Windows 2008 Essential Business Server
| 64
| qemu-kvm-0.11.0
| AMD
| 64
| Works
| Installed on 800 MB RAM only. Host is: Ubuntu Server 9.10 64-bit, 3 x 2.7 GHz AMD Athlon X3 425, 2 x 1 GB DDR2 667 MHz, single channel, 4 x 250 GB SATA Samsung 7200 drives: approx. 498 GB RAID 10 volume for host OS and machine images, 4 x 1 GB RAID 0 volume for swap due to low host main memory. USB hardware key works (Hasp), Virtio drivers for LAN and HDD still testing. By Tomaszg.
|-

|-
| Windows 2008 Small Business Server
| 64
| qemu-kvm-0.11.0
| AMD
| 64
| Works (reboot from guest doesn't correctly work)
| Installed on 2 GB RAM, 1 CPU core. Host is: Ubuntu Server 9.10 64-bit, 2 x Six-Core AMD Opteron(tm) Processor 2425 HE, 8 x 4 GB DDR2, ISCSI for Guest discspace. Don't use virtio drivers (harddisc/network), use IDE (harddisc) and e1000 (network) emulation instead. By Mark.
|-

|-
| Windows 2008 Standard
| 64
| qemu-kvm-0.11.0
| AMD
| 64
| Works (reboot from guest doesn't correctly work)
| Installed on 2 GB RAM, 1 CPU core. Host is: Ubuntu Server 9.10 64-bit, 2 x Six-Core AMD Opteron(tm) Processor 2425 HE, 8 x 4 GB DDR2, ISCSI for Guest discspace. Don't use virtio drivers (harddisc/network), use IDE (harddisc) and e1000 (network) emulation instead. By Mark.
|-

|-
| Windows 2008 Standard
| 32
| qemu-kvm-0.11.0
| Intel
| 32
| Works
| Installed on 1.5 GB RAM, 2 CPU core. Host is: Fedora 14 32-bit, Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz, 3 x 1 GB DDR2 + 1 x 2 GB DDR2, single SATA for host, separate SATA for guest. Working just fine with virtio or Realtek for network. CPU usage near 100% when viewing with KVM console, 14% when viewing through Remmina RDP.
|-

|-
| Windows 2008 R2 RTM
| 64
| kvm-88
| Intel
| 64
| Works
| Installs and works with 1GB guest RAM. [http://twitpic.com/dxs0z/full screenshot]
|-

|-
| Windows 2008 R2 Standard
| 64
| qemu-kvm-0.12.5
| Intel
| 64
| Works
| Installed on HP Proliant ML330 G6 with Ubuntu 10.04.1 server host (2.6.32-24-server) with kvm-kmod-2.6.32.16 using 2 CPU and 2GB guest RAM with IDE harddisc and e1000 network emulation. Works great. By Krunoslav Husak (h00s)
|-

|-
| Windows 2008 R2 Datacenter
| 64
| qemu-kvm-0.12.5
| Intel
| 64
| Works
| Installed on HP Proliant DL530 G4 with Debian 6.0.2 (2.6.32-5-amd64). Using 4 CPU and 4GB RAM for guest. Run stable. By Alexander Pushkarev. [http://www.easyfoto.ru/20110722070342560.jpg Screenshot]
|-

|-
| Windows 7 Professional (Final)
| 64
| qemu-kvm-0.12.1.2-1 ARCH-2.6.32
| AMD
| 64
| Works
| using 2CPUs and 2GB guest RAM [http://img715.yfrog.com/img715/2143/win7profnl642proc2gb.png Screenshot]
|-

|-
| Windows 7 RTM
| 32, 64
| kvm-88
| Intel
| 64
| Works
| Installs and works with 1GB guest RAM. [http://twitpic.com/d3gqq/full screenshot]
|-

|-
| Windows 7 RC
| 64
| kvm-72+dfsg-5
| Intel
| 64
| Works
| Installs and works without any problem with 1GB guest RAM.
|-

|-
| Windows 7 Beta
| 64
| kvm-84
| AMD
| 64
| Works
| Installs and works without any problem with 512MB guest RAM.
|-

| Windows 7 Beta
| 32
| kvm-83
| Intel
| 32
| Works
| Installed in about 25-30 minutes and worked flawlessly on my ThinkPad T60 (1953-7EU) with 1.5G of RAM
|-

| Windows 7 Beta
| 32
| kvm-62
| AMD
| 64
| Works
| "-m 2048 -vnc :0 -usbdevice tablet -smp 2 -std-vga" on qcow2
|-

| Windows Server 2008 (Datacenter)
| 64
| kvm-72
| Intel, AMD
| 64
| Works
| by Alexey.E.
|-

| Windows Server 2008 (Datacenter)
| 32
| kvm-72
| Intel, AMD
| 64, 32
| Works
| by Alexey.E.
|-

| Windows Vista Ultimate
| 64
| kvm-84
| Intel, AMD
| 64
| Works
| (not Aero Glass capable) by Alexey.E.
|-

| Windows Vista Ultimate
| 32
| kvm-84
| Intel, AMD
| 64, 32
| Works
| (not Aero Glass capable) by Alexey.E.
|-

| Windows Server 2003 R2 (Std)
| 32
| qemu-kvm-0.11.1
| Intel
| 64
| Works
| Well with virtio drivers by Patrick.M.

|-
| Windows Server 2003 R2 (Std)
| 32
| qemu-kvm-0.13
| Intel
| 64
| Works
| Well with virtio drivers (1.1.13) by Alexandre D.
|-

| Windows Server 2003 x64
| 64
| qemu-kvm-0.13
| Intel, AMD
| 64
| Works
| Well with virtio drivers (1.1.13) by Alexandre D.
|-

| Windows Server 2003 x64
| 64
| kvm-72
| Intel, AMD
| 64
| Works
| by Alexey.E. (setup is unstable, rerun several times)
|-

| Windows Server 2003 (Enterprise)
| 32
| kvm-72
| Intel
| 32, 64
| Works
| by Alexey.E.
|-

| Windows Server 2003 (Enterprise)
| 32
| kvm-72
| AMD
| 64
| Works
| by Alexey.E.
|-

| Windows XP Pro x64
| 64
| kvm-72
| Intel, AMD
| 64
| Works
| by Alexey.E. (setup is unstable, rerun several times)
|-

| Windows XP Pro
| 32
| kvm-72
| Intel
| 32, 64
| Works
| by Alexey.E.
|-

| Windows XP Pro
| 32
| qemu-kvm-0.11.0
| AMD
| 64
| Works
| Installed on standard IDE driver. Swapped to Virtio XP drivers both for LAN and HDD after installation from "NetKVM-and-viostor.iso". Works well so far. by Tomaszg.
|-

| Windows XP Pro
| 32
| kvm-72
| AMD
| 64
| Works
| by Alexey.E.
|-

| Windows 2000 Pro (SP4)
| 32
| kvm-64
| Intel, AMD
| 64
| Works
| use Qcow2 format. (setup is unstable, rerun several times) by Alexey.E.
|-

| Windows 2000 Pro (SP4)
| 32
| kvm-64
| Intel
| 32
| Works
| use Qcow2 format. (setup is unstable, rerun several times) by Alexey.E.
|-

| Windows 2000 Advanced Server
| 32
| kvm-44
| Intel
| 64
| Works
| use Qcow2 format.
|-

| Windows 98SE
| 32
| kvm-63
| Intel
| 32
| Fails
| by Alexey.E. (halts when booting HIMEM)
|-

| Windows 98SE
| 32
| kvm-80, 2.6.27.7
| AMD
| 64
| no way
| install crashes
|-

| Windows NT Server 4.0 sp 1
| 32
| kvm-72, 2.6.30
| Intel
| 64
| Works
| for networking use -net nic,model=ne2k_pci and install rtl8029 guest driver (included in guest OS cd)
|-

| Windows NT Workstation 4.0 (no SP)
| 32
| qemu-kvm 0.12.3, 2.6.33
| AMD
| 64
| Works
| without any SP requires -cpu qemu64,level=1, also use -vga std
|-

| Windows 95
| 32
| kvm-44, 2.6.23-rc8
| AMD
| 64, 32
| no way
|
|}

== Linux Family: Fedora/RedHat Derivatives ==
{|border=1
| '''Guest'''
| '''Guest bitness'''
| '''Host version'''
| '''Host cpu'''
| '''Host bitness'''
| '''Status'''
| '''Comments'''
|-

| CentOS 6.0
| 64
| kvm-83
| Intel
| 64
| Works
| by Arno-Can Uestuensoez / [http://www.UnifiedSessionsManager.org UnifiedSessionsManager]
|-

| CentOS 5.6
| 64
| kvm-83
| Intel
| 64
| Works
| by Arno-Can Uestuensoez / [http://www.UnifiedSessionsManager.org UnifiedSessionsManager]
|-

| CentOS 5.5
| 64
| kvm-83-164.el5.x86_64.rpm
| AMD (Sempron 140)
| 64
| Works
| by Arno-Can Uestuensoez / [http://www.UnifiedSessionsManager.org UnifiedSessionsManager]
|-

| Enterprise Linux 5.4 / Unbreakable Linux
| 64
| kvm-83
| Intel
| 64
| Works
| by Arno-Can Uestuensoez / [http://www.UnifiedSessionsManager.org UnifiedSessionsManager]
|-

| Fedora 15
| 64
| kvm-83
| Intel
| 64
| Works
| Requires sufficient memory(e.g. 1.5G), and vga=std - by Arno-Can Uestuensoez / [http://www.UnifiedSessionsManager.org UnifiedSessionsManager]
|-

| Fedora 13
| 64
| kvm-83
| Intel
| 64
| Works
| by Arno-Can Uestuensoez / [http://www.UnifiedSessionsManager.org UnifiedSessionsManager]
|-

| Fedora 11
| 64
| kvm-87
| Intel
| 64
| Fails
| Anaconda freezes
|-

| Fedora 11
| 32
| kvm-87
| Intel
| 64
| Works
|
|-

| Fedora 11 BETA
| 32, 64
| kvm-84
| Intel
| 64
| Fails
| by Alexey.E. Slowness and softlockups.
|-

|-
| Fedora 10
| 32, 64
| kvm-85
| Intel, AMD
| 64
| Works
| by Alexey.E. Updated by Lennert.B.
|-

| Fedora 9
| 32, 64
| kvm-85
| Intel, AMD
| 64
| Works
| by Alexey.E.
|-

| Fedora 8
| 32, 64
| kvm-85
| Intel, AMD
| 64
| Works
| by Alexey.E.
|-

| Fedora 7
| 32, 64
| kvm-75
| Intel, AMD
| 64
| Works
| by Alexey.E.
|-

| Fedora 6
| 32
| kvm-26
| Intel, AMD
| 32, 64
| Works
|
|-

| Fedora 5
| 32, 64
| kvm-12
| Intel, AMD
| 32, 64
| Works
|
|-

| Fedora 4
| 64
|
| AMD
| 64
| Works, slightly high idle cpu
|by MichaelKarliner
|-

| Fedora 3
| 64
| kvm-78
| AMD
| 64
| Works
| by George Y. Requires noacpi in boot options
|-

| Fedora 1
| 32
| qemu-kvm-0.12.3
| Intel
| 64
| Crashes
| by Patrick.M. KVM freeze unable to kill PID.
|-

| Fedora 1
| 32
| qemu-kvm-0.11.1
| Intel
| 64
| Works
| by Patrick.M.
|-

| RHEL6 beta
| 64
| kvm-83
| Intel
| 64
| Works
| by Arno-Can Uestuensoez / [http://www.UnifiedSessionsManager.org UnifiedSessionsManager]
|-

| RHEL5
| 32, 64
| kvm-85
| Intel, AMD
| 64
| Works
| by Alexey.E.
|-

| RHEL4
| 32, 64
| kvm-85
| Intel, AMD
| 64
| Works
| by Frank.Q. updated by Alexey.E.
|-

| RHEL3
| 32, 64
| kvm-85
| Intel, AMD
| 64
| Works
| by Frank.Q. updated by Alexey.E.
|-

| Red Hat Linux 9
| 32
| kvm-51
| Intel
| 64
| Works
| by Alexey.E.
|-

| Red Hat Linux 8
| 32
| kvm-64
| Intel
| 64
| Crashes
| Fails on init. by Frank.Q.
|-

| Red Hat Linux 7.3
| 32
| kvm-78
| AMD
| 64
| Works
| -no-kvm is required for installation
|-

| Red Hat Linux 7
| 32
| kvm-52
| Intel, AMD
| 64
| Crashes
| Fails on init. by Alexey.E.
|-

| Scientific Linux 5.4.1
| 64
| kvm-83
| Intel
| 64
| Works
| by Arno-Can Uestuensoez / [http://www.UnifiedSessionsManager.org UnifiedSessionsManager]
|-

| Trixbox (CentOS)
| 32
| kvm-12
| Intel
| 64
| Works
|
|-

| CentOS 5.4
| 32
| qemu-kvm-0.12.3
| AMD
| 64
| Crashes
| When installing from the netinstall image, hangs during installation of the first packet.
|}

== Linux Family: Ubuntu/Debian Derivatives ==
{|border=1
| '''Guest'''
| '''Guest bitness'''
| '''Host version'''
| '''Host cpu'''
| '''Host bitness'''
| '''Status'''
| '''Comments'''
|-

| Debian GNU/Linux 6.0
| 64
| kvm-83
| Intel
| 64
| Works
| by Arno-Can Uestuensoez / [http://www.UnifiedSessionsManager.org UnifiedSessionsManager]
|-

| Debian GNU/Linux 5.0
| 64
| kvm-88
| Intel, AMD
| 64
| Works
| 2009/10/22 by Christian Berendt / [http://www.b1-systems.de B1 Systems]
|-

| Debian GNU/Linux 5.0
| 64
| kvm-83
| Intel
| 64
| Works
| by Arno-Can Uestuensoez / [http://www.UnifiedSessionsManager.org UnifiedSessionsManager]
|-

| Ubuntu 10.10
| 64
| kvm-83
| Intel
| 64
| Works
| by Arno-Can Uestuensoez / [http://www.UnifiedSessionsManager.org UnifiedSessionsManager]
|-

| Ubuntu 10.04 LTS
| 32, 64
| kvm-84
| Intel, AMD
| 64
| Works
| 2010/05/15 by KeithW
|-

| Ubuntu 9.04
| 64
| kvm-84
| Intel
| 64
| Works
| It's actually Xubuntu but should be the same both block and net virtio devices working too
|-

| Ubuntu 8.10
| 32
| kvm-85
| Intel, AMD
| 32, 64
| Works
| by Peter.v.V.
|-

| Ubuntu 8.04 LTS
| 32, 64
| kvm-64
| Intel, AMD
| 32, 64
| Works
| by Alexey.E. (some issues with virtio)
|-

| Ubuntu 7.10
| 32, 64
| kvm-62
| Intel,AMD
| 32, 64
| Crashes, Workaround exists
| Install using Qemu, remove GFX boot. by Alexey.E.
|-

| Ubuntu 7.10 Server
| 64
| kvm-60
| AMD
| 64
| Works
| No framebuffer (black screen at first). Hit enter to start installer.
|-

| Ubuntu 7.10 Server
| 32
| kvm-60/61
| Intel
| 64
| Doesn't work
| Installer crashes (by Ryota Ozaki)
|-

| Ubuntu 7.04
| 32, 64
| kvm-62
| Intel,AMD
| 32, 64
| Crashes, Workaround exists
| Install using Qemu, remove GFX boot. by Alexey.E.
|-

| Ubuntu 6.06 LTS Server
| 32
| kvm-20
| Intel
| 32
| Works
| use -no-acpi
|-

| Debian Lenny 5.0
| 64
| qemu-kvm-0.12.3
| Intel
| 64
| Works
| by Patrick. M.
|-

| Debian Lenny 5.0
| 64
| qemu-kvm-0.11.1
| Intel
| 64
| Works
| by Patrick. M.
|-

| Debian Lenny 5.0
| 32, 64
| kvm-72/77
| Intel
| 64
| Works
| Buggy virtio implementation (netinst), crc errors / segfaults after instalation.
|-

| Debian Etch 4.0
| 64
| kvm-72
| Intel, AMD
| 64
| Works
| by Alexey.E.
|-

| Debian Etch 4.0
| 32
| kvm-64
| Intel
| 64, 32
| Works
| by Alexey.E.
|-

| Debian Etch 4.0
| 32
| kvm-64
| AMD
| 64
| FAILS, workaround exists
| by Alexey.E. (manually choose i586 kernel, do not use default "k7" kernel)
|-

| Debian Sarge 3.1
| 32
| kvm-12
| Intel
| 32
| Works
|
|-

| Debian Sarge 3.1
| 32
| kvm-12
| Intel
| 64
| Mostly works
| Install hangs, will install via -no-kvm. Runs fine after
|-

| Xandros 3 OCE
| 32
| kvm-29
| Intel
| 64
| Works
| by Alexey.E.
|-

| KNOPPIX 5.1.1
| 32
| kvm-18
| Intel
| 64
| Works
| use nmi_watchdog=0 or nolapic kernel parameter to boot
|-

| Knoppix 5.2
| 32
| kvm-18
| Intel
| 32
| Works
|
|}

== Other Linux Distros ==
{|border=1
| '''Guest'''
| '''Guest bitness'''
| '''Host version'''
| '''Host cpu'''
| '''Host bitness'''
| '''Status'''
| '''Comments'''
|-

| Android 2.2
| 32
| kvm-83
| Intel
| 64
| Works
| deactivate suspend-mode(Screen timeout), by Arno-Can Uestuensoez / [http://www.UnifiedSessionsManager.org UnifiedSessionsManager]
|-

| SUSE Linux Enterprise Server 11
| 32, 64
| kvm-88
| Intel, AMD
| 64
| Works
| 2009/10/22 by Christian Berendt / [http://www.b1-systems.de B1 Systems]
|-

| SUSE Linux Enterprise Server 10
| 32
| kvm-88
| Intel, AMD
| 64
| Works
| 2009/10/22 by Christian Berendt / [http://www.b1-systems.de B1 Systems]
|-

| openSUSE 11.3
| 64
| kvm-83
| Intel
| 64
| Works
| by Arno-Can Uestuensoez / [http://www.UnifiedSessionsManager.org UnifiedSessionsManager]
|-

| openSUSE 11.2
| 64
| kvm-83
| Intel
| 64
| Works
| by Arno-Can Uestuensoez / [http://www.UnifiedSessionsManager.org UnifiedSessionsManager]
|-

| openSUSE 11.1
| 32, 64
| kvm-88
| Intel, AMD
| 64
| Works
| 2009/10/22 by Christian Berendt / [http://www.b1-systems.de B1 Systems]
|-

| openSUSE 11.1
| 32, 64
| kvm-85
| Intel, AMD
| 64
| Works
| by Alexey.E.
|-

| openSUSE 11.0
| 32, 64
| kvm-85
| Intel, AMD
| 64
| Works
| by Alexey.E.
|-

| openSUSE 10.3
| 32
| kvm-57
| AMD
| 64
| Works
| by Alexey.E.
|-

| openSUSE 10.3
| 32/64
| kvm-64
| Intel
| 64, 32
| Crashes, Workaround exists
| Start kvm with -no-kvm for installation. Remove graphical GRUB. by Alexey.E.
|-

| openSUSE 10.2
| 32/64
| kvm-28/kvm-51
| Intel
| 64
| Crashes, Workaround exists
| Start kvm with -no-kvm for installation. Remove graphical GRUB. by Alexey.E.
|-

| SUSE Linux 10.0
| 32
| kvm-64
| Intel
| 64, 32
| Crashes, Workaround exists
| Start kvm with -no-kvm for installation. Remove graphical GRUB. by Alexey.E.
|-

| SUSE Linux 9.1
| 32
| kvm-72
| Intel/AMD
| 64, 32
| Works
| by Alexey.E.
|-

| Slackware 12 .2
| 32
| kvm-36
| Intel
| 32
| Works
|
|-

| Slackware 12
| 32
| kvm-36
| Intel
| 32
| Works
|
|-

| Slackware 11
| 32
| kvm-15
| Intel
| 64
| Works
| using test26.s kernel
|-

| Qemu-Puppy 2.01-3
| 32
| kvm-17/18
| Intel
| 32
| Works
|
|-

| Qemu-Puppy 2.13-1
| 32
| kvm-17/18
| Intel
| 32
| Works
|
|-

| SystemRescueCD 0.3.4
| 32
| kvm-18
| Intel
| 64
| Works
| Works fine, except for initial X-setting "cirrus" - changed to "vesa", then works.
|-

| Gentoo 2006.1
| 32
| kvm-24
| Intel
| 64
| Works
|
|-

| Gentoo 2007.0
| 32
| kvm-24
| Intel
| 64
| Works
|
|-

| Gentoo 20100311
| 64
| qemu-kvm-0.11.1
| Intel
| 64
| Works
| using hardened kernel 2.6.32-r3
|-

| Arch Linux (Duke)
|32
| kvm-17
|AMD
|64
|Works
|Host: 2.6.21-ARCH, guest: 2.6.22-rc5-ARCH says "booting paravirtualized kernel on bare hardware"
|-

| Mandrake Linux 9.2
|32
| kvm-51
|Intel
|64
| Works
| by Alexey.E.
|-

| Mandriva 2009
| 32/64
| kvm-75
| Intel
| 64
| Crashes, Workaround exists
| start kvm with -no-kvm for installation. Remove graphical GRUB. by Alexey.E.
|-

| Mandriva 2008.1
| 32
| kvm-64
| Intel
| 64, 32
| Crashes, Workaround exists
| start kvm with -no-kvm for installation. Remove graphical GRUB. by Alexey.E.
|-

| Mandriva 2008
| 32
| kvm-51
| Intel
| 64
| Crashes, Workaround exists
| start kvm with -no-kvm for installation. Remove graphical GRUB. by Alexey.E.
|-

| Mandriva 2007
| 32
| kvm-51
| Intel
| 64
| Crashes, Workaround exists
| start kvm with -no-kvm for installation. Remove graphical GRUB. by Alexey.E.
|-

| Crux Linux 2.5
| 32
| kvm-82
| Intel
| 32
| Works
| Boots Automatically at 'Guest Install' stage. Installs without issue. by Chris P
|-

| Mikrotik 5.0rc3
| 32
| qemu-kvm-0.13.0
| Intel
| 64
| Works
| using virtio nic + vhost_net, watchdog does not work, does not support virtio block device
|}

== UNIX Family: BSD ==
{|border=1
|'''Guest'''
| '''Guest bitness'''
| '''Host version'''
| '''Host cpu'''
| '''Host bitness'''
| '''Status'''
| '''Comments'''
|-

| OpenBSD 5.0
| 64
| qemu-kvm-0.15.0, Linux 2.6.37.6 (Slackware 13.37)
| Intel Core2Duo E8400
| 64
| Works
| SMP works, no need to disable mpbios anymore. Must use '''if=ide''' as the scsi interface will result in sd0(siop0) errors during install; recommend using the e1000 network driver as well. More information can be found [http://tenforward.libpcap.net:8080/2011/10/OpenBSD-5.0-supports-SMP-under-KVM here].
|-

| OpenBSD 4.9
| 64
| qemu-kvm-0.14, linux 2.6.38.4 (Fedora 15 Beta)
| AMD Phenom(tm) 9650 Quad-Core
| 64
| Works
| Disable mpbios as with 4.5
|-

| OpenBSD 4.8
| 32
| kvm-83, linux 2.6.18 (CentOS 5.5)
| Intel E5700
| 64
| Works
| Disable mpbios as with 4.5
|-

| OpenBSD 4.7
| 64
| qemu-kvm-0.12.5
| Intel
| 64
| Works
| Need e1000 driver. (scsi driver does not work). Ide works out of the box. disabling the mpbios is not needed. Done with Linux 2.6.34.2 host kernel.
|-

| OpenBSD 4.6
| 32, 64
| qemu-kvm-0.11.0-0ubuntu6.3
| Intel
| 64
| Works
| Need e1000 driver and disable mpbios (same as other OpenBSD >= 4.5 entries)
|-

| OpenBSD 4.6
| 32
| kvm-84-7.6
| AMD
| 32
| Works
| Use the e1000 driver [-net nic,model=e1000]. Does not find the network after the installation (during install is fine) but disabling mpbios as suggested in 4.5 workaround fixes it.
|-

| OpenBSD 4.5
| 32
| kvm-85
| Intel
| 32
| Crashes
| Use the e1000 driver [-net nic,model=e1000] to avoid lockups and slow network speeds. Crashes after "setting tty flags" - Jaco van der Schyff
4.0 would hang on me at the same place if i booted /bsd.mp but not if i boot /bsd (uniprocessor kernel) - Buck <br/>
4.5 can be made to boot by disabling mpbios as described [http://scie.nti.st/2009/10/4/running-openbsd-4-5-in-kvm-on-ubuntu-linux-9-04 here]; this is a workaround though, not a fix - Maxim
|-

| OpenBSD 4.5
| 64
| kvm-84
| Intel
| 64
| Works
| Use e1000 drivers. Install from CD works, but then you must do the following at the next boot prompt: "bsd -c", "disable mpbios", then "quit"
Make this permanent by using "config -ef /bsd" as root, once everything has booted. -- Garry Dolley
|-

| OpenBSD 4.4
| 64
| kvm-78
| AMD
| 64
| Works
|
|-

| OpenBSD 4.2
| 32
| kvm-58
| Intel
| 32
| Works
|
|-

| OpenBSD 4.1
| 32
| kvm-72
| Intel, AMD
| 64
| Works
| by Alexey.E.
|-

| OpenBSD 4.0
| 64
| kvm-12
| Intel
| 64
| Works
|
|-

| OpenBSD 4.0
| 32
| kvm-16 + CVS
| Intel
| 64
| Works
|
|-

| FreeBSD 6.1
| 32
| kvm-17/18
| Intel
| 32
| Works
|
|-

| FreeBSD 6.2
| 64
| kvm-12
| AMD
| 64
| Works
|
|-

| FreeBSD 6.2
| 32
| kvm-16 + CVS
| AMD
| 64
| Works
|
|-

| FreeBSD 6.3
| 32
| Fedora 8 - kvm-37-7.fc8
| Intel
| 64
| works
|
|-

|FreeBSD 6.3
|32
|Debian Lenny, kvm-60
|AMD
|64
|Works
|No issues in several weeks of testing. Freddie
|-

|FreeBSD 6.3
|64
|Debian Lenny, kvm-60
|AMD
|64
|Works
|No issues in several weeks of testing. Freddie
|-

|FreeBSD 7.0
|32
|Debian Lenny, kvm-60
|AMD
|64
|Works
|No issues in several weeks of testing. Tested with 1 and 2 virtual CPUs. Freddie
|-

|FreeBSD 7.0
|64
|Debian Lenny, kvm-60
|AMD
|64
|Works
|No issues in several weeks of testing. Tested with 1 and 2 virtual CPUs. Freddie
|-

|FreeBSD 7.0
|32
|OpenSUSE 10.3 kvm-63
|AMD
|64
|works
| disk i/o issues? "ad0: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=XXXXXXX"
|-

|FreeBSD 6.0, FreeBSD 6.2, FreeBSD 7.2
|32, 64
|debian squeeze, kvm-0.12.5, libvirt
|Intel Xeon
|64
|works
|freeze with "ad0: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=XXXXXXX". fix with 'hw.ata.ata_dma=0' in /boot/loader.conf
|-

| FreeBSD 7.0
| 64
| OpenSUSE 10.3 kvm-63
| AMD
| 64
| crashes after boot loader
|-

| FreeBSD 7.1
| 64
| kvm-84
| Intel
| 64
| Works
| sdl graphics mess up if using kvm, setup with -nokvm then use ssh or -nographics and serial console
|-

|FreeBSD 7.2
|64
|kvm-86-3
|Intel
|64
|Works, need to install from the DVD or CD image
|Damon Chesser, Jadase Staff
|-

|FreeBSD 8.0
|32, 64
|qemu-kvm-0.11.0-0ubuntu6.3
|Intel
|64
|Works
|installed from full DVD, used NIC model=ne2k_pci
|-

| GNU/kFreeBSD
| 32
| kvm-84
| Intel
| 32
| Works
| kvm module must be loaded with oos_shadow=0
|-

|GNU/kFreeBSD
| 64
| kvm-15
| AMD
| 64
| Works
|
|-

| GNU/kFreeBSD
| 32
| kvm-16 + CVS
| AMD
| 64
| Works
|
|-

| NetBSD 3.1
| 32
| kvm-17/18
| Intel
| 32
| Works
|
|-

| NetBSD 3.1
| 32
| kvm-21
| AMD
| 64
| Works
|
|-

| NetBSD 4.0
| 32
| kvm-60
| Intel
| 64
| Works
| avoid hangup on boot with --no-acpi and network card timeout by trying out a different card, e.g. -net nic,model=ne2k_pci
|-

| NetBSD 5.0
| 64
| kvm-88
| Intel
| 64
| Crashes/hangs
| Install CD image will crash or hang, depending on if ACPI is enabled or not. NetBSD 4.0 workarounds ineffective.
|-

| NetBSD 5.0.2
| 32
| kvm from 2.6.32-2-amd64 debian kernel on debian sid
| both Intel and Amd
| 64
| Works
| avoid slow down/ hangs with --no-acpi and network timeout by using -net nic,model=ne2k_pci, disable both SMP and ACPI in /boot.cfg inside guest
|-

| MirBSD 2009/10
| 32
| kvm_1:84+dfsg-0ubuntu12.4~hardy1
| Intel
| Works
| Use of nic,model=e1000 is strongly recommended, ne2k variants work too, emulated Realtek are crappier than metal ones and do not work.
|-

| PC-BSD 1.4
| 32
| kvm-56
| Intel
| 64
| Works
| By Alexey.E.
|-

| DragonflyBSD 1.10.1
| 32
| kvm-58
| Intel
| 64
| Works
| avoid kvm-[64-67] which require -no-kvm-pit to work; use -net nic,model=e1000 to avoid network timeouts
|-

| DragonflyBSD 2.2.1
| 32
| kvm-85
| Intel
| 64
| Works
| not tried X
|}

== UNIX Family: Solaris/OpenSolaris ==
{|border=1
| '''Guest'''
| '''Guest bitness'''
| '''Host version'''
| '''Host cpu'''
| '''Host bitness'''
| '''Status'''
| '''Comments'''
|-

| Solaris 10 U1
| 32
| kvm-12
| Intel
| 64
| Works
| later releases will detect the CPU is 64 bit capable and try to default to run a 64 bit kernel and fail, for those you have to override Solaris autodetection by adding "kernel/unix" to the kernel multiboot entry in GRUB
|-

| Solaris 10 U3
| 64
| kvm-58 + patch
| Intel
| 64
| Works
| needs additional patch to kvm for [http://tapir.sajinet.com.pe/gentoo/portage/app-emulation/kvm/files/kvm-57-kernel-longmode.patch kvm kernel longmode]
|-

| Nexenta Core 1.0
| 64
| kvm-61
| Intel
| 64
| Works
| needs additional patch to kvm for [http://tapir.sajinet.com.pe/gentoo/portage/app-emulation/kvm/files/kvm-57-kernel-longmode.patch kvm kernel longmode]. Use -m 512 -net nic,model=e1000
|-

| Nexenta Core 2.0 b104 rc3
| 32 / 64
| qemu-kvm-0.11.0
| Intel
| 64
| Works
| Might need additional patch to kvm for [http://tapir.sajinet.com.pe/gentoo/portage/app-emulation/kvm/files/kvm-57-kernel-longmode.patch kvm kernel longmode]. My qemu-kvm was already patched. Had to switch of 'acpi', 'apic' and 'pae' features in guest configuration. Guest machine-type set to pc-0.10. Use -m 512 -net nic,model=e1000.
|-

| OpenSolaris 2008.05
| 64
| kvm-69
| Intel
| 64
| Works
| Use -m 512 -net nic,model=e1000
|-

| Milax 0.3.2
| 32
| kvm-62
| Intel
| 64
| Works
| Use the kvm option -net nic,model=rtl8139 and add atapi-cd-dma-enabled=0,atapi-other-dma-enabled=0 to the kernel line in the grub menu for older releases of Milax http://www.milax.org/ in version 0.3.2 choose the Qemu grub menu entry ; tested on Ubuntu 8.04.1 by BerndSchemmer
|-

| Belenix 0.7.1
| 64
| kvm-62
| Intel
| 64
| Works
| Note: older releases of Belenix only work in text mode; tested on Ubuntu 8.04.1 by BerndSchemmer
|-

| Solaris 10 U6
| 32 & 64
| kvm-62
| Intel
| 64
| Mostly Works (see note)
| Note: the grub menu entry for Solaris 10 created by the installer is wrong, to make it work add kernel/unix to the line beginning with kernel ; tested on Ubuntu 8.04.1 by BerndSchemmer
|-

| OpenSolaris 2008.11
| 64
| kvm-62
| Intel
| 64
|Works
| tested on Ubuntu 8.04.1 by BerndSchemmer
|-

| OpenSolaris 2009.06
| 32, 64
| qemu-kvm-0.11.0-0ubuntu6.3
| Intel
| 64
|Works
| Used "-vga std" but don't recall why.
|-

| Solaris 11 Express 2010.11
| 32, 64
| qemu-kvm-0.12.1.2-2.113.el6_0.8
| Intel
| 64
|Works but without USB support
| During boot the system prints the following warning: "No SOF interrupts have been received. This USB EHCI controller is unusable." As a result, no keyboard and mouse functionality from the console. Must install with automatic networking enabled, and login via the network to use it. Also warns at boot "rtls0: Failure resetting PHY" but networking seems to still work.
|}

== Other UNIX systems ==
{| border=1
|'''Guest'''
| '''Guest bitness'''
| '''Host version'''
| '''Host cpu'''
| '''Host bitness'''
| '''Status'''
| '''Comments'''
|-

| Darwin 8.0.1
| 32
| kvm-29
| Intel
| 64
| Crashes
| by Alexey.E.
|-

| MINIX 3.1.2a
| 32
| kvm-71
| Intel
| 64
| Works
|
|-

| MINIX 3.1.6
| 32
| qemu-0.12.3
| Intel
| 64
| Crashes
| Only boots without -enable-kvm
|-

| GNU hurd live CD (20051117)
| 32
| kvm-28
| Intel
| 32
| Works
| Seems to have networking problems.
|-

| GNU/Hurd (Debian K14)
| 32
| kvm-33
| Intel
| 32
| Works
| [http://kvm.qumranet.com/kvmwiki/Guest_Support_Status?action=AttachFile&do=get&target=hurd-k14.png screenshot]
|-

| GNU/Hurd (Debian K16)
| 32
| kvm-69
| AMD
| 64
| Works
| avoid kvm-[64-67] which require -no-kvm-pit to work
|-

| QNX 4.25
| 32
| qemu-kvm-0.12.3, kernel 2.6.32-24
| Intel
| 64
| Works
| Use "-net nic,model=ne2k_pci" for network.
|-

| QNX 6.3.2
| 32
| qemu-kvm 88, host kernel: 2.6.30
| Intel
| 64
| Works
| Use "-net nic,model=ne2k_pci" for network. See also [http://community.qnx.com/sf/wiki/do/viewPage/projects.qemu/wiki/NeutrinoAsGuestInQEMU;jsessionid=82CAC3EC7E4C62A6DC51A1E021618862]
|-

| QNX 6.4.0
| 32
| kvm-83
| Intel
| 64
| Works
| by Arno-Can Uestuensoez / [http://www.UnifiedSessionsManager.org UnifiedSessionsManager]
|-

| QNX 6.4.1
| 32
| qemu-kvm-0.11.0, 2.6.31.5
| Intel
| 64
| Works
|-

|}

== Others ==
{|border=1
| '''Guest'''
| '''Guest bitness'''
| '''Host version'''
| '''Host cpu'''
| '''Host bitness'''
| '''Status'''
| '''Comments'''
|-

| Haiku OS
| 32
| kvm-12
| AMD
| 64
| Works
|
|-

| Amiga Research OS (AROS)
| 32
| kvm-12
| AMD
| 64
| Works
| LiveCD tested.
|-

| Amiga Research OS (AROS)
| 32
| kvm-58
| Intel
| 32
| Works
| LiveCD tested.
|-

| ReactOS 0.3.0
| 32
| kvm-14
| AMD
| 64
| Works
|
|-

| FreeDOS 1.0
| 32
| kvm-71
| Intel
| 64
| Works
|
|-

| MS DOS 6.22
| 32
| kvm-88
| Intel
| 64
| Works
| Works with "-cpu qemu32". Do not load emm386.exe inside config.sys [http://twitpic.com/dce6g screenshot]
|-

| MS DOS 5.0
| 32
| kvm-62
| Intel
| 64
| Works
| Installs and boots. Tested by Alan J.
|-

| Syllable 0.61
| 32
| kvm-29
| Intel
| 64
| Crashes
| by Alexey.E.
|-

| Visopsys 0.62
| 32
| kvm-29
| Intel
| 64
| Crashes
| by Alexey.E.
|-

| Plan 9
| 32
| kvm-68
| Intel
| 64
| Works
| needs -no-kvm-irqchip
|-

| FreeDOS 7 + Novell Netware 4.1
| 32
| kvm-83
| AMD
| 64
| Works
| tested by Ruediger G. Biernat / [http://flickr.com/photos/rgbiernat/3261075882/ screenshot]
| tested by Anna.L Karl /
[http://www.vittleende.se/ Tandblekning]
|}

Main Page

2011-11-07T21:49:32Z

Mjt: Reverted edits by AMunoz (Talk); changed back to last version by Mianosm

== Kernel Based Virtual Machine ==

KVM (for Kernel-based Virtual Machine) is a full virtualization solution for Linux on x86 hardware containing virtualization extensions (Intel VT or AMD-V). It consists of a loadable kernel module, kvm.ko, that provides the core virtualization infrastructure and a processor specific module, kvm-intel.ko or kvm-amd.ko. KVM also requires a modified QEMU although work is underway to get the required changes upstream.

Using KVM, one can run multiple virtual machines running unmodified Linux or Windows images. Each virtual machine has private virtualized hardware: a network card, disk, graphics adapter, etc.

The kernel component of KVM is included in mainline Linux, as of 2.6.20.

KVM is open source software.

== Common Pages ==
{| style="border:none"
|style="width:50%;border:none;"|
* [[KVM Forum]]
** [[KVM Forum 2011]]
** [[KVM Forum 2010]]
* [[LinuxPlumbers2010|Linux Plumbers Conference 2010]]
* [[TODO]]
* [[KVM-Autotest]]
* [[KVM Features]]
|style="width:50%;border:none;"|
* [[Management Tools]]
* [[Documents]]
|}

== Common External Pages ==

{|style="border:none"
|style="width:50%;border:none;"|
* [http://www.qemu.org/ QEMU]
* [http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors Xen's HVM Compatible Processors List]
|style="width:50%;border:none;"|
* [http://qemu-buch.de Book "qemu-kvm & libvirt"]
* [http://qemu-buch.de/cgi-bin/moin.cgi/ QEMU Wiki]
|}

Virtio

2011-08-13T09:37:07Z

Mjt:

=Virtio=

== Paravirtualized drivers for kvm/Linux ==
* Virtio was chosen to be the main platform for IO virtualization in KVM
* The idea behind it is to have a common framework for hypervisors for IO virtualization
* More information (although not uptodate) can be found [[Media:KvmForum2007$kvm_pv_drv.pdf|here]]
* At the moment network/block/balloon devices are suported for kvm
* The host implementation is in userspace - qemu, so no driver is needed in the host.

== How to use Virtio ==
* Get kvm version >= 60
* Get Linux kernel with virtio drivers for the guest
** Get Kernel >= 2.6.25 and activate (modules should also work, but take care of initramdisk)
*** CONFIG_VIRTIO_PCI=y (Virtualization -> PCI driver for virtio devices)
*** CONFIG_VIRTIO_BALLOON=y (Virtualization -> Virtio balloon driver)
*** CONFIG_VIRTIO_BLK=y (Device Drivers -> Block -> Virtio block driver)
*** CONFIG_VIRTIO_NET=y (Device Drivers -> Network device support -> Virtio network driver)
*** CONFIG_VIRTIO=y (automatically selected)
*** CONFIG_VIRTIO_RING=y (automatically selected)
*** you can safely disable SATA/SCSI and also all other nic drivers if you only use VIRTIO (disk/nic)
* As an alternative one can use a standard guest kernel for the guest > 2.6.18 and make use sync backward compatibility option
** Backport and instructions can be found in [http://www.kernel.org/pub/scm/virt/kvm/kvm-guest-drivers-linux.git kvm-guest-drivers-linux.git]
* Use virtio-net-pci device for the network devices (or model=virtio for old -net..-net syntax) and if=virtio for disk
** Example
<pre><nowiki>
x86_64-softmmu/qemu-system-x86_64 -boot c -drive file=/images/xpbase.qcow2,if=virtio -m 384 -netdev type=tap,script=/etc/kvm/qemu-ifup,id=net0 -device virtio-net-pci,netdev=net0
</nowiki></pre>
* -hd[ab] for disk won't work, use -drive
* Disk will show up as /dev/vd[a-z][1-9], if you migrate you need to change "root=" in Lilo/GRUB config
* At the moment the kernel modules are automatically loaded in the guest but the interface should be started manually (dhclient/ifconfig)
* Currently performance is much better when using a host kernel configured with CONFIG_HIGH_RES_TIMERS. Another option is use HPET/RTC and -clock= qemu option.
* Expected performance
** Performance varies from host to host, kernel to kernel
** On my laptop I measured 1.1Gbps rx throughput using 2.6.23, 850Mbps tx.
** Ping latency is 300-500 usec
* Enjoy, more to come :)

__NOTOC__

Virtio

2011-08-13T09:34:26Z

Mjt: changed old -net..-net syntax to -netdev..-device

=Virtio=

== Paravirtualized drivers for kvm/Linux ==
* Virtio was chosen to be the main platform for IO virtualization in KVM
* The idea behind it is to have a common framework for hypervisors for IO virtualization
* More information (although not uptodate) can be found [[Media:KvmForum2007$kvm_pv_drv.pdf|here]]
* At the moment network/block/balloon devices are suported for kvm
* The host implementation is in userspace - qemu, so no driver is needed in the host.

== How to use Virtio ==
* Get kvm version >= 60
* Get Linux kernel with virtio drivers for the guest
** Get Kernel >= 2.6.25 and activate (modules should also work, but take care of initramdisk)
*** CONFIG_VIRTIO_PCI=y (Virtualization -> PCI driver for virtio devices)
*** CONFIG_VIRTIO_BALLOON=y (Virtualization -> Virtio balloon driver)
*** CONFIG_VIRTIO_BLK=y (Device Drivers -> Block -> Virtio block driver)
*** CONFIG_VIRTIO_NET=y (Device Drivers -> Network device support -> Virtio network driver)
*** CONFIG_VIRTIO=y (automatically selected)
*** CONFIG_VIRTIO_RING=y (automatically selected)
*** you can safely disable SATA/SCSI and also all other nic drivers if you only use VIRTIO (disk/nic)
* As an alternative one can use a standard guest kernel for the guest > 2.6.18 and make use sync backward compatibility option
** Backport and instructions can be found in [http://www.kernel.org/pub/scm/virt/kvm/kvm-guest-drivers-linux.git kvm-guest-drivers-linux.git]
* Use model=virtio for the network devices and if=virtio for disk
** Example
<pre><nowiki>
x86_64-softmmu/qemu-system-x86_64 -boot c -drive file=/images/xpbase.qcow2,if=virtio -m 384 -netdev type=tap,script=/etc/kvm/qemu-ifup,id=net0 -device virtio-net-pci,netdev=net0
</nowiki></pre>
* -hd[ab] for disk won't work, use -drive
* Disk will show up as /dev/vd[a-z][1-9], if you migrate you need to change "root=" in Lilo/GRUB config
* At the moment the kernel modules are automatically loaded in the guest but the interface should be started manually (dhclient/ifconfig)
* Currently performance is much better when using a host kernel configured with CONFIG_HIGH_RES_TIMERS. Another option is use HPET/RTC and -clock= qemu option.
* Expected performance
** Performance varies from host to host, kernel to kernel
** On my laptop I measured 1.1Gbps rx throughput using 2.6.23, 850Mbps tx.
** Ping latency is 300-500 usec
* Enjoy, more to come :)

__NOTOC__

Lists, IRC

2011-06-15T17:28:54Z

Mjt:

=Lists, IRC=

== Mailing Lists ==

{|
|-
! list
! topics
! subscribe
! archives
|-
| kvm@vger.kernel.org
| general and x86
| [mailto:majordomo@vger.kernel.org?body=subscribe%20kvm subscribe]
| [http://news.gmane.org/gmane.comp.emulators.kvm.devel Gmane], [http://www.spinics.net/lists/kvm spinics], [http://marc.info/?l=kvm MARC]
|-
| kvm-commits@vger.kernel.org
| kernel commit logs
| [mailto:majordomo@vger.kernel.org?body=subscribe%20kvm-commits subscribe]
| [http://news.gmane.org/gmane.comp.emulators.kvm.scm Gmane]
|-
| kvm-ia64@vger.kernel.org
| ia64
| [mailto:majordomo@vger.kernel.org?body=subscribe%20kvm-ia64 subscribe]
| [http://www.spinics.net/lists/kvm-ia64/ spinics]
|-
| kvm-ppc@vger.kernel.org
| PowerPC
| [mailto:majordomo@vger.kernel.org?body=subscribe%20kvm-ppc subscribe]
| [http://marc.info/?l=kvm-ppc-devel MARC]
|}

While the lists are used mainly for development, user queries are welcome. No need to subscribe for a one-off question, just send an email. You may also want to check the various qemu resources on the web, as kvm shares the qemu user interface and networking.

Please observe the usual mailing list etiquette: don't top-post, and trim excess quotations from the mail you are replying to.

Don't post to individual kvm developers directly.

== IRC ==

Join us on '''#kvm''' at [http://freenode.net Freenode]. Don't report serious bugs on IRC; they're liable to get lost. Use the list or the [[Bugs|bug tracker]].

== Blogs and related sites ==
Haydn Solomon's [http://www.linux-kvm.com linux-kvm] site, featuring forums and a blog

Avi Kivity's [http://avikivity.blogspot.com blog]

Pete Anderssons's [http://www.billigt-flyg.org blog]

Anthony Liguori's [http://blog.codemonkey.ws blog]

[http://virt.kernelnewbies.org/ Linux virtualization] wiki

== Forums ==

[http://forums.meulie.net/viewforum.php?f=43 KVM forum]

Lists, IRC

2011-06-15T17:24:58Z

Mjt:

=Lists, IRC=

== Mailing Lists ==

{|
|-
! list
! topics
! subscribe
! archives
|-
| kvm@vger.kernel.org
| general and x86
| [mailto:majordomo@vger.kernel.org?body=subscribe%20kvm subscribe]
| [http://news.gmane.org/gmane.comp.emulators.kvm.devel Gmane], [http://www.spinics.net/lists/kvm spinics], [http://marc.info/?l=kvm MARC]
|-
| kvm-commits@vger.kernel.org
| kernel commit logs
| [mailto:majordomo@vger.kernel.org?body=subscribe%20kvm-commits subscribe]
| [http://news.gmane.org/gmane.comp.emulators.kvm.scm Gmane]
|-
| kvm-ia64@vger.kernel.org
| ia64
| [mailto:majordomo@vger.kernel.org?body=subscribe%20kvm-ia64 subscribe]
| [http://www.spinics.net/lists/kvm-ia64/ spinics]
|-
| kvm-ppc@vger.kernel.org
| PowerPC
| [mailto:majordomo@vger.kernel.org?body=subscribe%20kvm-ppc subscribe]
| [http://marc.info/?l=kvm-ppc-devel MARC]

While the lists are used mainly for development, user queries are welcome. No need to subscribe for a one-off question, just send an email. You may also want to check the various qemu resources on the web, as kvm shares the qemu user interface and networking.

Please observe the usual mailing list etiquette: don't top-post, and trim excess quotations from the mail you are replying to.

Don't post to individual kvm developers directly.

== IRC ==

Join us on '''#kvm''' at [http://freenode.net Freenode]. Don't report serious bugs on IRC; they're liable to get lost. Use the list or the [[Bugs|bug tracker]].

== Blogs and related sites ==
Haydn Solomon's [http://www.linux-kvm.com linux-kvm] site, featuring forums and a blog

Avi Kivity's [http://avikivity.blogspot.com blog]

Pete Anderssons's [http://www.billigt-flyg.org blog]

Anthony Liguori's [http://blog.codemonkey.ws blog]

[http://virt.kernelnewbies.org/ Linux virtualization] wiki

== Forums ==

[http://forums.meulie.net/viewforum.php?f=43 KVM forum]

Tracing

2011-03-09T15:58:01Z

Mjt:

Tracing is done by means of kernel tracepoints, the ftrace infrastructure, and trace-cmd.

= Installing trace-cmd =

# Install the udis86 and udis86-devel packages
# download trace-cmd:
<nowiki>
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git trace-cmd
$ cd trace-cmd
</nowiki>
# build and install:
<nowiki>
$ make && sudo make install
</nowiki>

= Tracing =

<nowiki>
# trace-cmd record -b 20000 -e kvm
</nowiki>
(trace-cmd will wait)

run your workload, then stop trace-cmd with ctrl-C. trace-cmd will write a trace.dat file.

= Analyzing the trace =

<nowiki>
trace-cmd report
</nowiki>

will format and display the contents of the trace.

UsingVhost

2011-02-24T10:16:23Z

Mjt: formatting

As of September 2010, vhost is not included in any released tarballs, so you need the git version.

[[VhostNet]] provides better latency (10% less than e1000 on my system) and greater throughput (8x the normal virtio, around 7~8 Gigabits/sec here) for network.

=== Obtaining the code ===

you need the at least qemu-kvm-0.13.0 (http://sourceforge.net/projects/kvm/files/qemu-kvm/)

=== kernel requirements ===

On the host you need a kernel with CONFIG_VHOST_NET=y and in the guest you need a kernel with CONFIG_PCI_MSI=y

=== example command line ===
To start a guest with vhost:
* kvm -netdev type=tap,id=guest0,script=kvm-ifup,'''vhost=on''' -device virtio-net-pci,netdev=guest0,mac=''ma:c:a:dd:re:ss'' ..''other options''..

=== Caveats ===
Some DHCP clients have problems with this implementation, more [http://www.spinics.net/lists/kvm/msg37660.html details here].

UsingVhost

2011-02-24T10:11:48Z

Mjt: show the important option in bold

As of September 2010, vhost is not included in any released tarballs, so you need the git version.

[[VhostNet]] provides better latency (10% less than e1000 on my system) and greater throughput (8x the normal virtio, around 7~8 Gigabits/sec here) for network.

=== Obtaining the code ===

you need the at least qemu-kvm-0.13.0 (http://sourceforge.net/projects/kvm/files/qemu-kvm/)

=== kernel requirements ===

On the host you need a kernel with CONFIG_VHOST_NET=y and in the guest you need a kernel with CONFIG_PCI_MSI=y

=== example command line ===
To start a guest with vhost:
* /usr/bin/kvm -netdev type=tap,id=guest0,script=kvm-ifup,'''vhost=on''' -device virtio-net-pci,netdev=guest0,mac=00:16:3e:00:00:01 ..other options..

=== Caveats ===
Some DHCP clients have problems with this implementation, more [http://www.spinics.net/lists/kvm/msg37660.html details here].

Main Page

2011-02-24T09:22:22Z

Mjt: changed qemu main site link to be www.qemu.org

== Kernel Based Virtual Machine ==

KVM (for Kernel-based Virtual Machine) is a full virtualization solution for Linux on x86 hardware containing virtualization extensions (Intel VT or AMD-V). It consists of a loadable kernel module, kvm.ko, that provides the core virtualization infrastructure and a processor specific module, kvm-intel.ko or kvm-amd.ko. KVM also requires a modified QEMU although work is underway to get the required changes upstream.

Using KVM, one can run multiple virtual machines running unmodified Linux or Windows images. Each virtual machine has private virtualized hardware: a network card, disk, graphics adapter, etc.

The kernel component of KVM is included in mainline Linux, as of 2.6.20.

KVM is open source software.

== Common Pages ==
{| style="border:none"
|style="width:50%;border:none;"|
* [[KVM Forum]]
** [[KVM Forum 2010]]
* [[LinuxPlumbers2010|Linux Plumbers Conference 2010]]
* [[TODO]]
* [[KVM-Autotest]]
* [[KVM Features]]
|style="width:50%;border:none;"|
* [[Management Tools]]
* [[Documents]]
|}

== Common External Pages ==

{|style="border:none"
|style="width:50%;border:none;"|
* [http://www.qemu.org/ QEMU]
* [http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors Xen's HVM Compatible Processors List]
|style="width:50%;border:none;"|
* [http://qemu-buch.de Book "qemu-kvm & libvirt"]
* [http://qemu-buch.de/cgi-bin/moin.cgi/ QEMU Wiki]
|}

Lists, IRC

2010-12-14T22:48:26Z

Mjt: remove spam by Garydavid, _again_

=Lists, IRC=

== Mailing Lists ==

{|
|-
! list
! topics
! subscribe
! archives
|-
| kvm@vger.kernel.org
| general and x86
| [mailto:majordomo@vger.kernel.org?body=subscribe%20kvm subscribe]
| [http://news.gmane.org/gmane.comp.emulators.kvm.devel Gmane], [http://www.spinics.net/lists/kvm spinics], [http://marc.info/?l=kvm MARC]
|-
| kvm-commits@vger.kernel.org
| kernel commit logs
| [mailto:majordomo@vger.kernel.org?body=subscribe%20kvm-commits subscribe]
| [http://news.gmane.org/gmane.comp.emulators.kvm.scm Gmane]
|-
| kvm-ia64@vger.kernel.org
| ia64
| [mailto:majordomo@vger.kernel.org?body=subscribe%20kvm-ia64 subscribe]
|
|-
| kvm-ppc@vger.kernel.org
| PowerPC
| [mailto:majordomo@vger.kernel.org?body=subscribe%20kvm-ppc subscribe]
| [http://marc.info/?l=kvm-ppc-devel MARC]
|
|}

While the lists are used mainly for development, user queries are welcome. No need to subscribe for a one-off question, just send an email. You may also want to check the various qemu resources on the web, as kvm shares the qemu user interface and networking.

Please observe the usual mailing list etiquette: don't top-post, and trim excess quotations from the mail you are replying to.

Don't post to individual kvm developers directly.

== IRC ==

Join us on '''#kvm''' at [http://freenode.net Freenode]. Don't report serious bugs on IRC; they're liable to get lost. Use the list or the [[Bugs|bug tracker]].

== Blogs and related sites ==
Haydn Solomon's [http://www.linux-kvm.com linux-kvm] site, featuring forums and a blog

Avi Kivity's [http://avikivity.blogspot.com blog]

Anthony Liguori's [http://blog.codemonkey.ws blog]

[http://virt.kernelnewbies.org/ Linux virtualization] wiki

== Forums ==

[http://forums.meulie.net/viewforum.php?f=43 KVM forum]

Lists, IRC

2010-11-10T22:08:40Z

Mjt:

=Lists, IRC=

== Mailing Lists ==

{|
|-
! list
! topics
! subscribe
! archives
|-
| kvm@vger.kernel.org
| general and x86
| [mailto:majordomo@vger.kernel.org?body=subscribe%20kvm subscribe]
| [http://news.gmane.org/gmane.comp.emulators.kvm.devel Gmane], [http://www.spinics.net/lists/kvm spinics], [http://marc.info/?l=kvm MARC]
|-
| kvm-commits@vger.kernel.org
| kernel commit logs
| [mailto:majordomo@vger.kernel.org?body=subscribe%20kvm-commits subscribe]
| [http://news.gmane.org/gmane.comp.emulators.kvm.scm Gmane]
|-
| kvm-ia64@vger.kernel.org
| ia64
| [mailto:majordomo@vger.kernel.org?body=subscribe%20kvm-ia64 subscribe]
|
|-
| kvm-ppc@vger.kernel.org
| PowerPC
| [mailto:majordomo@vger.kernel.org?body=subscribe%20kvm-ppc subscribe]
| [http://marc.info/?l=kvm-ppc-devel MARC]
|
|}

While the lists are used mainly for development, user queries are welcome. No need to subscribe for a one-off question, just send an email. You may also want to check the various qemu resources on the web, as kvm shares the qemu user interface and networking.

Please observe the usual mailing list etiquette: don't top-post, and trim excess quotations from the mail you are replying to.

Don't post to individual kvm developers directly.

== IRC ==

Join us on '''#kvm''' at [http://freenode.net Freenode]. Don't report serious bugs on IRC; they're liable to get lost. Use the list or the [[Bugs|bug tracker]].

== Blogs and related sites ==
Haydn Solomon's [http://www.linux-kvm.com linux-kvm] site, featuring forums and a blog

Avi Kivity's [http://avikivity.blogspot.com blog]

Anthony Liguori's [http://blog.codemonkey.ws blog]

[http://virt.kernelnewbies.org/ Linux virtualization] wiki

== Forums ==

[http://forums.meulie.net/viewforum.php?f=43 KVM forum]

Code

2010-10-18T18:05:24Z

Mjt:

=Code=

[[Category:Architechture]]

== kernel git tree ==

The kvm kernel code is available through a git tree (like the kernel itself). To create a repository using git, type

git clone git://git.kernel.org/pub/scm/virt/kvm/kvm.git

Alternatively, it is also accessible through the kernel.org gitweb interface:
[http://git.kernel.org/?p=virt/kvm/kvm.git;a=summary]

For subsequent upgrades use the command

git pull

in the git working directory.

== userspace git tree ==

The kvm userspace code (libkvm and qemu) is available through a git tree. To create a repository using git, type

git clone git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git

Alternatively, it is also accessible through the kernel.org gitweb interface:
[http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=summary]

== building an external module with older kernels ==

'''This only works for the x86 architecture.'''

1. If you wish to use a distribution kernel (or just some random kernel you like) with kvm,
you can use the external module kit. You will need the kvm-kmod repository:

git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git
cd kvm-kmod
git submodule update --init
./configure [--kerneldir=/path/to/kernel/dir]
make sync
make

=== Tip about building against Red Hat Enterprise Linux kernels ===

<code>kvm-userspace/kernel</code> has some compat code to allow it to compile against older kernels, and also some code specific to features that are normally not present on older kernels but are present on RHEL kernels.

So, when building against a RHEL kernel tree, check if the <code>RHEL_*</code> macros at <code>${kerneldir}/include/linux/version.h</code> are defined correctly, corresponding to the RHEL version where the kernel source comes from. If those macros aren't defined correctly, the compat code that allows compilation against RHEL kernels will break and you will get build errors.

== release tags ==

kvm stable releases (based off of Qemu's stable branch) are tagged with <code>kvm-qemu-0.NN.N</code> where ''N'' equates to the upstream Qemu branch versions. Note that kvm has them tagged not branched.

kvm development releases are tagged with <code>kvm-nn</code> where ''nn'' is the release number.

== Binary Packages ==

=== CentOS / RHEL ===

Unofficial packages of latest releases can be found at:
<code>http://www.lfarkas.org/linux/packages/centos/5/</code>

=== Debian ===

For Debian Lenny, please use packages from backports.debian.org - for <em>both</em> qemu-kvm and kernel (at least 2.6.32). It is important to use more recent kernel - 2.6.26 does not work well with kvm.

Note that package "kvm" has been renamed to "qemu-kvm" in Squeeze and in Lenny backports (and kvm is now transitional package that installs qemu-kvm automatically).

Debian Squeeze will have qemu-kvm based on 0.12, available in standard repositories.

Experimental 0.13 packages are available at
<code>http://www.corpit.ru/debian/tls/kvm/0.13/</code> , pending upload to debian -experimental.

== nightly snapshots ==

Nightly snapshots, for those who are uncomfortable with git, are [http://people.qumranet.com/avi/snapshots available]. When reporting a problem with a snapshot, please quote the snapshot name (which includes the date) and the contents of the SOURCES file in the snapshot tarball.

VhostNet

2010-09-15T13:16:17Z

Mjt: -netdev type=tap, not -netdev tap

vhost-net: a kernel-level virtio-net server

== What is vhost-net ==

vhost is a kernel-level backend for virtio.
The main motivation for vhost is to reduce virtualization
overhead for virtio by removing system calls on data path,
without guest changes. For virtio-net, this removes up to
4 system calls per packet: vm exit for kick, reentry for kick,
iothread wakeup for packet, interrupt injection for packet.

vhost is as minimal as possible. It relies on userspace for
all setup work.

=== Status ===
vhost is fully functional, and it already shows
improvement over userspace virtio.

== How to use ==

Download, build an install kernel from:

kernel:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost
userspace:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu-kvm.git vhost

=== Usage instructions: ===

vhost currently requires MSI-X support in guest virtio.
This means guests kernel version should be >= 2.6.31.

To enable vhost, simply add ",vhost" flag to nic options.
Example with tap backend:

qemu-system-x86_64 -m 1G disk-c.qcow2 \
-net nic,model=virtio,netdev=foo \
-netdev type=tap,id=foo,ifname=msttap0,script=/home/mst/ifup,downscript=no,'''vhost=on'''

Older (demo) version usage:
Example with tap backend:

qemu-system-x86_64 -m 1G disk-c.qcow2 \
-net tap,ifname=msttap0,script=/home/mst/ifup,downscript=no \
-net nic,model=virtio,'''vhost'''

Example with raw socket backend:

ifconfig eth3 promisc
qemu-system-x86_64 -m 1G disk-c.qcow2 \
-net raw,ifname=eth3 \
-net nic,model=virtio,'''vhost'''

Note: in raw socket mode, when binding to a physical
ethernet device, host to guest communication
will only work if your device is connected to a bridge
configured to mirror outgoing packets back at the originating link.
If you do not know whether this is the case, this most likely
means it isn't. Use another box to access the guest, or use tap.

== Limitations ==
* vhost currently requires MSI-X support in guest virtio. This means guests kernel version should be >= 2.6.31.
* with raw sockets, host to guest, and guest to guest communication on the same host does not always work. Use bridge+tap if you need that.
* driver unloading in guest and device hot-unplug are broken, because the relevant code in qemu is stubbed out. Need to implement them.

== Performance ==

Still tuning performance, especially guest to host.

External to system numbers with bridge+tap and 10GE vxge card:
qemu with bridge+tap, run with: -cpu host,-rdtscp,+x2apic,
host+guest 2.6.33-rc2. mtu 1500.

* netperf TCP_STREAM, default setup, 100 secs run
native: 81XX Mb/s
without vhost-net: 72XX Mb/s
with vhost-net: 78XX Mb/s

* TCP_RR, 100 secs run
native: 48 usec/Trans
without vhost-net: 395 usec/Trans
with vhost-net: 86 usec/Trans

Here are some local numbers coutesy of Shirley Ma:

* netperf TCP_STREAM, default setup, 60 secs run
guest->host increases from 3XXXMb/s to 5XXXMb/s
host->guest increases from 3XXXMb/s to 4XXXMb/s

* TCP_RR, 60 secs run
guest->host trans/s increases from 2XXX/s to 13XXX/s
host->guest trans/s increases from 2XXX/s to 13XXX/s

== TODOs ==

=== vhost-net driver projects ===
* profiling would be very helpful, I have not done any yet.
* merged buffers.
* scalability tuning: figure out the best threading model to use.

=== qemu projects ===
* migration support
* level triggered interrupts
* driver unloading/hotplug
* general cleanup and upstreaming
* upstream support for injecting interrupts from kernel, from qemu-kvm.git to qemu.git (this is a vhost dependency, without it vhost can't be upstreamed, or it can, but without real benefit)

=== virtio projects ===
* improve small packet/large buffer performance: support "reposting" buffers, pool for indirect buffers
* guest kernel 2.6.31 seems to work well. Under certain workloads,
virtio performance has regressed with guest kernels 2.6.32 and up
(but still better than userspace). A patch has been posted:
http://www.spinics.net/lists/netdev/msg115292.html

=== projects involing other kernel components and/or networking stack ===
* rx mac filtering in tun
* extend raw sockets to support GSO/checksum offloading, and teach vhost to use that capability [one way to do this: virtio net header support]; will allow working with e.g. macvlan
* improve locking: e.g. RX/TX poll should not need a lock
* multicast ICMPs snooping in bridge

=== long term projects ===
* kvm eventfd support for injecting level interrupts
* multiqueue (involves all of vhost, qemu, virtio, networking stack)
* zero copy tx for tun/raw sockets

=== Other ===
* More testing is always good

== Short term plans for MST ==

* get vhost net merged in linux kernel 2.6.33
* address most vhost qemu TODOs
* get vhost support merged in upstream qemu

== Short term plans for IBM(Sridhar Samudrala, David Stevens, Shirley MA) ==
* Add GSO/checksum offload support to AF_PACKET(raw) sockets.
* Mergeable RX buffers support in vhost-net.
* Defer SKB allocation in virtio_net receive path.

UsingVhost

2010-09-15T13:11:33Z

Mjt: add a link to vhost page

As of September 2010, vhost is not included in any released tarballs, so you need the git version.

[[VhostNet]] provides better latency (10% less than e1000 on my system) and greater throughput (8x the normal virtio, around 7~8 Gigabytes/sec here) for network.

=== Obtaining the code ===

* git clone git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
* git checkout refs/remotes/origin/stable-0.13
* cd kvm
* compile as usual

=== kernel requirements ===

On the host you need a kernel with CONFIG_VHOST_NET=y and in the guest you need a kernel with CONFIG_PCI_MSI=y

=== example command line ===
To start a guest with vhost:
* /usr/bin/kvm -netdev type=tap,id=guest0,script=kvm-ifup,vhost=on -device virtio-net-pci,netdev=guest0,mac=00:16:3e:00:00:01 ..other options..

UsingVhost

2010-09-15T13:07:51Z

Mjt: drop irrelevant command-line arguments in the example, to show only net-related ones

As of September 2010, vhost is not included in any released tarballs, so you need the git version.

Vhost provides better latency (10% less than e1000 on my system) and greater throughput (8x the normal virtio, around 7~8 Gigabytes/sec here) for network.

=== Obtaining the code ===

* git clone git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
* git checkout refs/remotes/origin/stable-0.13
* cd kvm
* compile as usual

=== kernel requirements ===

On the host you need a kernel with CONFIG_VHOST_NET=y and in the guest you need a kernel with CONFIG_PCI_MSI=y

=== example command line ===
To start a guest with vhost:
* /usr/bin/kvm -netdev type=tap,id=guest0,script=kvm-ifup,vhost=on -device virtio-net-pci,netdev=guest0,mac=00:16:3e:00:00:01 ..other options..