KVM - User contributions [en]

KVM Features

2018-03-10T10:20:25Z

Ckotichas:

= KVM-Features =

This is a possibly incomplete list of KVM features, together with their status. Feel free to update any of them as you see fit.

As a guideline, there is a feature description template in [[FeatureDescription/Template|here]]

* [[MonitorProtocol|QMP]] - Qemu Monitor Protocol
* [[KSM|KSM]] - Kernel Samepage Merging
* [[KVMClock|KVM Paravirtual Clock]] - A paravirtual timesource for KVM
* [[CPUHotPlug|CPU Hotplug support]] - Adding CPU's on the fly
* [[pcihotplug|PCI Hotplug support]] - Adding PCI devices on the fly
* [[VMchannel_Requirements | vmchannel ]] - Communication channel between the host and guests
* [[migration]] - Migrating virtual machines
* [[Nested Guests]] - Running virtual machines within virtual machines
* [[VhostNet|vhost]] -
* [[scsi|SCSI disk emulation]] -
* [[virtio|Virtio Devices]] -
* [[CPU clustering]] -
* [[hpet]] -
* [[Device assignment]] -
* [[pxe boot]] -
* [[iscsi boot]] -
* [[x2apic]] -
* [[Floppy]] -
* [[cdrom|CDROM]] -
* [[USB]] -
* [[UsbPassthrough|USB host device passthrough]] -
* [[Sound]] -
* [[UserspaceIrqchip|Userspace irqchip emulation]] -
* [[UserspacePit|Userspace pit emulation]] -
* [[Balloon|Balloon memory driver]] -
* [[LargePages|Large pages support]] -
* [[StableABI|Stable Guest ABI]] -

KVM Features

2018-03-10T10:19:44Z

Ckotichas:

= KVM-Features =

This is a possibly incomplete list of KVM features, together with their status. Feel free to update any of them as you see fit.

As a guideline, there is a feature description template in [[FeatureDescription/Template|here]]

* [[MonitorProtocol|QMP]] - Qemu Monitor Protocol
* [[KSM|KSM]] - Kernel Samepage Merging
* [[KVMClock|Kvm Paravirtual Clock]] - A Paravirtual timesource for KVM
* [[CPUHotPlug|CPU Hotplug support]] - Adding CPU's on the fly
* [[pcihotplug|PCI Hotplug support]] - Adding PCI devices on the fly
* [[VMchannel_Requirements | vmchannel ]] - Communication channel between the host and guests
* [[migration]] - Migrating virtual machines
* [[Nested Guests]] - Running virtual machines within virtual machines
* [[VhostNet|vhost]] -
* [[scsi|SCSI disk emulation]] -
* [[virtio|Virtio Devices]] -
* [[CPU clustering]] -
* [[hpet]] -
* [[Device assignment]] -
* [[pxe boot]] -
* [[iscsi boot]] -
* [[x2apic]] -
* [[Floppy]] -
* [[cdrom|CDROM]] -
* [[USB]] -
* [[UsbPassthrough|USB host device passthrough]] -
* [[Sound]] -
* [[UserspaceIrqchip|Userspace irqchip emulation]] -
* [[UserspacePit|Userspace pit emulation]] -
* [[Balloon|Balloon memory driver]] -
* [[LargePages|Large pages support]] -
* [[StableABI|Stable Guest ABI]] -

Sound

2018-03-10T10:16:39Z

Ckotichas:

== Windows XP ==
Windows XP recognizes QEMU's emulated Ensoniq AudioPCI ES1370 device automatically.
== Windows Vista ==
TBD
== Windows 7 ==
Intel 82801AA AC97 emulation works with Windows 7, but is detected as a "Multimedia Audio Controller" device. The correct driver can be installed through the Device Manager menu by selecting "Update Driver" in the device's Properties window. Windows will automatically obtain the correct driver from the internet.

ENSONIQ AudioPCI ES1370 emulation is also recognised by Windows with the same process, but the driver is prone to crashing.

Windows7Install

2018-03-10T10:05:24Z

Ckotichas:

= Introduction =
Some facts:
* Installing Windows 7 with IDE drivers requires about 12 hours (qemu-kvm 0.12.5)
* Windows 7 can be installed with virtio disk (requires guest drivers during installation)
* Windows 7 64-bit requires signed drivers (available from August 2010 - thanks to RedHat)
* Installation with virtio drivers works well, but Windows might not reboot at the end (see troubleshooting)

Signed guest drivers are available here:
* https://fedoraproject.org/wiki/Windows_Virtio_Drivers

= Installation steps =
* Download the guest drivers
* Configure the virtual disk as virtio
* Start the installation
** When the installer asks you to select a drive, load the virtio driver (viostor)
** The installation should take 45 to 60 minutes

If you don't want to swap the CD, configure 2 CD-ROM devices. Use the guest drivers disc as the first CD-ROM device, and Windows installation disc as the second device, or else it won't boot.

Once installed, if you did choose virtio for the network card, you will also need to update the driver.

= Troubleshooting =

== Cannot boot - broken MBR ==
Upon reboot, the screen displays:
<div style="border:1px solid gray; background:black;color:white;padding: 10px;width:500px;">
<pre>
Starting SeaBIOS (version 0.5.1-20100825_131917-polaris)

Booting from Hard Disk...
</pre>
</div>

The libvirt log shows
<pre>
kvm: unhandled exit 80000021
kvm_run returned -22
</pre>

The solution is to reinstall the MBR. Here is a tutorial for doing this: http://www.sevenforums.com/tutorials/20864-mbr-restore-windows-7-master-boot-record.html

Windows7Install

2018-03-10T10:01:29Z

Ckotichas:

= Introduction =
Some facts:
* Installing Windows 7 with IDE drivers requires about 12 hours (qemu-kvm 0.12.5)
* Windows 7 can be installed with virtio disk (requires guest drivers during installation)
* Windows 7 64-bit requires signed drivers (available from August 2010 - thanks to RedHat)
* Installation with virtio drivers works well, but Windows might not reboot at the end (see troubleshooting)

Signed guest drivers are available here:
* https://fedoraproject.org/wiki/Windows_Virtio_Drivers

= Installation steps =
* Download the guest drivers
* Configure the virtual disk as virtio
* Start the installation
** When the installer asks you to select a drive, load the virtio driver (viostor)
** The installation should take 45 to 60 minutes

If you don't want to swap the CD, configure 2 CD-ROMs. Use the guest drivers as first CD-ROM, and Windows installation disk as second, else it won't boot.

Once installed, if you did choose virtio for the network card, you will also need to update the driver.

= Troubleshooting =

== Cannot boot - broken MBR ==
Upon reboot, the screen displays:
<div style="border:1px solid gray; background:black;color:white;padding: 10px;width:500px;">
<pre>
Starting SeaBIOS (version 0.5.1-20100825_131917-polaris)

Booting from Hard Disk...
</pre>
</div>

The libvirt log shows
<pre>
kvm: unhandled exit 80000021
kvm_run returned -22
</pre>

The solution is to reinstall the MBR. Here is a tutorial for doing this: http://www.sevenforums.com/tutorials/20864-mbr-restore-windows-7-master-boot-record.html

HOWTO

2017-01-20T03:23:35Z

Ckotichas: /* Operating System related */

= Howto's =

