Virtual Machines with libvirt/KVM/QEMU

= Introduction =

For simple experimentation needs, VirtualBox is more polished and easier to use. However, it is worth learning libvirt instead, because it is more powerful and you can use it later on in production. The Virtual Machine Manager GUI is easy enough for novice usage too. If you learn some tricks beforehand, you will have a much easier ride. That is the main motivation for writing this page.

The information and instructions below are for to Ubuntu 18.04 and 20.04, but most of it probably applies to other Linux systems too.

= Installing the libvirt/KVM/QEMU Software =

In order to install libvirt/KVM/QEMU, install the following packages:

libvirt-bin libvirt-doc

The GUI tool will probably be helpful too, but if you are installing on a headless server, you can use the GUI from your workstation too. The package is:

virt-manager

If you are using Cockpit, install this package to see the VMs on the web interface:

cockpit-machines

After installing libvirt, log off and on again, so that your user account becomes a member of the libvirt group. I had once trouble connecting to the daemon socket with the virt-manager GUI, even though the user was effectively a member of 'libvirt'. I had to reboot the entire system, and then it worked.

= Creating a Virtual Machine =

Choosing a Virtual Graphics Card

 * Virtio graphics offer paravirtualised 3D acceleration.
 * For Linux, Virtio graphics are considered stable, but you do not usually need 3D acceleration in a VM. It may be safer to reduce virtualisation complexity and go for QXL instead.
 * It is not clear whether Virtio graphics are stable under Microsoft Windows. The digitally-signed drivers from RedHat do not seem to include a driver for the Virtio graphics card, so it probably best to use QXL instead.


 * A "Video QXL graphics card" offers paravirtualised 2D acceleration only. For Windows 8 or later, which uses the newer "Windows Display Driver Model" (WDDM), use the 'qxl-dod' graphics driver.

Choosing a Virtual Machine Type

 * pc is a standard PC i440FX + PIIX, from year 1996, alias of pc-i440fx-2.11 (the exact version may vary). It works best with older versions of Windows. Windows 10 is fine too.


 * q35 is a standard PC Q35 + ICH9, from year 2009, alias of pc-q35-2.11 (the exact version may vary). This machine type is newer than pc-i440fx, adds the PCI Express Bus and AHCI Bus Emulation (for SATA interfaces), and some modern motherboard and BIOS features. It works best with Linux. There is no support for legacy Windows XP/2000 guests.

Choosing a Virtual CPU
Choosing the right CPU type is hard, but that is only necessary if you need live migration, see libvirt API compareHypervisorCPU for the gory details. But if you need live migration, you probably would not be reading this page anyway.

You normally choose option "Copy host CPU configuration" and be done with it. Just keep in mind that a snapshot of a live VM may not be able to resume live on another host with a different CPU. Nevertheless, the OS inside the VM should be able to cold boot with the new CPU type.

Other Virtual Hardware

 * RNG (Random Number Generator):
 * This is not required under Windows, but add one just in case something needs a good random source for encryption purposes.
 * The first Debian boot can take a very long time without RNG, if the OS does not find a good random source for encryption purposes and it resorts to gathering entropy from somewhere else, like mouse movements.


 * VirtIO network card: Manually set a MAC address to avoid the risk of duplicates on your LAN. Changing the MAC address later could have an impact on Windows activation.


 * VirtIO disks: Manually set the "Cache mode" because it often has a suboptimal default:
 * "none" is your best bet, because it provides performance characteristics that are easy to understand: when the virtual disk is busy, it has the expected disk performance impact on the whole host and any other VMs.
 * "write-through" and "write-back" tend to pollute the host's page cache and will probably cause unexpected and possibly severe performance problems on the whole host and any other VMs, see The Linux Filesystem Cache is Braindead for more information.
 * "directsync" is slow.
 * "unsafe" is generally not a good idea.

Virtual Hardware for Windows

 * Avoid SATA disk interfaces, as they may prevent saving the VM state.


 * Create 2 virtual CD-ROM drives. They must be IDE, because the Windows setup program has a built-in driver to access standard IDE drives:
 * One CD-ROM drive is for the Windows installation DVD (mounted as ISO image).
 * The other drive is for the Virtio device drivers CD-ROM (mounted as ISO image). You will have to point the Windows setup program to the Virtio disk device driver on this CD-ROM during installation. Otherwise, the Windows setup program will not be able to access the Virtio virtual disk. After installation, the Windows Device Manager can recursively search for device drivers, but the Windows setup program apparently cannot. Look for the driver under a subdirectory like /viostor/w10/amd64/.


 * There is a relatively new issue that causes high CPU usage with Windows 10 guests. I have not got the details yet, but it seems to be related to a timer clock option called hpet.