My first QeMu VM
Before we can have a virtual machine, we need some virtual storage. The simplest way to do this is to use qemu-img, as follows:
$ qemu-img create -f qcow2 lxf.qcow2 20G This will create a dynamic QCOW2 image, so in this case it won’t immediately swallow up 20GB of disk space. Do make sure you create it in a location where it can safely grow to this size though, because if your root partition runs out of space then terrible things can happen. It’s possible to use statically sized raw images too. These may offer performance benefits in some situations and won’t incur storage overheads as you add data to them, but are less robust when your VM crashes.
We define the specifics of our VM by way of command line options. As you can imagine, there are probably enough of them to fill an issue of Linux Format, so we’ll concentrate on the essentials first. We’ll use an Elementary OS ISO (which you can find on our DVD, but you’ll want to copy it to a faster drive) in this example, but feel free to boot the OS of your choice. You can equally well specify /dev/cdrom instead of an ISO file if you want to use actual media. Here’s how to fire up our VM and allocate it 3GB of memory (a reasonable amount for desktop Linux):
$ qemu-system-x86_64 -cdrom elementaryos-5.0stable.20181016.iso -drive file=lxf.qcow2 -enablekvm -m 3G Note the -enable-kvm option here. QEMU on its own is just an emulator, and if we don’t let it use KVM then everything is emulated and so things will go slowly. Very slowly. If we explore the live environment (using the Try Elementary option) you should find that browsing the internet works, but pinging hosts doesn’t.
QEMU by default sets up some basic NAT networking which is fine for many use cases, but won’t let you, for example, SSH into the VM. Check the box (below left) for more advanced networking options. We can also go ahead and install Elementary OS as if we were doing it for real. When the install finishes select Restart. The virtual optical media will be ejected and you should be able to log in with the credentials you used to install. You should also find that things are a little faster with the live medium, but probably a far cry from a bare metal install.
By default QEMU sets up a basic VGA video card which for some reason could only manage 800x600 in our Elementary install. It should be able to handle much higher resolutions, but there are better options. One is the paravirtualised QXL virtual video device, which offers 2D acceleration and can (when using a suitable viewer) use the SPICE protocol for an even smoother experience. Shut down the VM and try starting it again with the QXL device: $ qemu-system-x86_64 -drive file=/mnt/stor/VMs/ lxf.qcow2 -enable-kvm -m 3G -vga qxl Now, inside the guest, if you run lspci you should see a line like the following: … Red Hat, Inc. QXL paravirtual graphic card and you should also have access to higher resolutions via System Settings> Displays. You can also assign more video memory to the QXL device (the default is 16MB, which is enough to handle up to and beyond 1080p at 32-bit depth, but you’ll need more for 4K) by adding an option like -global qxl-vga.vram_size=64MB to the end of the previous command. There are other settings for manipulating QXL memory – vgamem and ram – but we’ll leave it to you to figure out the subtleties that separate them. Bear in mind that none of these represent real video memory, and it won’t help with 3D acceleration (don’t worry, we’ll cover this later).
With the default settings our VM emulates an Intel 440FX chipset with a PIIX3 IDE disk controller and a bespoke emulated CPU. This is very simple hardware by today’s standards, and that is a good thing: it makes these things easier to emulate. Besides the QXL video device or the default VGA driver, it’s also possible to mimic an ancient Cirrus Logic GD5446 (this used to be the default in QEMU). However, rather than emulating old devices, a hypervisor can save effort by creating slimline virtual hardware and marshalling data to the appropriate piece of hardware on our actual machine. This technique is known as paravirtualisation, and the magic that enables KVM to use it is known as VirtIO. The QXL device is paravirtualised in the sense that it provides access to software rendering on the host machine, so it’s not going to break any speed records. But a VirtIO hard
DOUBLE THE VIRTUAL FUN “QEMU ON ITS OWN IS AN EMULATOR, BUT COMBINED WITH THE POWER OF KVM IT BECOMES A VIRTUALISATION TOOL”
drive can offer tremendous speed benefits; a VirtIO network adapter can lower latency and accelerate throughput. The VirtIO drivers are included in all Linux distributions, but you’ll need to install drivers for Windows, which you can find at https://fedorapeople. org/groups/virt/virtio-win/direct-downloads/. VirtIO devices can be set up and tuned from the command line, but this rapidly leads to unwieldy commands. It’s much easier to use the Libvirt-powered GUI interface virtmanager. Which we conveniently installed earlier.