== General ==
* [http://www.ibm.com/support/knowledgecenter/linuxonibm/liabq/liabqquick.htm IBM PowerKVM: Quick Start Guides for installing PowerKVM]
* [http://www.ibm.com/support/knowledgecenter/linuxonibm/liabo/liabokickoff.htm IBM PowerKVM]
* [http://www.ibm.com/support/knowledgecenter/linuxonibm/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.scribd.com/doc/17380947/Migrating-from-UML-to-Xen-and-Kernel-Based-Virtual-Machines 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 ===
* [http://wiki.gentoo.org/wiki/QEMU Wiki article].
* [[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]

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

=== RHEL/CentOS 7 ===
* [http://linux.dell.com/files/whitepapers/KVM_Virtualization_in_RHEL_7_Made_Easy.pdf KVM Virtualization in RHEL 7 Made Easy]

=== 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
* [http://www.returnbooleantrue.com/2015/04/making-your-windows-kvm-guest-boxes-fly.html Installing virtio drivers in Windows for Ubuntu hosts]

=== 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
* [https://github.com/tmartinfr/kvm-simple-init kvm-simple-init] - Simple init script to manage KVM virtual machines

=== libvirt ===

* [[Running libvirt with KVM]]

== Other ==

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

[[Category:Docs]][[Category:HowTo]]

Choose the right kvm & kernel version

2017-01-20T03:19:04Z

Ckotichas: /* Three Components */

== Three Components ==

A functional KVM system consists of three main components:

* Linux Module
* User Space Application
* Guest Virtio Driver

== Linux Module ==

KVM requires a few kernel modules in order to support full virtualization. Most distributions contain these modules by default, but they may need to be loaded manually. You can check if the KVM module is currently loaded with:

lsmod | grep kvm

If the module is not loaded, simply issue:

modprobe kvm

You may also need to load the appropriate module for your processor:

modprobe kvm_intel # Intel processors
modprobe kvm_amd # AMD processors

=== Guest virtio driver ===

Generally, there are no special requirements for the guest operating system. If you are using para-virtualized disks or network adapters however, make sure you have loaded the virtio_pci.ko, virtio_rng.ko, virtio_blk.ko, and virtio_net.ko modules (available since kernel version 2.6.25).

Refer to [[Virtio]] for more information

[[Category:Architecture]][[Category:Docs]][[Category:Historical]][[Category:HowTo]]

Choose the right kvm & kernel version

2017-01-20T03:16:59Z

Ckotichas: /* Linux Module */

== Three Components ==

To make it work, you need to get the right version for three components:

* Linux Module
* User Space Application
* Guest Virtio Driver

== Linux Module ==

KVM requires a few kernel modules in order to support full virtualization. Most distributions contain these modules by default, but they may need to be loaded manually. You can check if the KVM module is currently loaded with:

lsmod | grep kvm

If the module is not loaded, simply issue:

modprobe kvm

You may also need to load the appropriate module for your processor:

modprobe kvm_intel # Intel processors
modprobe kvm_amd # AMD processors

=== Guest virtio driver ===

Generally, there are no special requirements for the guest operating system. If you are using para-virtualized disks or network adapters however, make sure you have loaded the virtio_pci.ko, virtio_rng.ko, virtio_blk.ko, and virtio_net.ko modules (available since kernel version 2.6.25).

Refer to [[Virtio]] for more information

[[Category:Architecture]][[Category:Docs]][[Category:Historical]][[Category:HowTo]]

HOWTO

2017-01-20T02:54:52Z

Ckotichas: /* General */

= Howto's =

== General ==
* [http://www.ibm.com/support/knowledgecenter/linuxonibm/liabq/liabqquick.htm IBM PowerKVM: Quick Start Guides for installing PowerKVM]
* [http://www.ibm.com/support/knowledgecenter/linuxonibm/liabo/liabokickoff.htm IBM PowerKVM]
* [http://www.ibm.com/support/knowledgecenter/linuxonibm/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.scribd.com/doc/17380947/Migrating-from-UML-to-Xen-and-Kernel-Based-Virtual-Machines 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 ]

=== RHEL/CentOS 7 ===
* [http://linux.dell.com/files/whitepapers/KVM_Virtualization_in_RHEL_7_Made_Easy.pdf KVM Virtualization in RHEL 7 Made Easy]

=== 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
* [http://www.returnbooleantrue.com/2015/04/making-your-windows-kvm-guest-boxes-fly.html Installing virtio drivers in Windows for Ubuntu hosts]

=== 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
* [https://github.com/tmartinfr/kvm-simple-init kvm-simple-init] - Simple init script to manage KVM virtual machines

=== libvirt ===

* [[Running libvirt with KVM]]

== Other ==

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

[[Category:Docs]][[Category:HowTo]]

KVM Features

2017-01-20T02:50:53Z

Ckotichas: /* KVM-Features */

= KVM-Features =

This is a possibly incomplete list of KVM features, together with their status. Feel free to update any of them as you see fit.

As a guideline, there is a feature description template in [[FeatureDescription/Template|here]]

* [[MonitorProtocol|QMP]] - Qemu Monitor Protocol
* [[KSM|KSM]] - Kernel Samepage Merging
* [[KVMClock|Kvm Paravirtual Clock]] - A Paravirtual timesource for KVM
* [[CPUHotPlug|CPU Hotplug support]] - Adding cpus on the fly
* [[pcihotplug|PCI Hotplug support]] - Adding pci devices on the fly
* [[VMchannel_Requirements | vmchannel ]] - Communication channel between the host and guests
* [[migration]] - Migrating Virtual Machines
* [[VhostNet|vhost]] -
* [[scsi|SCSI disk emulation]] -
* [[virtio|Virtio Devices]] -
* [[CPU clustering]] -
* [[hpet]] -
* [[Device assignment]] -
* [[pxe boot]] -
* [[iscsi boot]] -
* [[x2apic]] -
* [[Floppy]] -
* [[cdrom|CDROM]] -
* [[USB]] -
* [[UsbPassthrough|USB host device passthrough]] -
* [[Sound]] -
* [[UserspaceIrqchip|Userspace irqchip emulation]] -
* [[UserspacePit|Userspace pit emulation]] -
* [[Balloon|Balloon memory driver]] -
* [[LargePages|Large pages support]] -
* [[StableABI|Stable Guest ABI]] -

KVM Features

2017-01-20T02:48:43Z

Ckotichas: /* KVM-Features */

= KVM-Features =

This is a possibly incomplete list of KVM features, together with their status. Feel free to update any of them as you see fit.

As a guideline, there is a feature description template in [[FeatureDescription/Template|here]]

* [[MonitorProtocol|QMP]] - Qemu Monitor Protocol
* [[KSM|KSM]] - Kernel Samepage Merging
* [[KVMClock|Kvm Paravirtual Clock]] - A Paravirtual timesource for KVM
* [[CPUHotPlug|CPU Hotplug support]] - Adding cpus on the fly
* [[pcihotplug|PCI Hotplug support]] - Adding pci devices on the fly
* [[VMchannel_Requirements | vmchannel ]] - Communication channel between the host and guests
* [[migration]] - Migrating Virtual Machines
* [[VhostNet|vhost]] -
* [[scsi|SCSI disk emulation]] -
* [[virtio|Virtio Devices]] -
* [[CPU clustering]] -
* [[hpet]] -
* [[Device assignment]] -
* [[pxe boot]] -
* [[iscsi boot]] -
* [[x2apic]] -
* [[Floppy]] -
* [[CDROM]] -
* [[USB]] -
* [[UsbPassthrough|USB host device passthrough]] -
* [[Sound]] -
* [[UserspaceIrqchip|Userspace Irqchip emulation]] -
* [[UserspacePit|Userspace pit emulation]] -
* [[Balloon|Balloon memory driver]] -
* [[LargePages|Large pages support]] -
* [[StableABI|Stable Guest ABI]] -

VGA device assignment

2017-01-20T02:44:19Z

Ckotichas: /* Open issues */

= Assigning physical VGA adapters =

It would appear that assigning modern PCI/PCIe VGA adapters should not be any different from [[How_to_assign_devices_with_VT-d_in_KVM|passing through normal PCI devices]]. But there are additional challenges to solve, specifically related to legacy VGA requirements and proprietary mechanisms to relocate I/O regions of the adapters. Moreover, some QEMU and SeaBIOS deficits contribute to the current situation that things rarely work out of the box.

== Open issues ==

* '''Insufficient PCI window size''' This is a fixable SeaBIOS limitation. Patches are currently under development by [http://www.kraxel.org/cgit/seabios/log/?h=kraxel.q35&id=99ff4d141d5a460eaf20fe2d4d13117c888eae15 Gerd Hoffmann].
* '''Non-standard I/O region remapping''' Some NVIDIA Quadro adapters are known to be affected by this, but probably only during early boot. A workaround could be identity mapping, i.e. locating the memory BARs in the guest at the same locations as on the host. Of course, this breaks if the guest OS or guest drivers decide to remap them.
* '''Legacy VGA support''' In order to get boot messages of the guest BIOS, boot loader, or early OS stages, access to the legacy VGA PIO and MMIO regions need to be forwarded to the passed-through adapter. Moreover, the VBIOS of the adapter must be bootable inside the guest. As a result, the following aspects will need to be addressed:
** '''Legacy VGA pass-through''' QEMU requires patches to forward guest access to legacy VGA via the assigned adapter.
** '''PAM/SRAM QEMU breakage''' Current QEMU contains broken code that prevents access to legacy VGA even if the adapter is emulated but differently initialized (test case: -vga none -device VGA)
** '''Legacy VGA arbitration''' As the legacy IO resources cannot be remapped, access needs to be switched between guests and the host on demand. The Linux kernel provides a VGA arbiter for this purpose, but it is not used consistently by all involved parties. Moreover, QEMU also requires additional patches to support this.
** '''VBIOS ROM access''' To re-run the POST procedures of the assigned adapter inside the guest, the proper VBIOS ROM image has to be used. However, when passing through the primary adapter of the host, Linux provides only access to the shadowed version of the VBIOS which may differ from the pre-POST version (due to modifications applied during POST). This has been observed with NVIDIA Quadro adapters. A workaround is to retrieve the VBIOS from the adapter while it is in secondary mode and use this saved image (-device pci-assign,...,romfile=...). But even that may fail, either due to problems of the host chipset or BIOS (e.g. host kernel complains about an unmappable ROM BAR).

== Potential tweaks & tricks ==

* Some adapters may advertise MSI support even if that feature does not work properly. In that case, KVM will use MSI on the host side unconditionally unless instructed to follow the guest driver usage via -device pci-assign,...,prefer_msi=off.

== Success stories ==

Despite all existing problems, some users have already succeeded in utilizing pass-through functionality for various VGA adapters:

* [http://thread.gmane.org/gmane.comp.emulators.kvm.devel/94524 Radeon HD 7870]
* [http://thread.gmane.org/gmane.comp.emulators.kvm.devel/104760 Radeon HD 7750]
* [http://thread.gmane.org/gmane.comp.emulators.kvm.devel/72987 Radeon HD 6950 with patched SeaBIOS]
* [http://tavi-tech.blogspot.com.au/2012/05/vga-passthrough-kvm-fedora-17-and.html Radeon HD 6770]
* [http://thread.gmane.org/gmane.comp.emulators.kvm.devel/71981 Radeon HD 5850]

VGA device assignment

2017-01-20T02:43:28Z

Ckotichas: /* Assigning physical VGA adapters */

= Assigning physical VGA adapters =

It would appear that assigning modern PCI/PCIe VGA adapters should not be any different from [[How_to_assign_devices_with_VT-d_in_KVM|passing through normal PCI devices]]. But there are additional challenges to solve, specifically related to legacy VGA requirements and proprietary mechanisms to relocate I/O regions of the adapters. Moreover, some QEMU and SeaBIOS deficits contribute to the current situation that things rarely work out of the box.

== Open issues ==

* '''Insufficient PCI window size''' This is a fixable SeaBIOS limitation. Patches are currently under development by [http://www.kraxel.org/cgit/seabios/log/?h=kraxel.q35&id=99ff4d141d5a460eaf20fe2d4d13117c888eae15 Gerd Hoffmann]
* '''Non-standard I/O region remapping''' Some NVIDIA Quadro adapters are known to be affected by this, but probably only during early boot. A workaround could be identity mapping, i.e. locating the memory BARs in the guest at the same locations as on the host. Of course, this breaks if the guest OS or guest drivers decide to remap them.
* '''Legacy VGA support''' In order to get boot messages of the guest BIOS, boot loader, or early OS stages, access to the legacy VGA PIO and MMIO regions need to be forwarded to the passed-through adapter. Moreover, the VBIOS of the adapter must be bootable inside the guest. As a result, the following aspects will need to be addressed:
** '''Legacy VGA pass-through''' QEMU requires patches to forward guest access to legacy VGA via the assigned adapter.
** '''PAM/SRAM QEMU breakage''' Current QEMU contains broken code that prevents access to legacy VGA even if the adapter is emulated but differently initialized (test case: -vga none -device VGA)
** '''Legacy VGA arbitration''' As the legacy IO resources cannot be remapped, access needs to be switched between guests and the host on demand. The Linux kernel provides a VGA arbiter for this purpose, but it is not used consistently by all involved parties. Moreover, QEMU also requires additional patches to support this.
** '''VBIOS ROM access''' To re-run the POST procedures of the assigned adapter inside the guest, the proper VBIOS ROM image has to be used. However, when passing through the primary adapter of the host, Linux provides only access to the shadowed version of the VBIOS which may differ from the pre-POST version (due to modifications applied during POST). This has been observed with NVIDIA Quadro adapters. A workaround is to retrieve the VBIOS from the adapter while it is in secondary mode and use this saved image (-device pci-assign,...,romfile=...). But even that may fail, either due to problems of the host chipset or BIOS (e.g. host kernel complains about an unmappable ROM BAR).

== Potential tweaks & tricks ==

* Some adapters may advertise MSI support even if that feature does not work properly. In that case, KVM will use MSI on the host side unconditionally unless instructed to follow the guest driver usage via -device pci-assign,...,prefer_msi=off.

== Success stories ==

Despite all existing problems, some users have already succeeded in utilizing pass-through functionality for various VGA adapters:

* [http://thread.gmane.org/gmane.comp.emulators.kvm.devel/94524 Radeon HD 7870]
* [http://thread.gmane.org/gmane.comp.emulators.kvm.devel/104760 Radeon HD 7750]
* [http://thread.gmane.org/gmane.comp.emulators.kvm.devel/72987 Radeon HD 6950 with patched SeaBIOS]
* [http://tavi-tech.blogspot.com.au/2012/05/vga-passthrough-kvm-fedora-17-and.html Radeon HD 6770]
* [http://thread.gmane.org/gmane.comp.emulators.kvm.devel/71981 Radeon HD 5850]

Networking

2016-07-25T00:40:21Z

Ckotichas: /* Public Bridge */

= Configuring Guest Networking =

Guest (VM) networking in kvm is the same as in qemu, so it is possible to refer to other documentation about networking in qemu. This page will try to explain how to configure the most frequent types of networking 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, then the user needs to have rw access to /dev/kvm
* In order for the guest to be able to access the internet or a local network, the host system must be able to access these resources as well

'''Solution:'''
* Simply run your guest without specifying network parameters, which by default will create user-level (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
* The 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 an rtl8139-based network interface.
* 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 the 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, then the user needs to have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
ip
brctl (deprecated). Use ip link instead
tunctl (deprecated). Use ip tuntap and ip link instead

'''Solution:'''

* You need to create a bridge, e-g:
# ip link add br0 type bridge
# brctl addbr br0 (deprecated)

* You need a qemu-ifup script containing the following (run as root):
#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
# tunctl -u `whoami` -t $1 (use ip tuntap instead!)
ip tuntap add $1 mode tap user `whoami`
ip link set $1 up
sleep 0.5s
# brctl addif $switch $1 (use ip link instead!)
ip link set $switch master $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 qemu-ifup as root, then consider using sudo
* 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 method shown here will not work with all wireless drivers as they might not support bridging.

'''Use case:'''

* You want to assign IP addresses 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 kvm as root, then the user must have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
ip
brctl (deprecated, use ip link instead)
tunctl (deprecated, use ip tuntap instead)

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

'''Solution 1: Using Distribution-Specific Scripts'''
{|border="1"
!RedHat
!Debian
!SuSE
|-
|
* 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 an 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 Configuration'''

* You need to create a bridge, e-g:
# ip link add br0 type bridge
# brctl addbr br0 (deprecated, use ip link instead!)

* Add one of your physical interface to the bridge, e-g for eth0:
# ip link set eth0 master br0
# brctl addif br0 eth0 (deprecated, use ip link instead!)

* You need a qemu-ifup script containing the following (run as root):

#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
#tunctl -u `whoami` -t $1
ip tuntap add $1 mode tap user `whoami`
ip link set $1 up
sleep 0.5s
#brctl addif $switch $1
ip link set $1 master $switch
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 qemu-ifup as root, then consider using sudo
* Each guest on the network must have a different MAC address
* 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

== Routing with iptables ==

With this method, you can connect your guest vm to a tap device in your host. Then you can set iptables rules in your host so that it acts as a router and firewall for your guest.

Routing is done simply by setting the default route on the client to the IP address of the host, allowing IP forwarding, and setting a route to the tap device of the client on the host.

*Host-side: Allow IPv4 forwarding and add a route to the guest (could be put in a script, but the route has to be added after the guest 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

*Guest-side: Set the default gateway to the IP address of the host (make sure the host and guest IP addresses are in the same subnet):

route add default gw <ip-of-host>

*Note: If the host is not on the same subnet as the guest, then you must manually add the route to the host before you create the 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).

More information will be provided later.

== Performance ==

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

Some 10G NIC performance comparisons between VFIO passthrough and virtio are discussed in [[VFIO vs virtio]].

== 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.

How to assign devices with VT-d in KVM

2016-07-25T00:34:18Z

Ckotichas: /* VT-d device hotplug */

= How to assign devices with VT-d in KVM =

== VT-d support ==
* In order to assign devices in KVM, you'll need a system which supports VT-d, not to be confused with the VT-x support of your CPU. VT-d needs to be supported by both your motherboard chipset and your CPU.

* If you are in doubt whether your motherboard or CPU supports VT-d, the Xen VT-d wiki has some information about VT-d enabled chipsets, motherboards, and CPUs:
http://wiki.xenproject.org/wiki/VTdHowTo

* If your hardware does not have an IOMMU (known as "Intel VT-d" on Intel-based machines and "AMD I/O Virtualization Technology" on AMD-based machines), you will not be able to assign devices in KVM.

* Assigning graphics cards is not officially supported at the moment, but there has been some success passing through a secondary Radeon HD 5850 as a VM's secondary display.

== Assigning the device ==
'''1. Modify the kernel config'''
* Navigate to the kernel source code directory (usually located in /usr/src/linux) and configure the kernel:
cd /usr/src/linux
make menuconfig
* Navigate to "Bus options (PCI etc.)" and enable the following options:
Support for DMA Remapping Devices
Enable DMA Remapping Devices
PCI Stub driver
* Optionally, this can also be enabled:
Support for Interrupt Remapping
* Save the changes and exit

'''2. Build the kernel'''
make
make modules_install
make install

'''3. Reboot and verify that your system has IOMMU support'''
* AMD-based machines:
dmesg | grep AMD-Vi
...
AMD-Vi: Enabling IOMMU at 0000:00:00.2 cap 0x40
AMD-Vi: Lazy IO/TLB flushing enabled
AMD-Vi: Initialized for Passthrough Mode
...
* Intel-based machines:
dmesg | grep -e DMAR -e IOMMU
...
DMAR:DRHD base: 0x000000feb03000 flags: 0x0
IOMMU feb03000: ver 1:0 cap c9008020e30260 ecap 1000
...
Note: If you get no output, you will need to fix this before moving on. Try the following:
* Verify that your hardware supports VT-d and that it has been enabled in the BIOS.
* Check dmesg for errors suggesting that the BIOS is broken.
* CONFIG_DMAR_DEFAULT_ON is not set. Pass one of the following commands as a kernel parameter:
intel_iommu=on # Intel only
iommu=pt iommu=1 # AMD only
Note: The kernel parameter can be passed temporarily using the GRUB menu by highlighting the OS, pressing "e", and appending the parameter to the end of the line beginning with "linux".

'''4. Unbind the device from the host kernel driver (Example: PCI device 01:00.0)
'''
* Load the PCI Stub Driver if it is compiled as a module
modprobe pci_stub
lspci -n

* Locate the entry for device 01:00.0 and note the vendor and device ID (8086:10b9 in this example)
...
01:00.0 0200: 8086:10b9 (rev 06)
...

* Place this information in the following files:
echo "8086 10b9" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:01:00.0" > /sys/bus/pci/devices/0000:01:00.0/driver/unbind
echo "0000:01:00.0" > /sys/bus/pci/drivers/pci-stub/bind

'''5. Load the KVM modules'''
modprobe kvm
modprobe kvm-intel

'''6. Assign the device'''
/usr/local/bin/qemu-system-x86_64 -m 512 -boot c -net none -hda /root/ia32e_rhel5u1.img -device pci-assign,host=01:00.0

== VT-d device hotplug ==
With VT-d, KVM also supports hotplugging devices on the guest. In the guest command interface (accessible with Ctrl+Alt+2), you can use the following commands to add/remove devices on the guest:
* Add
device_add pci-assign,host=01:00.0,id=mydevice
* Remove
device_del mydevice

== Notes ==
* VT-d spec specifies that all conventional PCI devices behind a PCIe-to PCI/PCI-X bridge or conventional PCI bridge can only be collectively assigned to the same guest. PCIe devices do not have this restriction.
* If the device doesn't support MSI, and it shares IRQ with other devices, then it cannot be assigned due to host irq sharing for assigned devices is not supported. You will get warning message when you assign it. Notice this also apply to the devices which only support MSI-X.

[[Category:Docs]][[Category:HowTo]][[Category:Devices]]

How to assign devices with VT-d in KVM

2016-07-25T00:28:16Z

Ckotichas: /* Assigning the device */

= How to assign devices with VT-d in KVM =

== VT-d support ==
* In order to assign devices in KVM, you'll need a system which supports VT-d, not to be confused with the VT-x support of your CPU. VT-d needs to be supported by both your motherboard chipset and your CPU.

* If you are in doubt whether your motherboard or CPU supports VT-d, the Xen VT-d wiki has some information about VT-d enabled chipsets, motherboards, and CPUs:
http://wiki.xenproject.org/wiki/VTdHowTo

* If your hardware does not have an IOMMU (known as "Intel VT-d" on Intel-based machines and "AMD I/O Virtualization Technology" on AMD-based machines), you will not be able to assign devices in KVM.

* Assigning graphics cards is not officially supported at the moment, but there has been some success passing through a secondary Radeon HD 5850 as a VM's secondary display.

== Assigning the device ==
'''1. Modify the kernel config'''
* Navigate to the kernel source code directory (usually located in /usr/src/linux) and configure the kernel:
cd /usr/src/linux
make menuconfig
* Navigate to "Bus options (PCI etc.)" and enable the following options:
Support for DMA Remapping Devices
Enable DMA Remapping Devices
PCI Stub driver
* Optionally, this can also be enabled:
Support for Interrupt Remapping
* Save the changes and exit

'''2. Build the kernel'''
make
make modules_install
make install

'''3. Reboot and verify that your system has IOMMU support'''
* AMD-based machines:
dmesg | grep AMD-Vi
...
AMD-Vi: Enabling IOMMU at 0000:00:00.2 cap 0x40
AMD-Vi: Lazy IO/TLB flushing enabled
AMD-Vi: Initialized for Passthrough Mode
...
* Intel-based machines:
dmesg | grep -e DMAR -e IOMMU
...
DMAR:DRHD base: 0x000000feb03000 flags: 0x0
IOMMU feb03000: ver 1:0 cap c9008020e30260 ecap 1000
...
Note: If you get no output, you will need to fix this before moving on. Try the following:
* Verify that your hardware supports VT-d and that it has been enabled in the BIOS.
* Check dmesg for errors suggesting that the BIOS is broken.
* CONFIG_DMAR_DEFAULT_ON is not set. Pass one of the following commands as a kernel parameter:
intel_iommu=on # Intel only
iommu=pt iommu=1 # AMD only
Note: The kernel parameter can be passed temporarily using the GRUB menu by highlighting the OS, pressing "e", and appending the parameter to the end of the line beginning with "linux".

'''4. Unbind the device from the host kernel driver (Example: PCI device 01:00.0)
'''
* Load the PCI Stub Driver if it is compiled as a module
modprobe pci_stub
lspci -n

* Locate the entry for device 01:00.0 and note the vendor and device ID (8086:10b9 in this example)
...
01:00.0 0200: 8086:10b9 (rev 06)
...

* Place this information in the following files:
echo "8086 10b9" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:01:00.0" > /sys/bus/pci/devices/0000:01:00.0/driver/unbind
echo "0000:01:00.0" > /sys/bus/pci/drivers/pci-stub/bind

'''5. Load the KVM modules'''
modprobe kvm
modprobe kvm-intel

'''6. Assign the device'''
/usr/local/bin/qemu-system-x86_64 -m 512 -boot c -net none -hda /root/ia32e_rhel5u1.img -device pci-assign,host=01:00.0

== VT-d device hotplug ==
KVM also supports hotplug devices with VT-d to guest. In guest command interface (you can press Ctrl+Alt+2 to enter it), you can use following command to hot add/remove devices to/from guest:
* hot add:
device_add pci-assign,host=01:00.0,id=mydevice
* hot remove:
device_del mydevice

== Notes ==
* VT-d spec specifies that all conventional PCI devices behind a PCIe-to PCI/PCI-X bridge or conventional PCI bridge can only be collectively assigned to the same guest. PCIe devices do not have this restriction.
* If the device doesn't support MSI, and it shares IRQ with other devices, then it cannot be assigned due to host irq sharing for assigned devices is not supported. You will get warning message when you assign it. Notice this also apply to the devices which only support MSI-X.

[[Category:Docs]][[Category:HowTo]][[Category:Devices]]

How to assign devices with VT-d in KVM

2016-07-25T00:27:10Z

Ckotichas: /* How to assign devices with VT-d in KVM */

= How to assign devices with VT-d in KVM =

== VT-d support ==
* In order to assign devices in KVM, you'll need a system which supports VT-d, not to be confused with the VT-x support of your CPU. VT-d needs to be supported by both your motherboard chipset and your CPU.

* If you are in doubt whether your motherboard or CPU supports VT-d, the Xen VT-d wiki has some information about VT-d enabled chipsets, motherboards, and CPUs:
http://wiki.xenproject.org/wiki/VTdHowTo

* If your hardware does not have an IOMMU (known as "Intel VT-d" on Intel-based machines and "AMD I/O Virtualization Technology" on AMD-based machines), you will not be able to assign devices in KVM.

* Assigning graphics cards is not officially supported at the moment, but there has been some success passing through a secondary Radeon HD 5850 as a VM's secondary display.

== How to assign devices with VT-d in KVM ==
'''1. Modify the kernel config'''
* Navigate to the kernel source code directory (usually located in /usr/src/linux) and configure the kernel:
cd /usr/src/linux
make menuconfig
* Navigate to "Bus options (PCI etc.)" and enable the following options:
Support for DMA Remapping Devices
Enable DMA Remapping Devices
PCI Stub driver
* Optionally, this can also be enabled:
Support for Interrupt Remapping
* Save the changes and exit

'''2. Build the kernel'''
make
make modules_install
make install

'''3. Reboot and verify that your system has IOMMU support'''
* AMD-based machines:
dmesg | grep AMD-Vi
...
AMD-Vi: Enabling IOMMU at 0000:00:00.2 cap 0x40
AMD-Vi: Lazy IO/TLB flushing enabled
AMD-Vi: Initialized for Passthrough Mode
...
* Intel-based machines:
dmesg | grep -e DMAR -e IOMMU
...
DMAR:DRHD base: 0x000000feb03000 flags: 0x0
IOMMU feb03000: ver 1:0 cap c9008020e30260 ecap 1000
...
Note: If you get no output, you will need to fix this before moving on. Try the following:
* Verify that your hardware supports VT-d and that it has been enabled in the BIOS.
* Check dmesg for errors suggesting that the BIOS is broken.
* CONFIG_DMAR_DEFAULT_ON is not set. Pass one of the following commands as a kernel parameter:
intel_iommu=on # Intel only
iommu=pt iommu=1 # AMD only
Note: The kernel parameter can be passed temporarily using the GRUB menu by highlighting the OS, pressing "e", and appending the parameter to the end of the line beginning with "linux".

'''4. Unbind the device from the host kernel driver (Example: PCI device 01:00.0)
'''
* Load the PCI Stub Driver if it is compiled as a module
modprobe pci_stub
lspci -n

* Locate the entry for device 01:00.0 and note the vendor and device ID (8086:10b9 in this example)
...
01:00.0 0200: 8086:10b9 (rev 06)
...

* Place this information in the following files:
echo "8086 10b9" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:01:00.0" > /sys/bus/pci/devices/0000:01:00.0/driver/unbind
echo "0000:01:00.0" > /sys/bus/pci/drivers/pci-stub/bind

'''5. Load the KVM modules'''
modprobe kvm
modprobe kvm-intel

'''6. Assign the device'''
/usr/local/bin/qemu-system-x86_64 -m 512 -boot c -net none -hda /root/ia32e_rhel5u1.img -device pci-assign,host=01:00.0

== VT-d device hotplug ==
KVM also supports hotplug devices with VT-d to guest. In guest command interface (you can press Ctrl+Alt+2 to enter it), you can use following command to hot add/remove devices to/from guest:
* hot add:
device_add pci-assign,host=01:00.0,id=mydevice
* hot remove:
device_del mydevice

== Notes ==
* VT-d spec specifies that all conventional PCI devices behind a PCIe-to PCI/PCI-X bridge or conventional PCI bridge can only be collectively assigned to the same guest. PCIe devices do not have this restriction.
* If the device doesn't support MSI, and it shares IRQ with other devices, then it cannot be assigned due to host irq sharing for assigned devices is not supported. You will get warning message when you assign it. Notice this also apply to the devices which only support MSI-X.

[[Category:Docs]][[Category:HowTo]][[Category:Devices]]

How to assign devices with VT-d in KVM

2016-07-24T23:20:07Z

Ckotichas: /* Assigning device to guest */

= How to assign devices with VT-d in KVM =

== VT-d support ==
* In order to assign devices in KVM, you'll need a system which supports VT-d, not to be confused with the VT-x support of your CPU. VT-d needs to be supported by both your motherboard chipset and your CPU.

* If you are in doubt whether your motherboard or CPU supports VT-d, the Xen VT-d wiki has some information about VT-d enabled chipsets, motherboards, and CPUs:
http://wiki.xenproject.org/wiki/VTdHowTo

* If your hardware does not have an IOMMU (known as "Intel VT-d" on Intel-based machines and "AMD I/O Virtualization Technology" on AMD-based machines), you will not be able to assign devices in KVM.

* Assigning graphics cards is not officially supported at the moment, but there has been some success passing through a secondary Radeon HD 5850 as a VM's secondary display.

== Assigning device to guest ==
'''1. Modify the kernel config'''
* make menuconfig
* set "Bus options (PCI etc.)" -> "Support for DMA Remapping Devices" to "*"
* set "Bus options (PCI etc.)" -> "Enable DMA Remapping Devices" to "*"
* set "Bus options (PCI etc.)" -> "PCI Stub driver" to "*"
* optional setting:
set "Bus options (PCI etc.)" -> "Support for Interrupt Remapping" to "*"
* exit/save

'''2. Build the kernel'''
* make
* make modules_install
* make install

'''3. Reboot and verify that your system has IOMMU support'''
* AMD Machine
** dmesg | grep AMD-Vi
...
AMD-Vi: Enabling IOMMU at 0000:00:00.2 cap 0x40
AMD-Vi: Lazy IO/TLB flushing enabled
AMD-Vi: Initialized for Passthrough Mode
...
* Intel Machine
** dmesg | grep -e DMAR -e IOMMU
...
DMAR:DRHD base: 0x000000feb03000 flags: 0x0
IOMMU feb03000: ver 1:0 cap c9008020e30260 ecap 1000
...
* If you get no output you'll need to fix this before moving on. Check if your hardware supports VT-d and check that it has been enabled in BIOS.

'''NOTE:''' If you still get an error "No IOMMU found." Check dmesg for errors suggesting your BIOS is broken. Another possible reason:
CONFIG_DMAR_DEFAULT_ON is not set. In that case, pass "intel_iommu=on" as kernel parameter to enable it. AMD uses different kernel parameter than Intel, on AMD you will need to pass "iommu=pt iommu=1".

'''4. Unbind the device from the host kernel driver (Example: PCI device 01:00.0)
'''
* Load the PCI Stub Driver if it is compiled as a module
modprobe pci_stub
* lspci -n
* locate the entry for device 01:00.0 and note down the vendor & device ID 8086:10b9
...
01:00.0 0200: 8086:10b9 (rev 06)
...

* echo "8086 10b9" > /sys/bus/pci/drivers/pci-stub/new_id
* echo 0000:01:00.0 > /sys/bus/pci/devices/0000:01:00.0/driver/unbind
* echo 0000:01:00.0 > /sys/bus/pci/drivers/pci-stub/bind

'''5. Load the KVM modules'''
* modprobe kvm
* modprobe kvm-intel

'''6. Assign the device'''
* /usr/local/bin/qemu-system-x86_64 -m 512 -boot c -net none -hda /root/ia32e_rhel5u1.img -device pci-assign,host=01:00.0

== VT-d device hotplug ==
KVM also supports hotplug devices with VT-d to guest. In guest command interface (you can press Ctrl+Alt+2 to enter it), you can use following command to hot add/remove devices to/from guest:
* hot add:
device_add pci-assign,host=01:00.0,id=mydevice
* hot remove:
device_del mydevice

== Notes ==
* VT-d spec specifies that all conventional PCI devices behind a PCIe-to PCI/PCI-X bridge or conventional PCI bridge can only be collectively assigned to the same guest. PCIe devices do not have this restriction.
* If the device doesn't support MSI, and it shares IRQ with other devices, then it cannot be assigned due to host irq sharing for assigned devices is not supported. You will get warning message when you assign it. Notice this also apply to the devices which only support MSI-X.

[[Category:Docs]][[Category:HowTo]][[Category:Devices]]

How to assign devices with VT-d in KVM

2016-07-24T23:16:46Z

Ckotichas: /* VT-d support */

= How to assign devices with VT-d in KVM =

== VT-d support ==
* In order to assign devices in KVM, you'll need a system which supports VT-d, not to be confused with the VT-x support of your CPU. VT-d needs to be supported by both your motherboard chipset and your CPU.

* If you are in doubt whether your motherboard or CPU supports VT-d, the Xen VT-d wiki has some information about VT-d enabled chipsets, motherboards, and CPUs:
http://wiki.xenproject.org/wiki/VTdHowTo

* If your hardware does not have an IOMMU (known as "Intel VT-d" on Intel-based machines and "AMD I/O Virtualization Technology" on AMD-based machines), you will not be able to assign devices in KVM.

* Assigning graphics cards is not officially supported at the moment, but there has been some success passing through a secondary Radeon HD 5850 as a VM's secondary display.

== Assigning device to guest ==
'''1. Modifying kernel config:'''
* make menuconfig
* set "Bus options (PCI etc.)" -> "Support for DMA Remapping Devices" to "*"
* set "Bus options (PCI etc.)" -> "Enable DMA Remapping Devices" to "*"
* set "Bus options (PCI etc.)" -> "PCI Stub driver" to "*"
* optional setting:
set "Bus options (PCI etc.)" -> "Support for Interrupt Remapping" to "*"
* exit/save

'''2. build kernel:'''
* make
* make modules_install
* make install

'''3. reboot and verify that your system has IOMMU support'''
* AMD Machine
** dmesg | grep AMD-Vi
...
AMD-Vi: Enabling IOMMU at 0000:00:00.2 cap 0x40
AMD-Vi: Lazy IO/TLB flushing enabled
AMD-Vi: Initialized for Passthrough Mode
...
* Intel Machine
** dmesg | grep -e DMAR -e IOMMU
...
DMAR:DRHD base: 0x000000feb03000 flags: 0x0
IOMMU feb03000: ver 1:0 cap c9008020e30260 ecap 1000
...
* If you get no output you'll need to fix this before moving on. Check if your hardware supports VT-d and check that it has been enabled in BIOS.

'''NOTE:''' If you still get an error "No IOMMU found." Check dmesg for errors suggesting your BIOS is broken. Another possible reason:
CONFIG_DMAR_DEFAULT_ON is not set. In that case, pass "intel_iommu=on" as kernel parameter to enable it. AMD uses different kernel parameter than Intel, on AMD you need to pass "iommu=pt iommu=1".

'''4. unbind device from host kernel driver (example PCI device 01:00.0)
'''
* Load the PCI Stub Driver if it is compiled as a module
modprobe pci_stub
* lspci -n
* locate the entry for device 01:00.0 and note down the vendor & device ID 8086:10b9
...
01:00.0 0200: 8086:10b9 (rev 06)
...

* echo "8086 10b9" > /sys/bus/pci/drivers/pci-stub/new_id
* echo 0000:01:00.0 > /sys/bus/pci/devices/0000:01:00.0/driver/unbind
* echo 0000:01:00.0 > /sys/bus/pci/drivers/pci-stub/bind

'''5. load KVM modules:'''
* modprobe kvm
* modprobe kvm-intel

'''6. assign device:'''
* /usr/local/bin/qemu-system-x86_64 -m 512 -boot c -net none -hda /root/ia32e_rhel5u1.img -device pci-assign,host=01:00.0

== VT-d device hotplug ==
KVM also supports hotplug devices with VT-d to guest. In guest command interface (you can press Ctrl+Alt+2 to enter it), you can use following command to hot add/remove devices to/from guest:
* hot add:
device_add pci-assign,host=01:00.0,id=mydevice
* hot remove:
device_del mydevice

== Notes ==
* VT-d spec specifies that all conventional PCI devices behind a PCIe-to PCI/PCI-X bridge or conventional PCI bridge can only be collectively assigned to the same guest. PCIe devices do not have this restriction.
* If the device doesn't support MSI, and it shares IRQ with other devices, then it cannot be assigned due to host irq sharing for assigned devices is not supported. You will get warning message when you assign it. Notice this also apply to the devices which only support MSI-X.

[[Category:Docs]][[Category:HowTo]][[Category:Devices]]

Change cdrom

2015-12-26T01:12:28Z

Ckotichas:

Qemu provides a way to change the iso in the virtual cdrom device via the monitor interface (Ctrl+Alt+2).

QEMU 0.10.5 monitor - type 'help' for more information
(qemu)

The commands you'll want to use are '''info block''', '''eject''', and '''change'''. First we need to determine which block device is the cdrom device you are interested in. Issue the '''info block''' command and look for cdrom devices.

(qemu) info block
ide0-hd0: type=hd removable=0 file=/dev/null ro=0 drv=host_device encrypted=0
ide1-cd0: type=cdrom removable=1 locked=0 [not inserted]
floppy0: type=floppy removable=1 locked=0 [not inserted]
sd0: type=floppy removable=1 locked=0 [not inserted]

ide1-cd0 is the only cdrom device in this example and there isn't any media inserted. To change the iso, we issue the '''change''' command supplying the device name (ide1-cd0) and the path to the new iso file.

(qemu) change ide1-cd0 /tmp/dsl-4.4.10.iso
(qemu) info block
ide0-hd0: type=hd removable=0 file=/dev/null ro=0 drv=host_device encrypted=0
ide1-cd0: type=cdrom removable=1 locked=0 file=/tmp/dsl-4.4.10.iso ro=0 drv=raw encrypted=0
floppy0: type=floppy removable=1 locked=0 [not inserted]
sd0: type=floppy removable=1 locked=0 [not inserted]
(qemu)

In case you already have a cdrom in the drive you need to '''eject''' the current iso first before issuing the '''change''' command. The '''eject''' command takes the name of the cdrom block device.

(qemu) eject ide1-cd0
(qemu) info block
ide0-hd0: type=hd removable=0 file=/dev/null ro=0 drv=host_device encrypted=0
ide1-cd0: type=cdrom removable=1 locked=0 [not inserted]
floppy0: type=floppy removable=1 locked=0 [not inserted]
sd0: type=floppy removable=1 locked=0 [not inserted]
(qemu) change ide1-cd0 /tmp/fedora11.iso
(qemu) info block
ide0-hd0: type=hd removable=0 file=/dev/null ro=0 drv=host_device encrypted=0
ide1-cd0: type=cdrom removable=1 locked=0 file=/tmp/fedora11.iso ro=0 drv=raw encrypted=0
floppy0: type=floppy removable=1 locked=0 [not inserted]
sd0: type=floppy removable=1 locked=0 [not inserted]

[[Category:HowTo]][[Category:Docs]][[Category:Devices]]

Networking

2015-11-22T04:46:14Z

Ckotichas: /* User Networking */

= Configuring Guest Networking =

Guest (VM) networking in kvm is the same as in qemu, so it is possible to refer to other documentation about networking in qemu. This page will try to explain how to configure the most frequent types of networking 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, then the user needs to have rw access to /dev/kvm
* In order for the guest to be able to access the internet or a local network, the host system must be able to access these resources as well

'''Solution:'''
* Simply run your guest without specifying network parameters, which by default will create user-level (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
* The 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 an rtl8139-based network interface.
* 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 the 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, then the user needs to have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
ip
brctl
tunctl

'''Solution:'''

* You need to create a bridge, e-g:
# brctl addbr br0

* You need a qemu-ifup script containing the following (run as root):
#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
tunctl -u `whoami` -t $1
ip link set $1 up
sleep 0.5s
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 qemu-ifup as root, then consider using sudo
* 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 method shown here will not work with most (if not 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 kvm as root, then the user must have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
ip
brctl
tunctl

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

'''Solution 1: Using Distribution-Specific Scripts'''
{|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 an 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 Configuration'''

* You need to create a bridge, e-g:
# brctl addbr br0

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

* You need a qemu-ifup script containing the following (run as root):

#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
tunctl -u `whoami` -t $1
ip link set $1 up
sleep 0.5s
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 qemu-ifup as root, then consider using sudo
* Each guest on the network must have a different MAC address
* 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

== Routing with iptables ==

With this method, you can connect your guest vm to a tap device in your host. Then you can set iptables rules in your host so that it acts as a router and firewall for your guest.

Routing is done simply by setting the default route on the client to the IP address of the host, allowing IP forwarding, and setting a route to the tap device of the client on the host.

*Host-side: Allow IPv4 forwarding and add a route to the guest (could be put in a script, but the route has to be added after the guest 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

*Guest-side: Set the default gateway to the IP address of the host (make sure the host and guest IP addresses are in the same subnet):

route add default gw <ip-of-host>

*Note: If the host is not on the same subnet as the guest, then you must manually add the route to the host before you create the 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).

More information will be provided later.

== Performance ==

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

Some 10G NIC performance comparisons between VFIO passthrough and virtio are discussed in [[VFIO vs virtio]].

== 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

2015-11-22T04:42:42Z

Ckotichas: /* User Networking */

= Configuring Guest Networking =

Guest (VM) networking in kvm is the same as in qemu, so it is possible to refer to other documentation about networking in qemu. This page will try to explain how to configure the most frequent types of networking 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, then the user 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-level (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
* The 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 an rtl8139-based network interface.
* 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 the 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, then the user needs to have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
ip
brctl
tunctl

'''Solution:'''

* You need to create a bridge, e-g:
# brctl addbr br0

* You need a qemu-ifup script containing the following (run as root):
#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
tunctl -u `whoami` -t $1
ip link set $1 up
sleep 0.5s
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 qemu-ifup as root, then consider using sudo
* 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 method shown here will not work with most (if not 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 kvm as root, then the user must have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
ip
brctl
tunctl

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

'''Solution 1: Using Distribution-Specific Scripts'''
{|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 an 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 Configuration'''

* You need to create a bridge, e-g:
# brctl addbr br0

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

* You need a qemu-ifup script containing the following (run as root):

#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
tunctl -u `whoami` -t $1
ip link set $1 up
sleep 0.5s
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 qemu-ifup as root, then consider using sudo
* Each guest on the network must have a different MAC address
* 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

== Routing with iptables ==

With this method, you can connect your guest vm to a tap device in your host. Then you can set iptables rules in your host so that it acts as a router and firewall for your guest.

Routing is done simply by setting the default route on the client to the IP address of the host, allowing IP forwarding, and setting a route to the tap device of the client on the host.

*Host-side: Allow IPv4 forwarding and add a route to the guest (could be put in a script, but the route has to be added after the guest 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

*Guest-side: Set the default gateway to the IP address of the host (make sure the host and guest IP addresses are in the same subnet):

route add default gw <ip-of-host>

*Note: If the host is not on the same subnet as the guest, then you must manually add the route to the host before you create the 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).

More information will be provided later.

== Performance ==

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

Some 10G NIC performance comparisons between VFIO passthrough and virtio are discussed in [[VFIO vs virtio]].

== 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

2015-11-22T04:37:31Z

Ckotichas: /* VDE */

= Configuring Guest Networking =

Guest (VM) networking in kvm is the same as in qemu, so it is possible to refer to other documentation about networking in qemu. This page will try to explain how to configure the most frequent types of networking 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, then the user 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-level (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
* The 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 the 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, then the user needs to have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
ip
brctl
tunctl

'''Solution:'''

* You need to create a bridge, e-g:
# brctl addbr br0

* You need a qemu-ifup script containing the following (run as root):
#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
tunctl -u `whoami` -t $1
ip link set $1 up
sleep 0.5s
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 qemu-ifup as root, then consider using sudo
* 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 method shown here will not work with most (if not 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 kvm as root, then the user must have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
ip
brctl
tunctl

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

'''Solution 1: Using Distribution-Specific Scripts'''
{|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 an 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 Configuration'''

* You need to create a bridge, e-g:
# brctl addbr br0

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

* You need a qemu-ifup script containing the following (run as root):

#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
tunctl -u `whoami` -t $1
ip link set $1 up
sleep 0.5s
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 qemu-ifup as root, then consider using sudo
* Each guest on the network must have a different MAC address
* 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

== Routing with iptables ==

With this method, you can connect your guest vm to a tap device in your host. Then you can set iptables rules in your host so that it acts as a router and firewall for your guest.

Routing is done simply by setting the default route on the client to the IP address of the host, allowing IP forwarding, and setting a route to the tap device of the client on the host.

*Host-side: Allow IPv4 forwarding and add a route to the guest (could be put in a script, but the route has to be added after the guest 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

*Guest-side: Set the default gateway to the IP address of the host (make sure the host and guest IP addresses are in the same subnet):

route add default gw <ip-of-host>

*Note: If the host is not on the same subnet as the guest, then you must manually add the route to the host before you create the 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).

More information will be provided later.

== Performance ==

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

Some 10G NIC performance comparisons between VFIO passthrough and virtio are discussed in [[VFIO vs virtio]].

== 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

2015-11-22T04:33:26Z

Ckotichas: /* Routing with iptables */

= Configuring Guest Networking =

Guest (VM) networking in kvm is the same as in qemu, so it is possible to refer to other documentation about networking in qemu. This page will try to explain how to configure the most frequent types of networking 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, then the user 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-level (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
* The 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 the 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, then the user needs to have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
ip
brctl
tunctl

'''Solution:'''

* You need to create a bridge, e-g:
# brctl addbr br0

* You need a qemu-ifup script containing the following (run as root):
#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
tunctl -u `whoami` -t $1
ip link set $1 up
sleep 0.5s
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 qemu-ifup as root, then consider using sudo
* 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 method shown here will not work with most (if not 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 kvm as root, then the user must have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
ip
brctl
tunctl

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

'''Solution 1: Using Distribution-Specific Scripts'''
{|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 an 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 Configuration'''

* You need to create a bridge, e-g:
# brctl addbr br0

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

* You need a qemu-ifup script containing the following (run as root):

#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
tunctl -u `whoami` -t $1
ip link set $1 up
sleep 0.5s
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 qemu-ifup as root, then consider using sudo
* Each guest on the network must have a different MAC address
* 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

== Routing with iptables ==

With this method, you can connect your guest vm to a tap device in your host. Then you can set iptables rules in your host so that it acts as a router and firewall for your guest.

Routing is done simply by setting the default route on the client to the IP address of the host, allowing IP forwarding, and setting a route to the tap device of the client on the host.

*Host-side: Allow IPv4 forwarding and add a route to the guest (could be put in a script, but the route has to be added after the guest 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

*Guest-side: Set the default gateway to the IP address of the host (make sure the host and guest IP addresses are in the same subnet):

route add default gw <ip-of-host>

*Note: If the host is not on the same subnet as the guest, then you must manually add the route to the host before you create the 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]].

Some 10G NIC performance comparisons between VFIO passthrough and virtio are discussed in [[VFIO vs virtio]].

== 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

2015-11-22T04:30:08Z

Ckotichas: /* Routing with iptables */

= Configuring Guest Networking =

Guest (VM) networking in kvm is the same as in qemu, so it is possible to refer to other documentation about networking in qemu. This page will try to explain how to configure the most frequent types of networking 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, then the user 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-level (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
* The 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 the 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, then the user needs to have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
ip
brctl
tunctl

'''Solution:'''

* You need to create a bridge, e-g:
# brctl addbr br0

* You need a qemu-ifup script containing the following (run as root):
#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
tunctl -u `whoami` -t $1
ip link set $1 up
sleep 0.5s
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 qemu-ifup as root, then consider using sudo
* 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 method shown here will not work with most (if not 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 kvm as root, then the user must have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
ip
brctl
tunctl

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

'''Solution 1: Using Distribution-Specific Scripts'''
{|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 an 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 Configuration'''

* You need to create a bridge, e-g:
# brctl addbr br0

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

* You need a qemu-ifup script containing the following (run as root):

#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
tunctl -u `whoami` -t $1
ip link set $1 up
sleep 0.5s
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 qemu-ifup as root, then consider using sudo
* Each guest on the network must have a different MAC address
* 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

== Routing with iptables ==

With this method, you can connect your guest vm to a tap device in your host. Then you can set iptables rules in your host so that it acts as a router and firewall for your guest.

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

Test the setup beforehand:

*Host-side: Allow IPv4 forwarding and add a route to the guest (could be put in a script, but the route has to be added after the guest 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

*Guest-side: Set the default gateway to the IP address of the host (make sure the host and guest IP addresses are in the same subnet):

route add default gw <ip-of-host>

*Note: If the host is not on the same subnet as the guest, then you must manually add the route to the host before you create the 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]].

Some 10G NIC performance comparisons between VFIO passthrough and virtio are discussed in [[VFIO vs virtio]].

== 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

2015-11-22T04:15:20Z

Ckotichas: /* Configuring Guest Networking */

= Configuring Guest Networking =

Guest (VM) networking in kvm is the same as in qemu, so it is possible to refer to other documentation about networking in qemu. This page will try to explain how to configure the most frequent types of networking 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, then the user 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-level (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
* The 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 the 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, then the user needs to have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
ip
brctl
tunctl

'''Solution:'''

* You need to create a bridge, e-g:
# brctl addbr br0

* You need a qemu-ifup script containing the following (run as root):
#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
tunctl -u `whoami` -t $1
ip link set $1 up
sleep 0.5s
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 qemu-ifup as root, then consider using sudo
* 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 method shown here will not work with most (if not 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 kvm as root, then the user must have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
ip
brctl
tunctl

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

'''Solution 1: Using Distribution-Specific Scripts'''
{|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 an 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 Configuration'''

* You need to create a bridge, e-g:
# brctl addbr br0

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

* You need a qemu-ifup script containing the following (run as root):

#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
tunctl -u `whoami` -t $1
ip link set $1 up
sleep 0.5s
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 qemu-ifup as root, then consider using sudo
* Each guest on the network must have a different MAC address
* 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

== 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]].

Some 10G NIC performance comparisons between VFIO passthrough and virtio are discussed in [[VFIO vs virtio]].

== 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

2015-11-22T04:12:42Z

Ckotichas: /* Public 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, then the user 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-level (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
* The 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 the 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, then the user needs to have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
ip
brctl
tunctl

'''Solution:'''

* You need to create a bridge, e-g:
# brctl addbr br0

* You need a qemu-ifup script containing the following (run as root):
#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
tunctl -u `whoami` -t $1
ip link set $1 up
sleep 0.5s
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 qemu-ifup as root, then consider using sudo
* 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 method shown here will not work with most (if not 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 kvm as root, then the user must have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
ip
brctl
tunctl

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

'''Solution 1: Using Distribution-Specific Scripts'''
{|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 an 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 Configuration'''

* You need to create a bridge, e-g:
# brctl addbr br0

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

* You need a qemu-ifup script containing the following (run as root):

#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
tunctl -u `whoami` -t $1
ip link set $1 up
sleep 0.5s
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 qemu-ifup as root, then consider using sudo
* Each guest on the network must have a different MAC address
* 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

== 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]].

Some 10G NIC performance comparisons between VFIO passthrough and virtio are discussed in [[VFIO vs virtio]].

== 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

2015-11-22T04:06:19Z

Ckotichas: /* Private Virtual 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, then the user 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-level (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
* The 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 the 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, then the user needs to have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
ip
brctl
tunctl

'''Solution:'''

* You need to create a bridge, e-g:
# brctl addbr br0

* You need a qemu-ifup script containing the following (run as root):
#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
tunctl -u `whoami` -t $1
ip link set $1 up
sleep 0.5s
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 qemu-ifup as root, then consider using sudo
* 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 method shown here will not work with most (if not 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 kvm as root, then the user must have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
/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 Distribution-Specific Scripts'''
{|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 an 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 Configuration'''

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

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

* You need a qemu-ifup script containing the following (run as root):

#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
/usr/sbin/tunctl -u `whoami` -t $1
/sbin/ip link set $1 up
sleep 0.5s
/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
* Each guest on the network must have a different MAC address
* 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

== 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]].

Some 10G NIC performance comparisons between VFIO passthrough and virtio are discussed in [[VFIO vs virtio]].

== 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

2015-11-22T03:57:27Z

Ckotichas: /* User Networking */

= 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, then the user 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-level (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
* The 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 the 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, then the user 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 method shown here will not work with most (if not 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 kvm as root, then the user must have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
/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 Distribution-Specific Scripts'''
{|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 an 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 Configuration'''

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

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

* You need a qemu-ifup script containing the following (run as root):

#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
/usr/sbin/tunctl -u `whoami` -t $1
/sbin/ip link set $1 up
sleep 0.5s
/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
* Each guest on the network must have a different MAC address
* 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

== 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]].

Some 10G NIC performance comparisons between VFIO passthrough and virtio are discussed in [[VFIO vs virtio]].

== 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

2015-11-22T03:53:55Z

Ckotichas: /* Performance */

= 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-level (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
* The 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 the 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, then the user 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 method shown here will not work with most (if not 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 kvm as root, then the user must have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
/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 Distribution-Specific Scripts'''
{|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 an 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 Configuration'''

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

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

* You need a qemu-ifup script containing the following (run as root):

#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
/usr/sbin/tunctl -u `whoami` -t $1
/sbin/ip link set $1 up
sleep 0.5s
/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
* Each guest on the network must have a different MAC address
* 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

== 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]].

Some 10G NIC performance comparisons between VFIO passthrough and virtio are discussed in [[VFIO vs virtio]].

== 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

2015-11-22T03:52:23Z

Ckotichas: /* Performance */

= 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-level (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
* The 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 the 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, then the user 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 method shown here will not work with most (if not 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 kvm as root, then the user must have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
/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 Distribution-Specific Scripts'''
{|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 an 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 Configuration'''

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

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

* You need a qemu-ifup script containing the following (run as root):

#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
/usr/sbin/tunctl -u `whoami` -t $1
/sbin/ip link set $1 up
sleep 0.5s
/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
* Each guest on the network must have a different MAC address
* 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

== 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]].

Some 10G NIC performance comparisons between VFIO passthrough and virtio [[VFIO vs virtio]]

== 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

2015-11-22T03:51:01Z

Ckotichas: /* User Networking */

= 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-level (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
* The 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 the 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, then the user 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 method shown here will not work with most (if not 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 kvm as root, then the user must have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
/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 Distribution-Specific Scripts'''
{|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 an 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 Configuration'''

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

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

* You need a qemu-ifup script containing the following (run as root):

#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
/usr/sbin/tunctl -u `whoami` -t $1
/sbin/ip link set $1 up
sleep 0.5s
/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
* Each guest on the network must have a different MAC address
* 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

== 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]].

Some 10G NIC performance comparison between VFIO passthrough and virtio [[VFIO vs virtio]]

== 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

2015-11-22T03:45:13Z

Ckotichas: /* Public 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

'''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, then the user 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 method shown here will not work with most (if not 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 kvm as root, then the user must have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
/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 Distribution-Specific Scripts'''
{|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 an 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 Configuration'''

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

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

* You need a qemu-ifup script containing the following (run as root):

#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
/usr/sbin/tunctl -u `whoami` -t $1
/sbin/ip link set $1 up
sleep 0.5s
/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
* Each guest on the network must have a different MAC address
* 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

== 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]].

Some 10G NIC performance comparison between VFIO passthrough and virtio [[VFIO vs virtio]]

== 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

2015-11-22T03:41:55Z

Ckotichas: /* Public 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

'''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, then the user 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 method shown here will not work with most (if not 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 kvm as root, then the user must have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
/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 Distribution-Specific Scripts'''
{|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 an 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 Configuration'''

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

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

* You need a qemu-ifup script containing the following (run as root):

#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
/usr/sbin/tunctl -u `whoami` -t $1
/sbin/ip link set $1 up
sleep 0.5s
/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]].

Some 10G NIC performance comparison between VFIO passthrough and virtio [[VFIO vs virtio]]

== 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

2015-11-22T03:40:48Z

Ckotichas: /* Private Virtual 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

'''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, then the user 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 method shown here will not work with most (if not 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 kvm as root, then the user must have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
/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 Distribution-Specific Scripts'''
{|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 an 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 Configuration'''

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

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

* You need a qemu-ifup script containing the following (run as root):

#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
/usr/sbin/tunctl -u `whoami` -t $1
/sbin/ip link set $1 up
sleep 0.5s
/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]].

Some 10G NIC performance comparison between VFIO passthrough and virtio [[VFIO vs virtio]]

== 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

2015-11-22T03:38:44Z

Ckotichas: /* public 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

'''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 method shown here will not work with most (if not 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 kvm as root, then the user must have rw access to /dev/kvm
* The following commands must be installed on the host system and executed as root:
/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 Distribution-Specific Scripts'''
{|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 an 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 Configuration'''

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

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

* You need a qemu-ifup script containing the following (run as root):

#!/bin/sh
set -x

switch=br0

if [ -n "$1" ];then
/usr/sbin/tunctl -u `whoami` -t $1
/sbin/ip link set $1 up
sleep 0.5s
/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]].

Some 10G NIC performance comparison between VFIO passthrough and virtio [[VFIO vs virtio]]

== 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.

FAQ

2015-11-08T20:03:43Z

Ckotichas: /* When connecting to a VNC terminal, a "rect too big" message appears and the VNC session disconnects */

=FAQ=
__TOC__
== Preparing to use KVM ==
=== What do I need to use KVM? ===
You will need an x86 machine running a recent Linux kernel on an Intel processor with VT (virtualization technology) extensions, or an AMD processor with SVM extensions (also called AMD-V). Xen has a [http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors complete list] of compatible processors. For Intel processors, see also [http://ark.intel.com/VTList.aspx the Intel® Virtualization Technology List].

----------
=== Are 64-bit processors supported under KVM? ===
Yes they are supported and will allow you to run 32-bit and 64-bit guests.

See also '''Can KVM run a 32-bit guest on a 64-bit host? What about PAE?''' below.

----------

=== What is Intel VT / AMD-V / hvm? ===
[http://www.intel.com/technology/itj/2006/v10i3/1-hardware/6-vt-x-vt-i-solutions.htm Intel VT] and [http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_8826_14287,00.html AMD's AMD-V] are instruction set extensions that provide hardware assistance to virtual machine monitors. They enable running fully isolated virtual machines at native hardware speeds, for some workloads.

HVM (for Hardware Virtual Machine) is a vendor-neutral term often used to designate the x86 instruction set extensions.

----------

=== Where do I get my kvm kernel modules from? ===

See the [[Getting the kvm kernel modules]] page.

----------

=== How can I tell if I have Intel VT or AMD-V? ===
With a recent enough Linux kernel, run the command:

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

If something shows up, you have VT. You can also check the processor model name (in `/proc/cpuinfo`) in the vendor's web site.

Note:

* You'll never see (vmx|svm) in /proc/cpuinfo if you're currently running in in a dom0 or domU. The Xen hypervisor suppresses these flags in order to prevent hijacking.
* Some manufacturers disable VT in the machine's BIOS, in such a way that it cannot be re-enabled.
* `/proc/cpuinfo` only shows virtualization capabilities starting with Linux 2.6.15 (Intel) and Linux 2.6.16 (AMD). Use the `uname -r` command to query your kernel version.
In case of doubt, contact your hardware vendor.

----------

=== "KVM: disabled by BIOS" error ===
Check if there is an option to enable it in the BIOS. If not, look for a more recent BIOS on the vendor's web site.

Note:

* On some hardware (e-g HP nx6320), you need to power-off/power-on the machine after enabling virtualization in the BIOS.
* Enabling some BIOS features may break VT support on some hardware (e-g Enabling Intel AMT on a Thinkpad T500 will prevent kvm-intel from loading with "disabled by bios")
* On some Dell hardware, you also need to disable "Trusted Execution", otherwise VT will not be enabled.

----------

=== How can I use AMD-V extension? ===
modprobe kvm-amd

----------

=== What user space tools does KVM use? ===
KVM uses a slightly modified [http://www.nongnu.org/qemu QEMU] program to instantiate the virtual machine. Once running, a virtual machine is just a regular process. You can use `top(1), kill(1), taskset(1)` and similar tools to manage virtual machines.

----------

=== What virtual disk formats can KVM use? ===
KVM inherits a wealth of disk formats support from QEMU; it supports raw images, the native QEMU format (qcow2), VMware format, and many more.

----------

=== How do I use KVM on a headless machine (without a local GUI?) ===
Install a management tool such as virt-manager on a remote machine.

----------

=== Are there management tools available to help me manage my virtual machines? ===
Yes. Please see the [[Management Tools]] page for some links.

----------

== Using KVM ==
=== How can I use KVM with a non-privileged user? ===
The cleanest way is probably to create a group, say ''kvm'', and add the user(s) to that group. Then you will need change /dev/kvm to owned by group ''kvm''.

On a system that runs udev, you will probably need to add the following line somewhere in your udev configuration so it will automatically give the right group to the newly created device (i-e for ubuntu add a line to ''/etc/udev/rules.d/40-permissions.rules'').

KERNEL=="kvm", GROUP="kvm"

----------

=== How can I get the most performance out of KVM? ===

See the [[Tuning KVM]] page.

----------

=== Is KVM stable? ===
KVM is stable and used in production. As with most open source projects, development snapshots are less stable than the stable release series.

If your name is Andreas Mohr, you're reporting bugs in the wrong place.
----------

=== That's alright, but can I really use it for my daily use? ===
Sure. We continuously run the most often-used OSes and configurations and if anything breaks for the developers, it's fixed as soon as it was broken. See the [[Guest Support Status]] and [[Host Support Status]] pages to find out more. Please update them with success stories so that new users would benefit from the experience of the community.

----------

=== How about production use? ===
For production use, it's recommended you use the KVM modules shipped by the distribution you're using to ensure stability. As mentioned above, it's tempting to use new features, but you never know of (unwanted) surprises hidden away. It'll be best if you can run the development snapshots with non-critical production load, so that the latest releases are stable for you when you decide to deploy them.

----------

=== What happens if I kill -9 a VM process? ===
From the guest's perspective, it is as if you yanked the power cord out. From the host's perspective, the process is killed and all resources it uses are reclaimed.

----------

=== I need help to setup the network for my guest ===
You can have a look to the [[Networking]] page of this wiki for informations on the most classical networking setup for the guests. You can also refer to the QEMU documentation.

----------

=== Where can I find more documention... ===
Most usability issues are covered in the QEMU [http://www.nongnu.org/qemu/user-doc.html documentation]. There is also an extensive [http://qemu-buch.de/cgi-bin/moin.cgi/FrequentlyAskedQuestions FAQ] (old vanished link: [http://kidsquid.com/cgi-bin/moin.cgi/FrequentlyAskedQuestions FAQ]).

----------

== Troubleshooting ==
=== How can I check that I'm not falling back to QEMU with no hardware acceleration? ===

If you think that you might not be using the hardware acceleration provided by the KVM module, here are a few steps to help you check this.

First of all, check that you don't have messages such as:

qemu-system-x86_64 -hda myvm.qcow2
open /dev/kvm: No such file or directory
Could not initialize KVM, will disable KVM support

In that case, you can check that:
* the modules are correctly loaded <code>lsmod|grep kvm
* you don't have a "KVM: disabled by BIOS" line in the output of dmesg
* /dev/kvm exists and you have the correct rights to use it

Other ways to do the diagnostic:
* if you have access to the QEMU monitor (Ctrl-Alt-2, use Ctrl-Alt-1 to get back to the VM display), enter the "info kvm" command and it should respond with "KVM support: enabled"
* the right-end columns of the output from <code>lsmod|grep kvm</code> on the host system, once the VM is started should show only non zero values. The value on the line corresponding to the architecture specific module (e-g kvm_intel, kvm_amd) show the number of VM using the module. For instance, if I have 2 VM running using the KVM module on a machine with vt, it will report:

lsmod|grep kvm
kvm_intel 44896 2
kvm 159656 1 kvm_intel

=== When connecting to a VNC terminal, a "rect too big" message appears and the VNC session disconnects ===
This happens because of a VNC protocol flaw on the way on-the-fly pixel format changes are handled (more info at [http://www.mail-archive.com/qemu-devel@nongnu.org/msg04879.html this thread]). If you are using TigerVNC, you can avoid this problem by disabling on-the-fly selection of pixel encoding, using the <tt>-AutoSelect=0</tt> command-line option of vncviewer. You may also want to check the encoding options on the vncviewer man page, as this will disable automatic selection of encoding based on connection speed.

----------
'''How do I set up the network such that my guest is accessible from other machines?''' or

=== My guest network is stuck what should I do? ===
KVM uses QEMU for its device emulation. Consult the [http://qemu-project.org/Documentation/Networking QEMU network wiki page] for detailed network setup instructions.

One would probably be interested in the Root Networking Mode page and the Network Bridge page.

Guest-side network lockups (fortunately restartable) may be happening due to tun/tap bridging erroneous MAC address reconfiguration on host side, see RHEL bug #571991 and others.

----------

=== I'm experiencing timer drift issues in my VM guests, what to do? ===

Especially in case of networked systems (e.g. via NFS or Samba) it is very important to ensure stable operation of timing (both system timer and RTC).
Tell-tale signs of related trouble in VMs (apparently qemu/KVM/VMWare etc. are all affected) are e.g.
"make[2]: Warning: File `XXXXX/cmakelists_rebuilder.stamp' has modification time 0.37 s in the future"
"Clock skew detected. Your build may be incomplete."

[http://maemovmware.garage.maemo.org/2nd_edition/requirements_documentation.html Maemo docs] state that it's important to disable UTC and set the correct time zone, however I don't really see how that would help in case of diverging host/guest clocks.
IMHO much more useful and important is to configure properly working NTP server (chrony recommended, or ntpd) on both host and guest.
The single most decisive trick IMHO is to specify the '''host''' NTP server as the main entry within guest VM instead of "foreign" NTP servers, to make sure to achieve the most precise coupling between these two related systems (timing drift vs. other systems does not matter nearly as much as a tight time precision for inner host/guest system interaction e.g. in the case of NFS/Samba shares etc.).
For verification, see chronyc "sources -v", "tracking" ("System time" row) commands.

After having applied this very tight NTP coupling, this seems to finally have gotten rid of make's time drift warnings.

Perhaps qemu's -tdf (timing drift fix) option magically manages to help in your case, too.

See also [https://espace.cern.ch/it-faqs/Lists/faqs/DispForm.aspx?ID=368 Faqs: I received a message about "clock skew"].

----------
=== I get "rtc interrupts lost" messages, and the guest is very slow? ===
Try setting <code>CONFIG_HPET_EMULATE_RTC=y</code> in your host <code>.config</code>.

----------

=== I get an "Exception 13" or "Exception 12" message while booting a guest OS on my Intel host ===
See the [[Intel Real Mode Emulation Problems]] page.

----------

=== I have VMware/Parallels/VirtualBox installed and when I modprobe KVM, my system deadlocks. ===
Neither Intel VT nor AMD-V provide a mechanism to determine whether software is currently using the hardware virtualization extensions. This means that if you have two kernel modules loaded attempting to use hardware virtualization extensions, very bad things will happen. If you are using another type of virtualization software and experience any sort of weirdness with KVM, make sure you can reproduce the problem without the kernel modules for that software loaded before you report a bug in KVM.

----------

=== There's nothing on QEMU/KVM screen, but it's not hanged! I'm trying to install Kubuntu. ===
Try to run kvm with -std-vga option. It helps if guest operating system uses framebuffer mode like Kubuntu/Ubuntu.

----------

=== When I click the guest operating system window, mouse is grabbed. How can I get mouse to not to do that? OR Mouse doesn't show up / doesn't work in the guest. What do I do? ===
From #qemu wiki, try to run kvm/qemu with

-usb -usbdevice tablet
If that doesn't work, try this:

$ export SDL_VIDEO_X11_DGAMOUSE=0
(from http://wiki.clug.org.za/wiki/QEMU_mouse_not_working )

----------

== General KVM information ==
=== What is the difference between KVM and Xen? ===
Xen is an external hypervisor; it assumes control of the machine and divides resources among guests. On the other hand, KVM is part of Linux and uses the regular Linux scheduler and memory management. This means that KVM is much smaller and simpler to use; it is also more featureful; for example KVM can swap guests to disk in order to free RAM.

KVM only run on processors that supports x86 hvm (vt/svm instructions set) whereas Xen also allows running modified operating systems on non-hvm x86 processors using a technique called paravirtualization. KVM does not support paravirtualization for CPU but may support paravirtualization for device drivers to improve I/O performance.

----------

=== What is the difference between KVM and VMware? ===
VMware is a proprietary product. KVM is Free Software released under the GPL.

----------

=== What is the difference between KVM and QEMU? ===
QEMU uses emulation; KVM uses processor extensions (HVM) for virtualization.

----------

=== Do you have a port of KVM for Windows? ===
Not officially.

Kazushi Takahashi has been working on an experimental version though, called WinKVM, available [http://github.com/ddk50/winkvm here].

----------

=== What kernel version does it work with? ===
It depends on what version of KVM you are using. The last release of KVM should work with any recent kernel (2.6.17 and above), older releases even older kernels.

----------

=== How much RAM do I need? ===
You will need enough memory to let the guest run comfortably while keeping enough for the host. 1GB is probably a minimum configuration for the host OS.

----------

=== Is dynamic memory management for guests supported? ===
This is a broad topic covering a few areas.

A. KVM only allocates memory as the guest tries to use it. Once it's allocated, KVM keeps it. Some guests (namely Microsoft guests) zero all memory at boot time. So they will use all memory.

B. Certain guests (only Linux at the moment) have a balloon driver, so the host can have the guest allocate a certain amount of memory which the guest won't be able to use anymore and it can then be freed on the host. Ballooning is controlled in the host via the [http://www.nongnu.org/qemu/qemu-doc.html#SEC12 balloon monitor command].

C. Some hosts (presently only RHEL5.4 / CentOS 5.4) have a feature called KSM (Kernel Sharedpage Merging), which collapses together identical pages; this requires kernel support on the host, as well as a kvm new enough to opt in to the behavior. As some guest platforms (most notably Windows) zero out free'd memory, such pages are trivially collapsed. The ksmctl command needs to be used to enable KSM; alternately, the ksmtuned service found in Fedora 12 can be run to dynamically adjust KSM's aggressiveness based on the amount of free memory available

----------

=== What OSs can I run inside KVM VM? ===
Several. See the [[Guest Support Status]] page for details. Note that several Linux flavors are known to hang on Intel processors during startup. Workaround is to disable splash screens in grub.

----------

=== Does KVM support a live migration feature to move virtual machines from one host to another without downtime? ===
Yes. See the [[Migration]] page for details.

----------

=== Does KVM support live migration from an AMD host to an Intel host and back? ===
Yes. There may be issues on 32-bit Intel hosts which don't support NX (or XD), but for 64-bit hosts back and forth migration should work well. Migration of 32-bit guests should work between 32-bit hosts and 64-bit hosts.
If one of your hosts does not support NX, you may consider disabling NX when starting the guest on a NX-capable system. You can do it by passing "-cpu qemu64,-nx" parameter to the guest.

----------

=== Can KVM run a 32-bit guest on a 64-bit host? What about PAE? ===
KVM supports 32-bit guests on 64-bit hosts, and any combination of PAE and non-PAE guests and hosts. The only unsupported combination is a 64-bit guest on a 32-bit host.

If you are running a Windows Virtual Machine and have problems enabling PAE in your guest see the [[Windows PAE Workaround]] page.

----------

=== Is it possible to use a host's USB devices within a guest? ===
Yes, this method is described in detail [http://www.linux-kvm.org/page/USB_Host_Device_Assigned_to_Guest here].

----------

=== Can I have higher or widescreen resolutions (eg 1680 x 1050) in KVM? ===
Use the -vga std parameter while starting the VM to allow high resolution and widescreen displays.

If the resolution you want to use is not available, you can patch the corresponding source files (see http://article.gmane.org/gmane.comp.emulators.kvm.devel/13557 as a reference), or send a mail to the KVM mailing list if you are not able to patch the source yourself.

When using Windows as guest OS and not having issues with people violating the GPL you might want to use the driver from the VBEMP x86 project (http://www.bearwindows.boot-land.net/vbemp.htm) which is based on ReactOS code.

----------

=== Does KVM support SMP hosts? ===
Yes.

----------

=== Does KVM support SMP guests? ===
Yes. Up to 16 CPUs can be specified using the -smp option.

----------

=== Is the name 'KVM' trademarked? ===
No.

----------

=== I compiled a new kernel for my KVM client and the ethernet interface is not recognized ===
You can specify alternative network interfaces to qemu with the ''-net nic,model='' parameter. For example, ''-net nic,model=rtl8139'' would enable a device with the Realtek 8139 chipset.

----------

=== I can't ping from guest to host or vice versa. How can I access the host? ===
The ping command may not go through in this circumstance, but you may be able to access the host in another way. For example, you can access a host running Apache by entering its IP address into a browser within the guest.

----------

[[Category:Docs]][[Category:HowTo]]

FAQ

2015-11-08T20:01:57Z

Ckotichas: /* When connecting to a VNC Terminal, a "rect too big" message appears and the VNC Session disconnects */

=FAQ=
__TOC__
== Preparing to use KVM ==
=== What do I need to use KVM? ===
You will need an x86 machine running a recent Linux kernel on an Intel processor with VT (virtualization technology) extensions, or an AMD processor with SVM extensions (also called AMD-V). Xen has a [http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors complete list] of compatible processors. For Intel processors, see also [http://ark.intel.com/VTList.aspx the Intel® Virtualization Technology List].

----------
=== Are 64-bit processors supported under KVM? ===
Yes they are supported and will allow you to run 32-bit and 64-bit guests.

See also '''Can KVM run a 32-bit guest on a 64-bit host? What about PAE?''' below.

----------

=== What is Intel VT / AMD-V / hvm? ===
[http://www.intel.com/technology/itj/2006/v10i3/1-hardware/6-vt-x-vt-i-solutions.htm Intel VT] and [http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_8826_14287,00.html AMD's AMD-V] are instruction set extensions that provide hardware assistance to virtual machine monitors. They enable running fully isolated virtual machines at native hardware speeds, for some workloads.

HVM (for Hardware Virtual Machine) is a vendor-neutral term often used to designate the x86 instruction set extensions.

----------

=== Where do I get my kvm kernel modules from? ===

See the [[Getting the kvm kernel modules]] page.

----------

=== How can I tell if I have Intel VT or AMD-V? ===
With a recent enough Linux kernel, run the command:

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

If something shows up, you have VT. You can also check the processor model name (in `/proc/cpuinfo`) in the vendor's web site.

Note:

* You'll never see (vmx|svm) in /proc/cpuinfo if you're currently running in in a dom0 or domU. The Xen hypervisor suppresses these flags in order to prevent hijacking.
* Some manufacturers disable VT in the machine's BIOS, in such a way that it cannot be re-enabled.
* `/proc/cpuinfo` only shows virtualization capabilities starting with Linux 2.6.15 (Intel) and Linux 2.6.16 (AMD). Use the `uname -r` command to query your kernel version.
In case of doubt, contact your hardware vendor.

----------

=== "KVM: disabled by BIOS" error ===
Check if there is an option to enable it in the BIOS. If not, look for a more recent BIOS on the vendor's web site.

Note:

* On some hardware (e-g HP nx6320), you need to power-off/power-on the machine after enabling virtualization in the BIOS.
* Enabling some BIOS features may break VT support on some hardware (e-g Enabling Intel AMT on a Thinkpad T500 will prevent kvm-intel from loading with "disabled by bios")
* On some Dell hardware, you also need to disable "Trusted Execution", otherwise VT will not be enabled.

----------

=== How can I use AMD-V extension? ===
modprobe kvm-amd

----------

=== What user space tools does KVM use? ===
KVM uses a slightly modified [http://www.nongnu.org/qemu QEMU] program to instantiate the virtual machine. Once running, a virtual machine is just a regular process. You can use `top(1), kill(1), taskset(1)` and similar tools to manage virtual machines.

----------

=== What virtual disk formats can KVM use? ===
KVM inherits a wealth of disk formats support from QEMU; it supports raw images, the native QEMU format (qcow2), VMware format, and many more.

----------

=== How do I use KVM on a headless machine (without a local GUI?) ===
Install a management tool such as virt-manager on a remote machine.

----------

=== Are there management tools available to help me manage my virtual machines? ===
Yes. Please see the [[Management Tools]] page for some links.

----------

== Using KVM ==
=== How can I use KVM with a non-privileged user? ===
The cleanest way is probably to create a group, say ''kvm'', and add the user(s) to that group. Then you will need change /dev/kvm to owned by group ''kvm''.

On a system that runs udev, you will probably need to add the following line somewhere in your udev configuration so it will automatically give the right group to the newly created device (i-e for ubuntu add a line to ''/etc/udev/rules.d/40-permissions.rules'').

KERNEL=="kvm", GROUP="kvm"

----------

=== How can I get the most performance out of KVM? ===

See the [[Tuning KVM]] page.

----------

=== Is KVM stable? ===
KVM is stable and used in production. As with most open source projects, development snapshots are less stable than the stable release series.

If your name is Andreas Mohr, you're reporting bugs in the wrong place.
----------

=== That's alright, but can I really use it for my daily use? ===
Sure. We continuously run the most often-used OSes and configurations and if anything breaks for the developers, it's fixed as soon as it was broken. See the [[Guest Support Status]] and [[Host Support Status]] pages to find out more. Please update them with success stories so that new users would benefit from the experience of the community.

----------

=== How about production use? ===
For production use, it's recommended you use the KVM modules shipped by the distribution you're using to ensure stability. As mentioned above, it's tempting to use new features, but you never know of (unwanted) surprises hidden away. It'll be best if you can run the development snapshots with non-critical production load, so that the latest releases are stable for you when you decide to deploy them.

----------

=== What happens if I kill -9 a VM process? ===
From the guest's perspective, it is as if you yanked the power cord out. From the host's perspective, the process is killed and all resources it uses are reclaimed.

----------

=== I need help to setup the network for my guest ===
You can have a look to the [[Networking]] page of this wiki for informations on the most classical networking setup for the guests. You can also refer to the QEMU documentation.

----------

=== Where can I find more documention... ===
Most usability issues are covered in the QEMU [http://www.nongnu.org/qemu/user-doc.html documentation]. There is also an extensive [http://qemu-buch.de/cgi-bin/moin.cgi/FrequentlyAskedQuestions FAQ] (old vanished link: [http://kidsquid.com/cgi-bin/moin.cgi/FrequentlyAskedQuestions FAQ]).

----------

== Troubleshooting ==
=== How can I check that I'm not falling back to QEMU with no hardware acceleration? ===

If you think that you might not be using the hardware acceleration provided by the KVM module, here are a few steps to help you check this.

First of all, check that you don't have messages such as:

qemu-system-x86_64 -hda myvm.qcow2
open /dev/kvm: No such file or directory
Could not initialize KVM, will disable KVM support

In that case, you can check that:
* the modules are correctly loaded <code>lsmod|grep kvm
* you don't have a "KVM: disabled by BIOS" line in the output of dmesg
* /dev/kvm exists and you have the correct rights to use it

Other ways to do the diagnostic:
* if you have access to the QEMU monitor (Ctrl-Alt-2, use Ctrl-Alt-1 to get back to the VM display), enter the "info kvm" command and it should respond with "KVM support: enabled"
* the right-end columns of the output from <code>lsmod|grep kvm</code> on the host system, once the VM is started should show only non zero values. The value on the line corresponding to the architecture specific module (e-g kvm_intel, kvm_amd) show the number of VM using the module. For instance, if I have 2 VM running using the KVM module on a machine with vt, it will report:

lsmod|grep kvm
kvm_intel 44896 2
kvm 159656 1 kvm_intel

=== When connecting to a VNC Terminal, a "rect too big" message appears and the VNC Session disconnects ===
This happens because of a VNC protocol flaw on the way on-the-fly pixel format changes are handled (more info at [http://www.mail-archive.com/qemu-devel@nongnu.org/msg04879.html this thread]). If you are using TigerVNC, you can avoid this problem by disabling on-the-fly selection of pixel encoding, using the <tt>-AutoSelect=0</tt> command-line option of vncviewer. You may also want to check the encoding options on the vncviewer man page, as this will disable automatic selection of encoding based on connection speed.

----------
'''How do I set up the network such that my guest is accessible from other machines?''' or

=== My guest network is stuck what should I do? ===
KVM uses QEMU for its device emulation. Consult the [http://qemu-project.org/Documentation/Networking QEMU network wiki page] for detailed network setup instructions.

One would probably be interested in the Root Networking Mode page and the Network Bridge page.

Guest-side network lockups (fortunately restartable) may be happening due to tun/tap bridging erroneous MAC address reconfiguration on host side, see RHEL bug #571991 and others.

----------

=== I'm experiencing timer drift issues in my VM guests, what to do? ===

Especially in case of networked systems (e.g. via NFS or Samba) it is very important to ensure stable operation of timing (both system timer and RTC).
Tell-tale signs of related trouble in VMs (apparently qemu/KVM/VMWare etc. are all affected) are e.g.
"make[2]: Warning: File `XXXXX/cmakelists_rebuilder.stamp' has modification time 0.37 s in the future"
"Clock skew detected. Your build may be incomplete."

[http://maemovmware.garage.maemo.org/2nd_edition/requirements_documentation.html Maemo docs] state that it's important to disable UTC and set the correct time zone, however I don't really see how that would help in case of diverging host/guest clocks.
IMHO much more useful and important is to configure properly working NTP server (chrony recommended, or ntpd) on both host and guest.
The single most decisive trick IMHO is to specify the '''host''' NTP server as the main entry within guest VM instead of "foreign" NTP servers, to make sure to achieve the most precise coupling between these two related systems (timing drift vs. other systems does not matter nearly as much as a tight time precision for inner host/guest system interaction e.g. in the case of NFS/Samba shares etc.).
For verification, see chronyc "sources -v", "tracking" ("System time" row) commands.

After having applied this very tight NTP coupling, this seems to finally have gotten rid of make's time drift warnings.

Perhaps qemu's -tdf (timing drift fix) option magically manages to help in your case, too.

See also [https://espace.cern.ch/it-faqs/Lists/faqs/DispForm.aspx?ID=368 Faqs: I received a message about "clock skew"].

----------
=== I get "rtc interrupts lost" messages, and the guest is very slow? ===
Try setting <code>CONFIG_HPET_EMULATE_RTC=y</code> in your host <code>.config</code>.

----------

=== I get an "Exception 13" or "Exception 12" message while booting a guest OS on my Intel host ===
See the [[Intel Real Mode Emulation Problems]] page.

----------

=== I have VMware/Parallels/VirtualBox installed and when I modprobe KVM, my system deadlocks. ===
Neither Intel VT nor AMD-V provide a mechanism to determine whether software is currently using the hardware virtualization extensions. This means that if you have two kernel modules loaded attempting to use hardware virtualization extensions, very bad things will happen. If you are using another type of virtualization software and experience any sort of weirdness with KVM, make sure you can reproduce the problem without the kernel modules for that software loaded before you report a bug in KVM.

----------

=== There's nothing on QEMU/KVM screen, but it's not hanged! I'm trying to install Kubuntu. ===
Try to run kvm with -std-vga option. It helps if guest operating system uses framebuffer mode like Kubuntu/Ubuntu.

----------

=== When I click the guest operating system window, mouse is grabbed. How can I get mouse to not to do that? OR Mouse doesn't show up / doesn't work in the guest. What do I do? ===
From #qemu wiki, try to run kvm/qemu with

-usb -usbdevice tablet
If that doesn't work, try this:

$ export SDL_VIDEO_X11_DGAMOUSE=0
(from http://wiki.clug.org.za/wiki/QEMU_mouse_not_working )

----------

== General KVM information ==
=== What is the difference between KVM and Xen? ===
Xen is an external hypervisor; it assumes control of the machine and divides resources among guests. On the other hand, KVM is part of Linux and uses the regular Linux scheduler and memory management. This means that KVM is much smaller and simpler to use; it is also more featureful; for example KVM can swap guests to disk in order to free RAM.

KVM only run on processors that supports x86 hvm (vt/svm instructions set) whereas Xen also allows running modified operating systems on non-hvm x86 processors using a technique called paravirtualization. KVM does not support paravirtualization for CPU but may support paravirtualization for device drivers to improve I/O performance.

----------

=== What is the difference between KVM and VMware? ===
VMware is a proprietary product. KVM is Free Software released under the GPL.

----------

=== What is the difference between KVM and QEMU? ===
QEMU uses emulation; KVM uses processor extensions (HVM) for virtualization.

----------

=== Do you have a port of KVM for Windows? ===
Not officially.

Kazushi Takahashi has been working on an experimental version though, called WinKVM, available [http://github.com/ddk50/winkvm here].

----------

=== What kernel version does it work with? ===
It depends on what version of KVM you are using. The last release of KVM should work with any recent kernel (2.6.17 and above), older releases even older kernels.

----------

=== How much RAM do I need? ===
You will need enough memory to let the guest run comfortably while keeping enough for the host. 1GB is probably a minimum configuration for the host OS.

----------

=== Is dynamic memory management for guests supported? ===
This is a broad topic covering a few areas.

A. KVM only allocates memory as the guest tries to use it. Once it's allocated, KVM keeps it. Some guests (namely Microsoft guests) zero all memory at boot time. So they will use all memory.

B. Certain guests (only Linux at the moment) have a balloon driver, so the host can have the guest allocate a certain amount of memory which the guest won't be able to use anymore and it can then be freed on the host. Ballooning is controlled in the host via the [http://www.nongnu.org/qemu/qemu-doc.html#SEC12 balloon monitor command].

C. Some hosts (presently only RHEL5.4 / CentOS 5.4) have a feature called KSM (Kernel Sharedpage Merging), which collapses together identical pages; this requires kernel support on the host, as well as a kvm new enough to opt in to the behavior. As some guest platforms (most notably Windows) zero out free'd memory, such pages are trivially collapsed. The ksmctl command needs to be used to enable KSM; alternately, the ksmtuned service found in Fedora 12 can be run to dynamically adjust KSM's aggressiveness based on the amount of free memory available

----------

=== What OSs can I run inside KVM VM? ===
Several. See the [[Guest Support Status]] page for details. Note that several Linux flavors are known to hang on Intel processors during startup. Workaround is to disable splash screens in grub.

----------

=== Does KVM support a live migration feature to move virtual machines from one host to another without downtime? ===
Yes. See the [[Migration]] page for details.

----------

=== Does KVM support live migration from an AMD host to an Intel host and back? ===
Yes. There may be issues on 32-bit Intel hosts which don't support NX (or XD), but for 64-bit hosts back and forth migration should work well. Migration of 32-bit guests should work between 32-bit hosts and 64-bit hosts.
If one of your hosts does not support NX, you may consider disabling NX when starting the guest on a NX-capable system. You can do it by passing "-cpu qemu64,-nx" parameter to the guest.

----------

=== Can KVM run a 32-bit guest on a 64-bit host? What about PAE? ===
KVM supports 32-bit guests on 64-bit hosts, and any combination of PAE and non-PAE guests and hosts. The only unsupported combination is a 64-bit guest on a 32-bit host.

If you are running a Windows Virtual Machine and have problems enabling PAE in your guest see the [[Windows PAE Workaround]] page.

----------

=== Is it possible to use a host's USB devices within a guest? ===
Yes, this method is described in detail [http://www.linux-kvm.org/page/USB_Host_Device_Assigned_to_Guest here].

----------

=== Can I have higher or widescreen resolutions (eg 1680 x 1050) in KVM? ===
Use the -vga std parameter while starting the VM to allow high resolution and widescreen displays.

If the resolution you want to use is not available, you can patch the corresponding source files (see http://article.gmane.org/gmane.comp.emulators.kvm.devel/13557 as a reference), or send a mail to the KVM mailing list if you are not able to patch the source yourself.

When using Windows as guest OS and not having issues with people violating the GPL you might want to use the driver from the VBEMP x86 project (http://www.bearwindows.boot-land.net/vbemp.htm) which is based on ReactOS code.

----------

=== Does KVM support SMP hosts? ===
Yes.

----------

=== Does KVM support SMP guests? ===
Yes. Up to 16 CPUs can be specified using the -smp option.

----------

=== Is the name 'KVM' trademarked? ===
No.

----------

=== I compiled a new kernel for my KVM client and the ethernet interface is not recognized ===
You can specify alternative network interfaces to qemu with the ''-net nic,model='' parameter. For example, ''-net nic,model=rtl8139'' would enable a device with the Realtek 8139 chipset.

----------

=== I can't ping from guest to host or vice versa. How can I access the host? ===
The ping command may not go through in this circumstance, but you may be able to access the host in another way. For example, you can access a host running Apache by entering its IP address into a browser within the guest.

----------

[[Category:Docs]][[Category:HowTo]]

FAQ

2015-11-08T19:57:46Z

Ckotichas: /* Is it possible to use a host's USB devices within a guest? */

=FAQ=
__TOC__
== Preparing to use KVM ==
=== What do I need to use KVM? ===
You will need an x86 machine running a recent Linux kernel on an Intel processor with VT (virtualization technology) extensions, or an AMD processor with SVM extensions (also called AMD-V). Xen has a [http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors complete list] of compatible processors. For Intel processors, see also [http://ark.intel.com/VTList.aspx the Intel® Virtualization Technology List].

----------
=== Are 64-bit processors supported under KVM? ===
Yes they are supported and will allow you to run 32-bit and 64-bit guests.

See also '''Can KVM run a 32-bit guest on a 64-bit host? What about PAE?''' below.

----------

=== What is Intel VT / AMD-V / hvm? ===
[http://www.intel.com/technology/itj/2006/v10i3/1-hardware/6-vt-x-vt-i-solutions.htm Intel VT] and [http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_8826_14287,00.html AMD's AMD-V] are instruction set extensions that provide hardware assistance to virtual machine monitors. They enable running fully isolated virtual machines at native hardware speeds, for some workloads.

HVM (for Hardware Virtual Machine) is a vendor-neutral term often used to designate the x86 instruction set extensions.

----------

=== Where do I get my kvm kernel modules from? ===

See the [[Getting the kvm kernel modules]] page.

----------

=== How can I tell if I have Intel VT or AMD-V? ===
With a recent enough Linux kernel, run the command:

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

If something shows up, you have VT. You can also check the processor model name (in `/proc/cpuinfo`) in the vendor's web site.

Note:

* You'll never see (vmx|svm) in /proc/cpuinfo if you're currently running in in a dom0 or domU. The Xen hypervisor suppresses these flags in order to prevent hijacking.
* Some manufacturers disable VT in the machine's BIOS, in such a way that it cannot be re-enabled.
* `/proc/cpuinfo` only shows virtualization capabilities starting with Linux 2.6.15 (Intel) and Linux 2.6.16 (AMD). Use the `uname -r` command to query your kernel version.
In case of doubt, contact your hardware vendor.

----------

=== "KVM: disabled by BIOS" error ===
Check if there is an option to enable it in the BIOS. If not, look for a more recent BIOS on the vendor's web site.

Note:

* On some hardware (e-g HP nx6320), you need to power-off/power-on the machine after enabling virtualization in the BIOS.
* Enabling some BIOS features may break VT support on some hardware (e-g Enabling Intel AMT on a Thinkpad T500 will prevent kvm-intel from loading with "disabled by bios")
* On some Dell hardware, you also need to disable "Trusted Execution", otherwise VT will not be enabled.

----------

=== How can I use AMD-V extension? ===
modprobe kvm-amd

----------

=== What user space tools does KVM use? ===
KVM uses a slightly modified [http://www.nongnu.org/qemu QEMU] program to instantiate the virtual machine. Once running, a virtual machine is just a regular process. You can use `top(1), kill(1), taskset(1)` and similar tools to manage virtual machines.

----------

=== What virtual disk formats can KVM use? ===
KVM inherits a wealth of disk formats support from QEMU; it supports raw images, the native QEMU format (qcow2), VMware format, and many more.

----------

=== How do I use KVM on a headless machine (without a local GUI?) ===
Install a management tool such as virt-manager on a remote machine.

----------

=== Are there management tools available to help me manage my virtual machines? ===
Yes. Please see the [[Management Tools]] page for some links.

----------

== Using KVM ==
=== How can I use KVM with a non-privileged user? ===
The cleanest way is probably to create a group, say ''kvm'', and add the user(s) to that group. Then you will need change /dev/kvm to owned by group ''kvm''.

On a system that runs udev, you will probably need to add the following line somewhere in your udev configuration so it will automatically give the right group to the newly created device (i-e for ubuntu add a line to ''/etc/udev/rules.d/40-permissions.rules'').

KERNEL=="kvm", GROUP="kvm"

----------

=== How can I get the most performance out of KVM? ===

See the [[Tuning KVM]] page.

----------

=== Is KVM stable? ===
KVM is stable and used in production. As with most open source projects, development snapshots are less stable than the stable release series.

If your name is Andreas Mohr, you're reporting bugs in the wrong place.
----------

=== That's alright, but can I really use it for my daily use? ===
Sure. We continuously run the most often-used OSes and configurations and if anything breaks for the developers, it's fixed as soon as it was broken. See the [[Guest Support Status]] and [[Host Support Status]] pages to find out more. Please update them with success stories so that new users would benefit from the experience of the community.

----------

=== How about production use? ===
For production use, it's recommended you use the KVM modules shipped by the distribution you're using to ensure stability. As mentioned above, it's tempting to use new features, but you never know of (unwanted) surprises hidden away. It'll be best if you can run the development snapshots with non-critical production load, so that the latest releases are stable for you when you decide to deploy them.

----------

=== What happens if I kill -9 a VM process? ===
From the guest's perspective, it is as if you yanked the power cord out. From the host's perspective, the process is killed and all resources it uses are reclaimed.

----------

=== I need help to setup the network for my guest ===
You can have a look to the [[Networking]] page of this wiki for informations on the most classical networking setup for the guests. You can also refer to the QEMU documentation.

----------

=== Where can I find more documention... ===
Most usability issues are covered in the QEMU [http://www.nongnu.org/qemu/user-doc.html documentation]. There is also an extensive [http://qemu-buch.de/cgi-bin/moin.cgi/FrequentlyAskedQuestions FAQ] (old vanished link: [http://kidsquid.com/cgi-bin/moin.cgi/FrequentlyAskedQuestions FAQ]).

----------

== Troubleshooting ==
=== How can I check that I'm not falling back to QEMU with no hardware acceleration? ===

If you think that you might not be using the hardware acceleration provided by the KVM module, here are a few steps to help you check this.

First of all, check that you don't have messages such as:

qemu-system-x86_64 -hda myvm.qcow2
open /dev/kvm: No such file or directory
Could not initialize KVM, will disable KVM support

In that case, you can check that:
* the modules are correctly loaded <code>lsmod|grep kvm
* you don't have a "KVM: disabled by BIOS" line in the output of dmesg
* /dev/kvm exists and you have the correct rights to use it

Other ways to do the diagnostic:
* if you have access to the QEMU monitor (Ctrl-Alt-2, use Ctrl-Alt-1 to get back to the VM display), enter the "info kvm" command and it should respond with "KVM support: enabled"
* the right-end columns of the output from <code>lsmod|grep kvm</code> on the host system, once the VM is started should show only non zero values. The value on the line corresponding to the architecture specific module (e-g kvm_intel, kvm_amd) show the number of VM using the module. For instance, if I have 2 VM running using the KVM module on a machine with vt, it will report:

lsmod|grep kvm
kvm_intel 44896 2
kvm 159656 1 kvm_intel

=== "rect too big" Message when using VNC Display ===
When connection to a VNC Terminal, a "rect too big" message appears, and the VNC Session disconnects.

This happens because of a VNC protocol flaw on the way on-the-fly pixel format changes are handled (more info at [http://www.mail-archive.com/qemu-devel@nongnu.org/msg04879.html this thread]). If you are using TigerVNC, you can avoid this problem by disabling on-the-fly selection of pixel encoding, using the <tt>-AutoSelect=0</tt> command-line option of vncviewer. You may also want to check the encoding options on the vncviewer man page, as this will disable automatic selection of encoding based on connection speed.

----------
'''How do I set up the network such that my guest is accessible from other machines?''' or

=== My guest network is stuck what should I do? ===
KVM uses QEMU for its device emulation. Consult the [http://qemu-project.org/Documentation/Networking QEMU network wiki page] for detailed network setup instructions.

One would probably be interested in the Root Networking Mode page and the Network Bridge page.

Guest-side network lockups (fortunately restartable) may be happening due to tun/tap bridging erroneous MAC address reconfiguration on host side, see RHEL bug #571991 and others.

----------

=== I'm experiencing timer drift issues in my VM guests, what to do? ===

Especially in case of networked systems (e.g. via NFS or Samba) it is very important to ensure stable operation of timing (both system timer and RTC).
Tell-tale signs of related trouble in VMs (apparently qemu/KVM/VMWare etc. are all affected) are e.g.
"make[2]: Warning: File `XXXXX/cmakelists_rebuilder.stamp' has modification time 0.37 s in the future"
"Clock skew detected. Your build may be incomplete."

[http://maemovmware.garage.maemo.org/2nd_edition/requirements_documentation.html Maemo docs] state that it's important to disable UTC and set the correct time zone, however I don't really see how that would help in case of diverging host/guest clocks.
IMHO much more useful and important is to configure properly working NTP server (chrony recommended, or ntpd) on both host and guest.
The single most decisive trick IMHO is to specify the '''host''' NTP server as the main entry within guest VM instead of "foreign" NTP servers, to make sure to achieve the most precise coupling between these two related systems (timing drift vs. other systems does not matter nearly as much as a tight time precision for inner host/guest system interaction e.g. in the case of NFS/Samba shares etc.).
For verification, see chronyc "sources -v", "tracking" ("System time" row) commands.

After having applied this very tight NTP coupling, this seems to finally have gotten rid of make's time drift warnings.

Perhaps qemu's -tdf (timing drift fix) option magically manages to help in your case, too.

See also [https://espace.cern.ch/it-faqs/Lists/faqs/DispForm.aspx?ID=368 Faqs: I received a message about "clock skew"].

----------
=== I get "rtc interrupts lost" messages, and the guest is very slow? ===
Try setting <code>CONFIG_HPET_EMULATE_RTC=y</code> in your host <code>.config</code>.

----------

=== I get an "Exception 13" or "Exception 12" message while booting a guest OS on my Intel host ===
See the [[Intel Real Mode Emulation Problems]] page.

----------

=== I have VMware/Parallels/VirtualBox installed and when I modprobe KVM, my system deadlocks. ===
Neither Intel VT nor AMD-V provide a mechanism to determine whether software is currently using the hardware virtualization extensions. This means that if you have two kernel modules loaded attempting to use hardware virtualization extensions, very bad things will happen. If you are using another type of virtualization software and experience any sort of weirdness with KVM, make sure you can reproduce the problem without the kernel modules for that software loaded before you report a bug in KVM.

----------

=== There's nothing on QEMU/KVM screen, but it's not hanged! I'm trying to install Kubuntu. ===
Try to run kvm with -std-vga option. It helps if guest operating system uses framebuffer mode like Kubuntu/Ubuntu.

----------

=== When I click the guest operating system window, mouse is grabbed. How can I get mouse to not to do that? OR Mouse doesn't show up / doesn't work in the guest. What do I do? ===
From #qemu wiki, try to run kvm/qemu with

-usb -usbdevice tablet
If that doesn't work, try this:

$ export SDL_VIDEO_X11_DGAMOUSE=0
(from http://wiki.clug.org.za/wiki/QEMU_mouse_not_working )

----------

== General KVM information ==
=== What is the difference between KVM and Xen? ===
Xen is an external hypervisor; it assumes control of the machine and divides resources among guests. On the other hand, KVM is part of Linux and uses the regular Linux scheduler and memory management. This means that KVM is much smaller and simpler to use; it is also more featureful; for example KVM can swap guests to disk in order to free RAM.

KVM only run on processors that supports x86 hvm (vt/svm instructions set) whereas Xen also allows running modified operating systems on non-hvm x86 processors using a technique called paravirtualization. KVM does not support paravirtualization for CPU but may support paravirtualization for device drivers to improve I/O performance.

----------

=== What is the difference between KVM and VMware? ===
VMware is a proprietary product. KVM is Free Software released under the GPL.

----------

=== What is the difference between KVM and QEMU? ===
QEMU uses emulation; KVM uses processor extensions (HVM) for virtualization.

----------

=== Do you have a port of KVM for Windows? ===
Not officially.

Kazushi Takahashi has been working on an experimental version though, called WinKVM, available [http://github.com/ddk50/winkvm here].

----------

=== What kernel version does it work with? ===
It depends on what version of KVM you are using. The last release of KVM should work with any recent kernel (2.6.17 and above), older releases even older kernels.

----------

=== How much RAM do I need? ===
You will need enough memory to let the guest run comfortably while keeping enough for the host. 1GB is probably a minimum configuration for the host OS.

----------

=== Is dynamic memory management for guests supported? ===
This is a broad topic covering a few areas.

A. KVM only allocates memory as the guest tries to use it. Once it's allocated, KVM keeps it. Some guests (namely Microsoft guests) zero all memory at boot time. So they will use all memory.

B. Certain guests (only Linux at the moment) have a balloon driver, so the host can have the guest allocate a certain amount of memory which the guest won't be able to use anymore and it can then be freed on the host. Ballooning is controlled in the host via the [http://www.nongnu.org/qemu/qemu-doc.html#SEC12 balloon monitor command].

C. Some hosts (presently only RHEL5.4 / CentOS 5.4) have a feature called KSM (Kernel Sharedpage Merging), which collapses together identical pages; this requires kernel support on the host, as well as a kvm new enough to opt in to the behavior. As some guest platforms (most notably Windows) zero out free'd memory, such pages are trivially collapsed. The ksmctl command needs to be used to enable KSM; alternately, the ksmtuned service found in Fedora 12 can be run to dynamically adjust KSM's aggressiveness based on the amount of free memory available

----------

=== What OSs can I run inside KVM VM? ===
Several. See the [[Guest Support Status]] page for details. Note that several Linux flavors are known to hang on Intel processors during startup. Workaround is to disable splash screens in grub.

----------

=== Does KVM support a live migration feature to move virtual machines from one host to another without downtime? ===
Yes. See the [[Migration]] page for details.

----------

=== Does KVM support live migration from an AMD host to an Intel host and back? ===
Yes. There may be issues on 32-bit Intel hosts which don't support NX (or XD), but for 64-bit hosts back and forth migration should work well. Migration of 32-bit guests should work between 32-bit hosts and 64-bit hosts.
If one of your hosts does not support NX, you may consider disabling NX when starting the guest on a NX-capable system. You can do it by passing "-cpu qemu64,-nx" parameter to the guest.

----------

=== Can KVM run a 32-bit guest on a 64-bit host? What about PAE? ===
KVM supports 32-bit guests on 64-bit hosts, and any combination of PAE and non-PAE guests and hosts. The only unsupported combination is a 64-bit guest on a 32-bit host.

If you are running a Windows Virtual Machine and have problems enabling PAE in your guest see the [[Windows PAE Workaround]] page.

----------

=== Is it possible to use a host's USB devices within a guest? ===
Yes, this method is described in detail [http://www.linux-kvm.org/page/USB_Host_Device_Assigned_to_Guest here].

----------

=== Can I have higher or widescreen resolutions (eg 1680 x 1050) in KVM? ===
Use the -vga std parameter while starting the VM to allow high resolution and widescreen displays.

If the resolution you want to use is not available, you can patch the corresponding source files (see http://article.gmane.org/gmane.comp.emulators.kvm.devel/13557 as a reference), or send a mail to the KVM mailing list if you are not able to patch the source yourself.

When using Windows as guest OS and not having issues with people violating the GPL you might want to use the driver from the VBEMP x86 project (http://www.bearwindows.boot-land.net/vbemp.htm) which is based on ReactOS code.

----------

=== Does KVM support SMP hosts? ===
Yes.

----------

=== Does KVM support SMP guests? ===
Yes. Up to 16 CPUs can be specified using the -smp option.

----------

=== Is the name 'KVM' trademarked? ===
No.

----------

=== I compiled a new kernel for my KVM client and the ethernet interface is not recognized ===
You can specify alternative network interfaces to qemu with the ''-net nic,model='' parameter. For example, ''-net nic,model=rtl8139'' would enable a device with the Realtek 8139 chipset.

----------

=== I can't ping from guest to host or vice versa. How can I access the host? ===
The ping command may not go through in this circumstance, but you may be able to access the host in another way. For example, you can access a host running Apache by entering its IP address into a browser within the guest.

----------

[[Category:Docs]][[Category:HowTo]]

FAQ

2015-11-08T19:51:50Z

Ckotichas: /* I compiled a new kernel for my KVM client and the ethernet interface is not recognized */

=FAQ=
__TOC__
== Preparing to use KVM ==
=== What do I need to use KVM? ===
You will need an x86 machine running a recent Linux kernel on an Intel processor with VT (virtualization technology) extensions, or an AMD processor with SVM extensions (also called AMD-V). Xen has a [http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors complete list] of compatible processors. For Intel processors, see also [http://ark.intel.com/VTList.aspx the Intel® Virtualization Technology List].

----------
=== Are 64-bit processors supported under KVM? ===
Yes they are supported and will allow you to run 32-bit and 64-bit guests.

See also '''Can KVM run a 32-bit guest on a 64-bit host? What about PAE?''' below.

----------

=== What is Intel VT / AMD-V / hvm? ===
[http://www.intel.com/technology/itj/2006/v10i3/1-hardware/6-vt-x-vt-i-solutions.htm Intel VT] and [http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_8826_14287,00.html AMD's AMD-V] are instruction set extensions that provide hardware assistance to virtual machine monitors. They enable running fully isolated virtual machines at native hardware speeds, for some workloads.

HVM (for Hardware Virtual Machine) is a vendor-neutral term often used to designate the x86 instruction set extensions.

----------

=== Where do I get my kvm kernel modules from? ===

See the [[Getting the kvm kernel modules]] page.

----------

=== How can I tell if I have Intel VT or AMD-V? ===
With a recent enough Linux kernel, run the command:

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

If something shows up, you have VT. You can also check the processor model name (in `/proc/cpuinfo`) in the vendor's web site.

Note:

* You'll never see (vmx|svm) in /proc/cpuinfo if you're currently running in in a dom0 or domU. The Xen hypervisor suppresses these flags in order to prevent hijacking.
* Some manufacturers disable VT in the machine's BIOS, in such a way that it cannot be re-enabled.
* `/proc/cpuinfo` only shows virtualization capabilities starting with Linux 2.6.15 (Intel) and Linux 2.6.16 (AMD). Use the `uname -r` command to query your kernel version.
In case of doubt, contact your hardware vendor.

----------

=== "KVM: disabled by BIOS" error ===
Check if there is an option to enable it in the BIOS. If not, look for a more recent BIOS on the vendor's web site.

Note:

* On some hardware (e-g HP nx6320), you need to power-off/power-on the machine after enabling virtualization in the BIOS.
* Enabling some BIOS features may break VT support on some hardware (e-g Enabling Intel AMT on a Thinkpad T500 will prevent kvm-intel from loading with "disabled by bios")
* On some Dell hardware, you also need to disable "Trusted Execution", otherwise VT will not be enabled.

----------

=== How can I use AMD-V extension? ===
modprobe kvm-amd

----------

=== What user space tools does KVM use? ===
KVM uses a slightly modified [http://www.nongnu.org/qemu QEMU] program to instantiate the virtual machine. Once running, a virtual machine is just a regular process. You can use `top(1), kill(1), taskset(1)` and similar tools to manage virtual machines.

----------

=== What virtual disk formats can KVM use? ===
KVM inherits a wealth of disk formats support from QEMU; it supports raw images, the native QEMU format (qcow2), VMware format, and many more.

----------

=== How do I use KVM on a headless machine (without a local GUI?) ===
Install a management tool such as virt-manager on a remote machine.

----------

=== Are there management tools available to help me manage my virtual machines? ===
Yes. Please see the [[Management Tools]] page for some links.

----------

== Using KVM ==
=== How can I use KVM with a non-privileged user? ===
The cleanest way is probably to create a group, say ''kvm'', and add the user(s) to that group. Then you will need change /dev/kvm to owned by group ''kvm''.

On a system that runs udev, you will probably need to add the following line somewhere in your udev configuration so it will automatically give the right group to the newly created device (i-e for ubuntu add a line to ''/etc/udev/rules.d/40-permissions.rules'').

KERNEL=="kvm", GROUP="kvm"

----------

=== How can I get the most performance out of KVM? ===

See the [[Tuning KVM]] page.

----------

=== Is KVM stable? ===
KVM is stable and used in production. As with most open source projects, development snapshots are less stable than the stable release series.

If your name is Andreas Mohr, you're reporting bugs in the wrong place.
----------

=== That's alright, but can I really use it for my daily use? ===
Sure. We continuously run the most often-used OSes and configurations and if anything breaks for the developers, it's fixed as soon as it was broken. See the [[Guest Support Status]] and [[Host Support Status]] pages to find out more. Please update them with success stories so that new users would benefit from the experience of the community.

----------

=== How about production use? ===
For production use, it's recommended you use the KVM modules shipped by the distribution you're using to ensure stability. As mentioned above, it's tempting to use new features, but you never know of (unwanted) surprises hidden away. It'll be best if you can run the development snapshots with non-critical production load, so that the latest releases are stable for you when you decide to deploy them.

----------

=== What happens if I kill -9 a VM process? ===
From the guest's perspective, it is as if you yanked the power cord out. From the host's perspective, the process is killed and all resources it uses are reclaimed.

----------

=== I need help to setup the network for my guest ===
You can have a look to the [[Networking]] page of this wiki for informations on the most classical networking setup for the guests. You can also refer to the QEMU documentation.

----------

=== Where can I find more documention... ===
Most usability issues are covered in the QEMU [http://www.nongnu.org/qemu/user-doc.html documentation]. There is also an extensive [http://qemu-buch.de/cgi-bin/moin.cgi/FrequentlyAskedQuestions FAQ] (old vanished link: [http://kidsquid.com/cgi-bin/moin.cgi/FrequentlyAskedQuestions FAQ]).

----------

== Troubleshooting ==
=== How can I check that I'm not falling back to QEMU with no hardware acceleration? ===

If you think that you might not be using the hardware acceleration provided by the KVM module, here are a few steps to help you check this.

First of all, check that you don't have messages such as:

qemu-system-x86_64 -hda myvm.qcow2
open /dev/kvm: No such file or directory
Could not initialize KVM, will disable KVM support

In that case, you can check that:
* the modules are correctly loaded <code>lsmod|grep kvm
* you don't have a "KVM: disabled by BIOS" line in the output of dmesg
* /dev/kvm exists and you have the correct rights to use it

Other ways to do the diagnostic:
* if you have access to the QEMU monitor (Ctrl-Alt-2, use Ctrl-Alt-1 to get back to the VM display), enter the "info kvm" command and it should respond with "KVM support: enabled"
* the right-end columns of the output from <code>lsmod|grep kvm</code> on the host system, once the VM is started should show only non zero values. The value on the line corresponding to the architecture specific module (e-g kvm_intel, kvm_amd) show the number of VM using the module. For instance, if I have 2 VM running using the KVM module on a machine with vt, it will report:

lsmod|grep kvm
kvm_intel 44896 2
kvm 159656 1 kvm_intel

=== "rect too big" Message when using VNC Display ===
When connection to a VNC Terminal, a "rect too big" message appears, and the VNC Session disconnects.

This happens because of a VNC protocol flaw on the way on-the-fly pixel format changes are handled (more info at [http://www.mail-archive.com/qemu-devel@nongnu.org/msg04879.html this thread]). If you are using TigerVNC, you can avoid this problem by disabling on-the-fly selection of pixel encoding, using the <tt>-AutoSelect=0</tt> command-line option of vncviewer. You may also want to check the encoding options on the vncviewer man page, as this will disable automatic selection of encoding based on connection speed.

----------
'''How do I set up the network such that my guest is accessible from other machines?''' or

=== My guest network is stuck what should I do? ===
KVM uses QEMU for its device emulation. Consult the [http://qemu-project.org/Documentation/Networking QEMU network wiki page] for detailed network setup instructions.

One would probably be interested in the Root Networking Mode page and the Network Bridge page.

Guest-side network lockups (fortunately restartable) may be happening due to tun/tap bridging erroneous MAC address reconfiguration on host side, see RHEL bug #571991 and others.

----------

=== I'm experiencing timer drift issues in my VM guests, what to do? ===

Especially in case of networked systems (e.g. via NFS or Samba) it is very important to ensure stable operation of timing (both system timer and RTC).
Tell-tale signs of related trouble in VMs (apparently qemu/KVM/VMWare etc. are all affected) are e.g.
"make[2]: Warning: File `XXXXX/cmakelists_rebuilder.stamp' has modification time 0.37 s in the future"
"Clock skew detected. Your build may be incomplete."

[http://maemovmware.garage.maemo.org/2nd_edition/requirements_documentation.html Maemo docs] state that it's important to disable UTC and set the correct time zone, however I don't really see how that would help in case of diverging host/guest clocks.
IMHO much more useful and important is to configure properly working NTP server (chrony recommended, or ntpd) on both host and guest.
The single most decisive trick IMHO is to specify the '''host''' NTP server as the main entry within guest VM instead of "foreign" NTP servers, to make sure to achieve the most precise coupling between these two related systems (timing drift vs. other systems does not matter nearly as much as a tight time precision for inner host/guest system interaction e.g. in the case of NFS/Samba shares etc.).
For verification, see chronyc "sources -v", "tracking" ("System time" row) commands.

After having applied this very tight NTP coupling, this seems to finally have gotten rid of make's time drift warnings.

Perhaps qemu's -tdf (timing drift fix) option magically manages to help in your case, too.

See also [https://espace.cern.ch/it-faqs/Lists/faqs/DispForm.aspx?ID=368 Faqs: I received a message about "clock skew"].

----------
=== I get "rtc interrupts lost" messages, and the guest is very slow? ===
Try setting <code>CONFIG_HPET_EMULATE_RTC=y</code> in your host <code>.config</code>.

----------

=== I get an "Exception 13" or "Exception 12" message while booting a guest OS on my Intel host ===
See the [[Intel Real Mode Emulation Problems]] page.

----------

=== I have VMware/Parallels/VirtualBox installed and when I modprobe KVM, my system deadlocks. ===
Neither Intel VT nor AMD-V provide a mechanism to determine whether software is currently using the hardware virtualization extensions. This means that if you have two kernel modules loaded attempting to use hardware virtualization extensions, very bad things will happen. If you are using another type of virtualization software and experience any sort of weirdness with KVM, make sure you can reproduce the problem without the kernel modules for that software loaded before you report a bug in KVM.

----------

=== There's nothing on QEMU/KVM screen, but it's not hanged! I'm trying to install Kubuntu. ===
Try to run kvm with -std-vga option. It helps if guest operating system uses framebuffer mode like Kubuntu/Ubuntu.

----------

=== When I click the guest operating system window, mouse is grabbed. How can I get mouse to not to do that? OR Mouse doesn't show up / doesn't work in the guest. What do I do? ===
From #qemu wiki, try to run kvm/qemu with

-usb -usbdevice tablet
If that doesn't work, try this:

$ export SDL_VIDEO_X11_DGAMOUSE=0
(from http://wiki.clug.org.za/wiki/QEMU_mouse_not_working )

----------

== General KVM information ==
=== What is the difference between KVM and Xen? ===
Xen is an external hypervisor; it assumes control of the machine and divides resources among guests. On the other hand, KVM is part of Linux and uses the regular Linux scheduler and memory management. This means that KVM is much smaller and simpler to use; it is also more featureful; for example KVM can swap guests to disk in order to free RAM.

KVM only run on processors that supports x86 hvm (vt/svm instructions set) whereas Xen also allows running modified operating systems on non-hvm x86 processors using a technique called paravirtualization. KVM does not support paravirtualization for CPU but may support paravirtualization for device drivers to improve I/O performance.

----------

=== What is the difference between KVM and VMware? ===
VMware is a proprietary product. KVM is Free Software released under the GPL.

----------

=== What is the difference between KVM and QEMU? ===
QEMU uses emulation; KVM uses processor extensions (HVM) for virtualization.

----------

=== Do you have a port of KVM for Windows? ===
Not officially.

Kazushi Takahashi has been working on an experimental version though, called WinKVM, available [http://github.com/ddk50/winkvm here].

----------

=== What kernel version does it work with? ===
It depends on what version of KVM you are using. The last release of KVM should work with any recent kernel (2.6.17 and above), older releases even older kernels.

----------

=== How much RAM do I need? ===
You will need enough memory to let the guest run comfortably while keeping enough for the host. 1GB is probably a minimum configuration for the host OS.

----------

=== Is dynamic memory management for guests supported? ===
This is a broad topic covering a few areas.

A. KVM only allocates memory as the guest tries to use it. Once it's allocated, KVM keeps it. Some guests (namely Microsoft guests) zero all memory at boot time. So they will use all memory.

B. Certain guests (only Linux at the moment) have a balloon driver, so the host can have the guest allocate a certain amount of memory which the guest won't be able to use anymore and it can then be freed on the host. Ballooning is controlled in the host via the [http://www.nongnu.org/qemu/qemu-doc.html#SEC12 balloon monitor command].

C. Some hosts (presently only RHEL5.4 / CentOS 5.4) have a feature called KSM (Kernel Sharedpage Merging), which collapses together identical pages; this requires kernel support on the host, as well as a kvm new enough to opt in to the behavior. As some guest platforms (most notably Windows) zero out free'd memory, such pages are trivially collapsed. The ksmctl command needs to be used to enable KSM; alternately, the ksmtuned service found in Fedora 12 can be run to dynamically adjust KSM's aggressiveness based on the amount of free memory available

----------

=== What OSs can I run inside KVM VM? ===
Several. See the [[Guest Support Status]] page for details. Note that several Linux flavors are known to hang on Intel processors during startup. Workaround is to disable splash screens in grub.

----------

=== Does KVM support a live migration feature to move virtual machines from one host to another without downtime? ===
Yes. See the [[Migration]] page for details.

----------

=== Does KVM support live migration from an AMD host to an Intel host and back? ===
Yes. There may be issues on 32-bit Intel hosts which don't support NX (or XD), but for 64-bit hosts back and forth migration should work well. Migration of 32-bit guests should work between 32-bit hosts and 64-bit hosts.
If one of your hosts does not support NX, you may consider disabling NX when starting the guest on a NX-capable system. You can do it by passing "-cpu qemu64,-nx" parameter to the guest.

----------

=== Can KVM run a 32-bit guest on a 64-bit host? What about PAE? ===
KVM supports 32-bit guests on 64-bit hosts, and any combination of PAE and non-PAE guests and hosts. The only unsupported combination is a 64-bit guest on a 32-bit host.

If you are running a Windows Virtual Machine and have problems enabling PAE in your guest see the [[Windows PAE Workaround]] page.

----------

=== Is it possible to use USB devices with a guest OS? ===
Yes, look up how to do it with QEMU, it's the same way.

----------

=== Can I have higher or widescreen resolutions (eg 1680 x 1050) in KVM? ===
Use the -vga std parameter while starting the VM to allow high resolution and widescreen displays.

If the resolution you want to use is not available, you can patch the corresponding source files (see http://article.gmane.org/gmane.comp.emulators.kvm.devel/13557 as a reference), or send a mail to the KVM mailing list if you are not able to patch the source yourself.

When using Windows as guest OS and not having issues with people violating the GPL you might want to use the driver from the VBEMP x86 project (http://www.bearwindows.boot-land.net/vbemp.htm) which is based on ReactOS code.

----------

=== Does KVM support SMP hosts? ===
Yes.

----------

=== Does KVM support SMP guests? ===
Yes. Up to 16 CPUs can be specified using the -smp option.

----------

=== Is the name 'KVM' trademarked? ===
No.

----------

=== I compiled a new kernel for my KVM client and the ethernet interface is not recognized ===
You can specify alternative network interfaces to qemu with the ''-net nic,model='' parameter. For example, ''-net nic,model=rtl8139'' would enable a device with the Realtek 8139 chipset.

----------

=== I can't ping from guest to host or vice versa. How can I access the host? ===
The ping command may not go through in this circumstance, but you may be able to access the host in another way. For example, you can access a host running Apache by entering its IP address into a browser within the guest.

----------

[[Category:Docs]][[Category:HowTo]]

FAQ

2015-11-08T19:39:13Z

Ckotichas: /* I can't ping from guest to host or vice versa. How can I access the host? */

=FAQ=
__TOC__
== Preparing to use KVM ==
=== What do I need to use KVM? ===
You will need an x86 machine running a recent Linux kernel on an Intel processor with VT (virtualization technology) extensions, or an AMD processor with SVM extensions (also called AMD-V). Xen has a [http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors complete list] of compatible processors. For Intel processors, see also [http://ark.intel.com/VTList.aspx the Intel® Virtualization Technology List].

----------
=== Are 64-bit processors supported under KVM? ===
Yes they are supported and will allow you to run 32-bit and 64-bit guests.

See also '''Can KVM run a 32-bit guest on a 64-bit host? What about PAE?''' below.

----------

=== What is Intel VT / AMD-V / hvm? ===
[http://www.intel.com/technology/itj/2006/v10i3/1-hardware/6-vt-x-vt-i-solutions.htm Intel VT] and [http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_8826_14287,00.html AMD's AMD-V] are instruction set extensions that provide hardware assistance to virtual machine monitors. They enable running fully isolated virtual machines at native hardware speeds, for some workloads.

HVM (for Hardware Virtual Machine) is a vendor-neutral term often used to designate the x86 instruction set extensions.

----------

=== Where do I get my kvm kernel modules from? ===

See the [[Getting the kvm kernel modules]] page.

----------

=== How can I tell if I have Intel VT or AMD-V? ===
With a recent enough Linux kernel, run the command:

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

If something shows up, you have VT. You can also check the processor model name (in `/proc/cpuinfo`) in the vendor's web site.

Note:

* You'll never see (vmx|svm) in /proc/cpuinfo if you're currently running in in a dom0 or domU. The Xen hypervisor suppresses these flags in order to prevent hijacking.
* Some manufacturers disable VT in the machine's BIOS, in such a way that it cannot be re-enabled.
* `/proc/cpuinfo` only shows virtualization capabilities starting with Linux 2.6.15 (Intel) and Linux 2.6.16 (AMD). Use the `uname -r` command to query your kernel version.
In case of doubt, contact your hardware vendor.

----------

=== "KVM: disabled by BIOS" error ===
Check if there is an option to enable it in the BIOS. If not, look for a more recent BIOS on the vendor's web site.

Note:

* On some hardware (e-g HP nx6320), you need to power-off/power-on the machine after enabling virtualization in the BIOS.
* Enabling some BIOS features may break VT support on some hardware (e-g Enabling Intel AMT on a Thinkpad T500 will prevent kvm-intel from loading with "disabled by bios")
* On some Dell hardware, you also need to disable "Trusted Execution", otherwise VT will not be enabled.

----------

=== How can I use AMD-V extension? ===
modprobe kvm-amd

----------

=== What user space tools does KVM use? ===
KVM uses a slightly modified [http://www.nongnu.org/qemu QEMU] program to instantiate the virtual machine. Once running, a virtual machine is just a regular process. You can use `top(1), kill(1), taskset(1)` and similar tools to manage virtual machines.

----------

=== What virtual disk formats can KVM use? ===
KVM inherits a wealth of disk formats support from QEMU; it supports raw images, the native QEMU format (qcow2), VMware format, and many more.

----------

=== How do I use KVM on a headless machine (without a local GUI?) ===
Install a management tool such as virt-manager on a remote machine.

----------

=== Are there management tools available to help me manage my virtual machines? ===
Yes. Please see the [[Management Tools]] page for some links.

----------

== Using KVM ==
=== How can I use KVM with a non-privileged user? ===
The cleanest way is probably to create a group, say ''kvm'', and add the user(s) to that group. Then you will need change /dev/kvm to owned by group ''kvm''.

On a system that runs udev, you will probably need to add the following line somewhere in your udev configuration so it will automatically give the right group to the newly created device (i-e for ubuntu add a line to ''/etc/udev/rules.d/40-permissions.rules'').

KERNEL=="kvm", GROUP="kvm"

----------

=== How can I get the most performance out of KVM? ===

See the [[Tuning KVM]] page.

----------

=== Is KVM stable? ===
KVM is stable and used in production. As with most open source projects, development snapshots are less stable than the stable release series.

If your name is Andreas Mohr, you're reporting bugs in the wrong place.
----------

=== That's alright, but can I really use it for my daily use? ===
Sure. We continuously run the most often-used OSes and configurations and if anything breaks for the developers, it's fixed as soon as it was broken. See the [[Guest Support Status]] and [[Host Support Status]] pages to find out more. Please update them with success stories so that new users would benefit from the experience of the community.

----------

=== How about production use? ===
For production use, it's recommended you use the KVM modules shipped by the distribution you're using to ensure stability. As mentioned above, it's tempting to use new features, but you never know of (unwanted) surprises hidden away. It'll be best if you can run the development snapshots with non-critical production load, so that the latest releases are stable for you when you decide to deploy them.

----------

=== What happens if I kill -9 a VM process? ===
From the guest's perspective, it is as if you yanked the power cord out. From the host's perspective, the process is killed and all resources it uses are reclaimed.

----------

=== I need help to setup the network for my guest ===
You can have a look to the [[Networking]] page of this wiki for informations on the most classical networking setup for the guests. You can also refer to the QEMU documentation.

----------

=== Where can I find more documention... ===
Most usability issues are covered in the QEMU [http://www.nongnu.org/qemu/user-doc.html documentation]. There is also an extensive [http://qemu-buch.de/cgi-bin/moin.cgi/FrequentlyAskedQuestions FAQ] (old vanished link: [http://kidsquid.com/cgi-bin/moin.cgi/FrequentlyAskedQuestions FAQ]).

----------

== Troubleshooting ==
=== How can I check that I'm not falling back to QEMU with no hardware acceleration? ===

If you think that you might not be using the hardware acceleration provided by the KVM module, here are a few steps to help you check this.

First of all, check that you don't have messages such as:

qemu-system-x86_64 -hda myvm.qcow2
open /dev/kvm: No such file or directory
Could not initialize KVM, will disable KVM support

In that case, you can check that:
* the modules are correctly loaded <code>lsmod|grep kvm
* you don't have a "KVM: disabled by BIOS" line in the output of dmesg
* /dev/kvm exists and you have the correct rights to use it

Other ways to do the diagnostic:
* if you have access to the QEMU monitor (Ctrl-Alt-2, use Ctrl-Alt-1 to get back to the VM display), enter the "info kvm" command and it should respond with "KVM support: enabled"
* the right-end columns of the output from <code>lsmod|grep kvm</code> on the host system, once the VM is started should show only non zero values. The value on the line corresponding to the architecture specific module (e-g kvm_intel, kvm_amd) show the number of VM using the module. For instance, if I have 2 VM running using the KVM module on a machine with vt, it will report:

lsmod|grep kvm
kvm_intel 44896 2
kvm 159656 1 kvm_intel

=== "rect too big" Message when using VNC Display ===
When connection to a VNC Terminal, a "rect too big" message appears, and the VNC Session disconnects.

This happens because of a VNC protocol flaw on the way on-the-fly pixel format changes are handled (more info at [http://www.mail-archive.com/qemu-devel@nongnu.org/msg04879.html this thread]). If you are using TigerVNC, you can avoid this problem by disabling on-the-fly selection of pixel encoding, using the <tt>-AutoSelect=0</tt> command-line option of vncviewer. You may also want to check the encoding options on the vncviewer man page, as this will disable automatic selection of encoding based on connection speed.

----------
'''How do I set up the network such that my guest is accessible from other machines?''' or

=== My guest network is stuck what should I do? ===
KVM uses QEMU for its device emulation. Consult the [http://qemu-project.org/Documentation/Networking QEMU network wiki page] for detailed network setup instructions.

One would probably be interested in the Root Networking Mode page and the Network Bridge page.

Guest-side network lockups (fortunately restartable) may be happening due to tun/tap bridging erroneous MAC address reconfiguration on host side, see RHEL bug #571991 and others.

----------

=== I'm experiencing timer drift issues in my VM guests, what to do? ===

Especially in case of networked systems (e.g. via NFS or Samba) it is very important to ensure stable operation of timing (both system timer and RTC).
Tell-tale signs of related trouble in VMs (apparently qemu/KVM/VMWare etc. are all affected) are e.g.
"make[2]: Warning: File `XXXXX/cmakelists_rebuilder.stamp' has modification time 0.37 s in the future"
"Clock skew detected. Your build may be incomplete."

[http://maemovmware.garage.maemo.org/2nd_edition/requirements_documentation.html Maemo docs] state that it's important to disable UTC and set the correct time zone, however I don't really see how that would help in case of diverging host/guest clocks.
IMHO much more useful and important is to configure properly working NTP server (chrony recommended, or ntpd) on both host and guest.
The single most decisive trick IMHO is to specify the '''host''' NTP server as the main entry within guest VM instead of "foreign" NTP servers, to make sure to achieve the most precise coupling between these two related systems (timing drift vs. other systems does not matter nearly as much as a tight time precision for inner host/guest system interaction e.g. in the case of NFS/Samba shares etc.).
For verification, see chronyc "sources -v", "tracking" ("System time" row) commands.

After having applied this very tight NTP coupling, this seems to finally have gotten rid of make's time drift warnings.

Perhaps qemu's -tdf (timing drift fix) option magically manages to help in your case, too.

See also [https://espace.cern.ch/it-faqs/Lists/faqs/DispForm.aspx?ID=368 Faqs: I received a message about "clock skew"].

----------
=== I get "rtc interrupts lost" messages, and the guest is very slow? ===
Try setting <code>CONFIG_HPET_EMULATE_RTC=y</code> in your host <code>.config</code>.

----------

=== I get an "Exception 13" or "Exception 12" message while booting a guest OS on my Intel host ===
See the [[Intel Real Mode Emulation Problems]] page.

----------

=== I have VMware/Parallels/VirtualBox installed and when I modprobe KVM, my system deadlocks. ===
Neither Intel VT nor AMD-V provide a mechanism to determine whether software is currently using the hardware virtualization extensions. This means that if you have two kernel modules loaded attempting to use hardware virtualization extensions, very bad things will happen. If you are using another type of virtualization software and experience any sort of weirdness with KVM, make sure you can reproduce the problem without the kernel modules for that software loaded before you report a bug in KVM.

----------

=== There's nothing on QEMU/KVM screen, but it's not hanged! I'm trying to install Kubuntu. ===
Try to run kvm with -std-vga option. It helps if guest operating system uses framebuffer mode like Kubuntu/Ubuntu.

----------

=== When I click the guest operating system window, mouse is grabbed. How can I get mouse to not to do that? OR Mouse doesn't show up / doesn't work in the guest. What do I do? ===
From #qemu wiki, try to run kvm/qemu with

-usb -usbdevice tablet
If that doesn't work, try this:

$ export SDL_VIDEO_X11_DGAMOUSE=0
(from http://wiki.clug.org.za/wiki/QEMU_mouse_not_working )

----------

== General KVM information ==
=== What is the difference between KVM and Xen? ===
Xen is an external hypervisor; it assumes control of the machine and divides resources among guests. On the other hand, KVM is part of Linux and uses the regular Linux scheduler and memory management. This means that KVM is much smaller and simpler to use; it is also more featureful; for example KVM can swap guests to disk in order to free RAM.

KVM only run on processors that supports x86 hvm (vt/svm instructions set) whereas Xen also allows running modified operating systems on non-hvm x86 processors using a technique called paravirtualization. KVM does not support paravirtualization for CPU but may support paravirtualization for device drivers to improve I/O performance.

----------

=== What is the difference between KVM and VMware? ===
VMware is a proprietary product. KVM is Free Software released under the GPL.

----------

=== What is the difference between KVM and QEMU? ===
QEMU uses emulation; KVM uses processor extensions (HVM) for virtualization.

----------

=== Do you have a port of KVM for Windows? ===
Not officially.

Kazushi Takahashi has been working on an experimental version though, called WinKVM, available [http://github.com/ddk50/winkvm here].

----------

=== What kernel version does it work with? ===
It depends on what version of KVM you are using. The last release of KVM should work with any recent kernel (2.6.17 and above), older releases even older kernels.

----------

=== How much RAM do I need? ===
You will need enough memory to let the guest run comfortably while keeping enough for the host. 1GB is probably a minimum configuration for the host OS.

----------

=== Is dynamic memory management for guests supported? ===
This is a broad topic covering a few areas.

A. KVM only allocates memory as the guest tries to use it. Once it's allocated, KVM keeps it. Some guests (namely Microsoft guests) zero all memory at boot time. So they will use all memory.

B. Certain guests (only Linux at the moment) have a balloon driver, so the host can have the guest allocate a certain amount of memory which the guest won't be able to use anymore and it can then be freed on the host. Ballooning is controlled in the host via the [http://www.nongnu.org/qemu/qemu-doc.html#SEC12 balloon monitor command].

C. Some hosts (presently only RHEL5.4 / CentOS 5.4) have a feature called KSM (Kernel Sharedpage Merging), which collapses together identical pages; this requires kernel support on the host, as well as a kvm new enough to opt in to the behavior. As some guest platforms (most notably Windows) zero out free'd memory, such pages are trivially collapsed. The ksmctl command needs to be used to enable KSM; alternately, the ksmtuned service found in Fedora 12 can be run to dynamically adjust KSM's aggressiveness based on the amount of free memory available

----------

=== What OSs can I run inside KVM VM? ===
Several. See the [[Guest Support Status]] page for details. Note that several Linux flavors are known to hang on Intel processors during startup. Workaround is to disable splash screens in grub.

----------

=== Does KVM support a live migration feature to move virtual machines from one host to another without downtime? ===
Yes. See the [[Migration]] page for details.

----------

=== Does KVM support live migration from an AMD host to an Intel host and back? ===
Yes. There may be issues on 32-bit Intel hosts which don't support NX (or XD), but for 64-bit hosts back and forth migration should work well. Migration of 32-bit guests should work between 32-bit hosts and 64-bit hosts.
If one of your hosts does not support NX, you may consider disabling NX when starting the guest on a NX-capable system. You can do it by passing "-cpu qemu64,-nx" parameter to the guest.

----------

=== Can KVM run a 32-bit guest on a 64-bit host? What about PAE? ===
KVM supports 32-bit guests on 64-bit hosts, and any combination of PAE and non-PAE guests and hosts. The only unsupported combination is a 64-bit guest on a 32-bit host.

If you are running a Windows Virtual Machine and have problems enabling PAE in your guest see the [[Windows PAE Workaround]] page.

----------

=== Is it possible to use USB devices with a guest OS? ===
Yes, look up how to do it with QEMU, it's the same way.

----------

=== Can I have higher or widescreen resolutions (eg 1680 x 1050) in KVM? ===
Use the -vga std parameter while starting the VM to allow high resolution and widescreen displays.

If the resolution you want to use is not available, you can patch the corresponding source files (see http://article.gmane.org/gmane.comp.emulators.kvm.devel/13557 as a reference), or send a mail to the KVM mailing list if you are not able to patch the source yourself.

When using Windows as guest OS and not having issues with people violating the GPL you might want to use the driver from the VBEMP x86 project (http://www.bearwindows.boot-land.net/vbemp.htm) which is based on ReactOS code.

----------

=== Does KVM support SMP hosts? ===
Yes.

----------

=== Does KVM support SMP guests? ===
Yes. Up to 16 CPUs can be specified using the -smp option.

----------

=== Is the name 'KVM' trademarked? ===
No.

----------

=== I compiled a new kernel for my KVM client, and the ethernet interface is not recognized ===
you can tell qemu to emulate e.g. the 8139 with model=rtl8139

----------

=== I can't ping from guest to host or vice versa. How can I access the host? ===
The ping command may not go through in this circumstance, but you may be able to access the host in another way. For example, you can access a host running Apache by entering its IP address into a browser within the guest.

----------

[[Category:Docs]][[Category:HowTo]]

FAQ

2015-11-08T19:28:18Z

Ckotichas: /* Are 64-bit processors supported under KVM? */

=FAQ=
__TOC__
== Preparing to use KVM ==
=== What do I need to use KVM? ===
You will need an x86 machine running a recent Linux kernel on an Intel processor with VT (virtualization technology) extensions, or an AMD processor with SVM extensions (also called AMD-V). Xen has a [http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors complete list] of compatible processors. For Intel processors, see also [http://ark.intel.com/VTList.aspx the Intel® Virtualization Technology List].

----------
=== Are 64-bit processors supported under KVM? ===
Yes they are supported and will allow you to run 32-bit and 64-bit guests.

See also '''Can KVM run a 32-bit guest on a 64-bit host? What about PAE?''' below.

----------

=== What is Intel VT / AMD-V / hvm? ===
[http://www.intel.com/technology/itj/2006/v10i3/1-hardware/6-vt-x-vt-i-solutions.htm Intel VT] and [http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_8826_14287,00.html AMD's AMD-V] are instruction set extensions that provide hardware assistance to virtual machine monitors. They enable running fully isolated virtual machines at native hardware speeds, for some workloads.

HVM (for Hardware Virtual Machine) is a vendor-neutral term often used to designate the x86 instruction set extensions.

----------

=== Where do I get my kvm kernel modules from? ===

See the [[Getting the kvm kernel modules]] page.

----------

=== How can I tell if I have Intel VT or AMD-V? ===
With a recent enough Linux kernel, run the command:

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

If something shows up, you have VT. You can also check the processor model name (in `/proc/cpuinfo`) in the vendor's web site.

Note:

* You'll never see (vmx|svm) in /proc/cpuinfo if you're currently running in in a dom0 or domU. The Xen hypervisor suppresses these flags in order to prevent hijacking.
* Some manufacturers disable VT in the machine's BIOS, in such a way that it cannot be re-enabled.
* `/proc/cpuinfo` only shows virtualization capabilities starting with Linux 2.6.15 (Intel) and Linux 2.6.16 (AMD). Use the `uname -r` command to query your kernel version.
In case of doubt, contact your hardware vendor.

----------

=== "KVM: disabled by BIOS" error ===
Check if there is an option to enable it in the BIOS. If not, look for a more recent BIOS on the vendor's web site.

Note:

* On some hardware (e-g HP nx6320), you need to power-off/power-on the machine after enabling virtualization in the BIOS.
* Enabling some BIOS features may break VT support on some hardware (e-g Enabling Intel AMT on a Thinkpad T500 will prevent kvm-intel from loading with "disabled by bios")
* On some Dell hardware, you also need to disable "Trusted Execution", otherwise VT will not be enabled.

----------

=== How can I use AMD-V extension? ===
modprobe kvm-amd

----------

=== What user space tools does KVM use? ===
KVM uses a slightly modified [http://www.nongnu.org/qemu QEMU] program to instantiate the virtual machine. Once running, a virtual machine is just a regular process. You can use `top(1), kill(1), taskset(1)` and similar tools to manage virtual machines.

----------

=== What virtual disk formats can KVM use? ===
KVM inherits a wealth of disk formats support from QEMU; it supports raw images, the native QEMU format (qcow2), VMware format, and many more.

----------

=== How do I use KVM on a headless machine (without a local GUI?) ===
Install a management tool such as virt-manager on a remote machine.

----------

=== Are there management tools available to help me manage my virtual machines? ===
Yes. Please see the [[Management Tools]] page for some links.

----------

== Using KVM ==
=== How can I use KVM with a non-privileged user? ===
The cleanest way is probably to create a group, say ''kvm'', and add the user(s) to that group. Then you will need change /dev/kvm to owned by group ''kvm''.

On a system that runs udev, you will probably need to add the following line somewhere in your udev configuration so it will automatically give the right group to the newly created device (i-e for ubuntu add a line to ''/etc/udev/rules.d/40-permissions.rules'').

KERNEL=="kvm", GROUP="kvm"

----------

=== How can I get the most performance out of KVM? ===

See the [[Tuning KVM]] page.

----------

=== Is KVM stable? ===
KVM is stable and used in production. As with most open source projects, development snapshots are less stable than the stable release series.

If your name is Andreas Mohr, you're reporting bugs in the wrong place.
----------

=== That's alright, but can I really use it for my daily use? ===
Sure. We continuously run the most often-used OSes and configurations and if anything breaks for the developers, it's fixed as soon as it was broken. See the [[Guest Support Status]] and [[Host Support Status]] pages to find out more. Please update them with success stories so that new users would benefit from the experience of the community.

----------

=== How about production use? ===
For production use, it's recommended you use the KVM modules shipped by the distribution you're using to ensure stability. As mentioned above, it's tempting to use new features, but you never know of (unwanted) surprises hidden away. It'll be best if you can run the development snapshots with non-critical production load, so that the latest releases are stable for you when you decide to deploy them.

----------

=== What happens if I kill -9 a VM process? ===
From the guest's perspective, it is as if you yanked the power cord out. From the host's perspective, the process is killed and all resources it uses are reclaimed.

----------

=== I need help to setup the network for my guest ===
You can have a look to the [[Networking]] page of this wiki for informations on the most classical networking setup for the guests. You can also refer to the QEMU documentation.

----------

=== Where can I find more documention... ===
Most usability issues are covered in the QEMU [http://www.nongnu.org/qemu/user-doc.html documentation]. There is also an extensive [http://qemu-buch.de/cgi-bin/moin.cgi/FrequentlyAskedQuestions FAQ] (old vanished link: [http://kidsquid.com/cgi-bin/moin.cgi/FrequentlyAskedQuestions FAQ]).

----------

== Troubleshooting ==
=== How can I check that I'm not falling back to QEMU with no hardware acceleration? ===

If you think that you might not be using the hardware acceleration provided by the KVM module, here are a few steps to help you check this.

First of all, check that you don't have messages such as:

qemu-system-x86_64 -hda myvm.qcow2
open /dev/kvm: No such file or directory
Could not initialize KVM, will disable KVM support

In that case, you can check that:
* the modules are correctly loaded <code>lsmod|grep kvm
* you don't have a "KVM: disabled by BIOS" line in the output of dmesg
* /dev/kvm exists and you have the correct rights to use it

Other ways to do the diagnostic:
* if you have access to the QEMU monitor (Ctrl-Alt-2, use Ctrl-Alt-1 to get back to the VM display), enter the "info kvm" command and it should respond with "KVM support: enabled"
* the right-end columns of the output from <code>lsmod|grep kvm</code> on the host system, once the VM is started should show only non zero values. The value on the line corresponding to the architecture specific module (e-g kvm_intel, kvm_amd) show the number of VM using the module. For instance, if I have 2 VM running using the KVM module on a machine with vt, it will report:

lsmod|grep kvm
kvm_intel 44896 2
kvm 159656 1 kvm_intel

=== "rect too big" Message when using VNC Display ===
When connection to a VNC Terminal, a "rect too big" message appears, and the VNC Session disconnects.

This happens because of a VNC protocol flaw on the way on-the-fly pixel format changes are handled (more info at [http://www.mail-archive.com/qemu-devel@nongnu.org/msg04879.html this thread]). If you are using TigerVNC, you can avoid this problem by disabling on-the-fly selection of pixel encoding, using the <tt>-AutoSelect=0</tt> command-line option of vncviewer. You may also want to check the encoding options on the vncviewer man page, as this will disable automatic selection of encoding based on connection speed.

----------
'''How do I set up the network such that my guest is accessible from other machines?''' or

=== My guest network is stuck what should I do? ===
KVM uses QEMU for its device emulation. Consult the [http://qemu-project.org/Documentation/Networking QEMU network wiki page] for detailed network setup instructions.

One would probably be interested in the Root Networking Mode page and the Network Bridge page.

Guest-side network lockups (fortunately restartable) may be happening due to tun/tap bridging erroneous MAC address reconfiguration on host side, see RHEL bug #571991 and others.

----------

=== I'm experiencing timer drift issues in my VM guests, what to do? ===

Especially in case of networked systems (e.g. via NFS or Samba) it is very important to ensure stable operation of timing (both system timer and RTC).
Tell-tale signs of related trouble in VMs (apparently qemu/KVM/VMWare etc. are all affected) are e.g.
"make[2]: Warning: File `XXXXX/cmakelists_rebuilder.stamp' has modification time 0.37 s in the future"
"Clock skew detected. Your build may be incomplete."

[http://maemovmware.garage.maemo.org/2nd_edition/requirements_documentation.html Maemo docs] state that it's important to disable UTC and set the correct time zone, however I don't really see how that would help in case of diverging host/guest clocks.
IMHO much more useful and important is to configure properly working NTP server (chrony recommended, or ntpd) on both host and guest.
The single most decisive trick IMHO is to specify the '''host''' NTP server as the main entry within guest VM instead of "foreign" NTP servers, to make sure to achieve the most precise coupling between these two related systems (timing drift vs. other systems does not matter nearly as much as a tight time precision for inner host/guest system interaction e.g. in the case of NFS/Samba shares etc.).
For verification, see chronyc "sources -v", "tracking" ("System time" row) commands.

After having applied this very tight NTP coupling, this seems to finally have gotten rid of make's time drift warnings.

Perhaps qemu's -tdf (timing drift fix) option magically manages to help in your case, too.

See also [https://espace.cern.ch/it-faqs/Lists/faqs/DispForm.aspx?ID=368 Faqs: I received a message about "clock skew"].

----------
=== I get "rtc interrupts lost" messages, and the guest is very slow? ===
Try setting <code>CONFIG_HPET_EMULATE_RTC=y</code> in your host <code>.config</code>.

----------

=== I get an "Exception 13" or "Exception 12" message while booting a guest OS on my Intel host ===
See the [[Intel Real Mode Emulation Problems]] page.

----------

=== I have VMware/Parallels/VirtualBox installed and when I modprobe KVM, my system deadlocks. ===
Neither Intel VT nor AMD-V provide a mechanism to determine whether software is currently using the hardware virtualization extensions. This means that if you have two kernel modules loaded attempting to use hardware virtualization extensions, very bad things will happen. If you are using another type of virtualization software and experience any sort of weirdness with KVM, make sure you can reproduce the problem without the kernel modules for that software loaded before you report a bug in KVM.

----------

=== There's nothing on QEMU/KVM screen, but it's not hanged! I'm trying to install Kubuntu. ===
Try to run kvm with -std-vga option. It helps if guest operating system uses framebuffer mode like Kubuntu/Ubuntu.

----------

=== When I click the guest operating system window, mouse is grabbed. How can I get mouse to not to do that? OR Mouse doesn't show up / doesn't work in the guest. What do I do? ===
From #qemu wiki, try to run kvm/qemu with

-usb -usbdevice tablet
If that doesn't work, try this:

$ export SDL_VIDEO_X11_DGAMOUSE=0
(from http://wiki.clug.org.za/wiki/QEMU_mouse_not_working )

----------

== General KVM information ==
=== What is the difference between KVM and Xen? ===
Xen is an external hypervisor; it assumes control of the machine and divides resources among guests. On the other hand, KVM is part of Linux and uses the regular Linux scheduler and memory management. This means that KVM is much smaller and simpler to use; it is also more featureful; for example KVM can swap guests to disk in order to free RAM.

KVM only run on processors that supports x86 hvm (vt/svm instructions set) whereas Xen also allows running modified operating systems on non-hvm x86 processors using a technique called paravirtualization. KVM does not support paravirtualization for CPU but may support paravirtualization for device drivers to improve I/O performance.

----------

=== What is the difference between KVM and VMware? ===
VMware is a proprietary product. KVM is Free Software released under the GPL.

----------

=== What is the difference between KVM and QEMU? ===
QEMU uses emulation; KVM uses processor extensions (HVM) for virtualization.

----------

=== Do you have a port of KVM for Windows? ===
Not officially.

Kazushi Takahashi has been working on an experimental version though, called WinKVM, available [http://github.com/ddk50/winkvm here].

----------

=== What kernel version does it work with? ===
It depends on what version of KVM you are using. The last release of KVM should work with any recent kernel (2.6.17 and above), older releases even older kernels.

----------

=== How much RAM do I need? ===
You will need enough memory to let the guest run comfortably while keeping enough for the host. 1GB is probably a minimum configuration for the host OS.

----------

=== Is dynamic memory management for guests supported? ===
This is a broad topic covering a few areas.

A. KVM only allocates memory as the guest tries to use it. Once it's allocated, KVM keeps it. Some guests (namely Microsoft guests) zero all memory at boot time. So they will use all memory.

B. Certain guests (only Linux at the moment) have a balloon driver, so the host can have the guest allocate a certain amount of memory which the guest won't be able to use anymore and it can then be freed on the host. Ballooning is controlled in the host via the [http://www.nongnu.org/qemu/qemu-doc.html#SEC12 balloon monitor command].

C. Some hosts (presently only RHEL5.4 / CentOS 5.4) have a feature called KSM (Kernel Sharedpage Merging), which collapses together identical pages; this requires kernel support on the host, as well as a kvm new enough to opt in to the behavior. As some guest platforms (most notably Windows) zero out free'd memory, such pages are trivially collapsed. The ksmctl command needs to be used to enable KSM; alternately, the ksmtuned service found in Fedora 12 can be run to dynamically adjust KSM's aggressiveness based on the amount of free memory available

----------

=== What OSs can I run inside KVM VM? ===
Several. See the [[Guest Support Status]] page for details. Note that several Linux flavors are known to hang on Intel processors during startup. Workaround is to disable splash screens in grub.

----------

=== Does KVM support a live migration feature to move virtual machines from one host to another without downtime? ===
Yes. See the [[Migration]] page for details.

----------

=== Does KVM support live migration from an AMD host to an Intel host and back? ===
Yes. There may be issues on 32-bit Intel hosts which don't support NX (or XD), but for 64-bit hosts back and forth migration should work well. Migration of 32-bit guests should work between 32-bit hosts and 64-bit hosts.
If one of your hosts does not support NX, you may consider disabling NX when starting the guest on a NX-capable system. You can do it by passing "-cpu qemu64,-nx" parameter to the guest.

----------

=== Can KVM run a 32-bit guest on a 64-bit host? What about PAE? ===
KVM supports 32-bit guests on 64-bit hosts, and any combination of PAE and non-PAE guests and hosts. The only unsupported combination is a 64-bit guest on a 32-bit host.

If you are running a Windows Virtual Machine and have problems enabling PAE in your guest see the [[Windows PAE Workaround]] page.

----------

=== Is it possible to use USB devices with a guest OS? ===
Yes, look up how to do it with QEMU, it's the same way.

----------

=== Can I have higher or widescreen resolutions (eg 1680 x 1050) in KVM? ===
Use the -vga std parameter while starting the VM to allow high resolution and widescreen displays.

If the resolution you want to use is not available, you can patch the corresponding source files (see http://article.gmane.org/gmane.comp.emulators.kvm.devel/13557 as a reference), or send a mail to the KVM mailing list if you are not able to patch the source yourself.

When using Windows as guest OS and not having issues with people violating the GPL you might want to use the driver from the VBEMP x86 project (http://www.bearwindows.boot-land.net/vbemp.htm) which is based on ReactOS code.

----------

=== Does KVM support SMP hosts? ===
Yes.

----------

=== Does KVM support SMP guests? ===
Yes. Up to 16 CPUs can be specified using the -smp option.

----------

=== Is the name 'KVM' trademarked? ===
No.

----------

=== I compiled a new kernel for my KVM client, and the ethernet interface is not recognized ===
you can tell qemu to emulate e.g. the 8139 with model=rtl8139

----------

=== I can't ping from host to guest or vice versa. How can I access the host please? ===
ping does not go through, but I suppose you can access the host in some way, i.e. you can navigate for sure internet(e.g. firefox) if host can

----------

[[Category:Docs]][[Category:HowTo]]