The QEMU and KVM tools are the low-level command line utilities that create a virtual machine. Before learning about higher-level tools, see how these basic tools work.
- [Instructor] The most direct way of creating a virtual machine is to use QEMU at the command line. This isn't something you're likely to do on a daily basis but it's the process that other more high-level tools will use to make virtual machines, so it's a good idea to understand what's going on under the hood before we start using fancy tools to do this for us. In order for us to use QEMU we need to install it and that can be done with a package manager. In my case, here on Ubuntu, I'll write apt install qemu and qemu-kvm.
This will install QEMU and some other software that it needs to run. The version of QEMU that I'm installing has a graphical user interface component. There's also a version without that called QEMU Headless which can be used to run existing virtual machines but which makes it a little bit difficult to go through the installation process to setup a guest operating system if we can't see what's happening on the guest's screen. So we're not using the headless version here, because we need to be able to interact with the graphical interface. With the QEMU package we get a whole bunch of new binaries. I'll take a look at the usr bin directory for everything that starts with qemu.
Most of these are specific implementations of QEMU for each of many different kinds of processor architectures. These tools set the processor type of the guest operating system. QEMU only runs on x86 hosts but it can emulate all of these other processor types, so if you need to run an OS that runs on a legacy processor, like if you're consolidating old systems onto new hardware. You can do that at a little bit of a cost in speed and if you're running an x86 guest you can take advantage of the speed benefit from KVM passing instructions directly to your x86 processor.
Running one of these will start a virtual environment, emulating the particular processor and a collection of emulated devices, video, sound, network and so on. You can check out the details of what particular models of devices are emulated with the man page for QEMU system. And if you scroll down you can see detailed information about common and advanced options you may be interested in exploring once you're familiar with the basics. I'll quit man for now with the Q key. Before we started the system, in most cases we need somewhere to store our installed operating system.
if you're booting a live CD or something you don't need storage, but I want to make a persistent VM to use later on and to do that I need a disk to install on. The most common way of creating a disk for a virtual machine is to generate a disk image file and we can create one using the QEMU image command. Virtual machines can use real disks and partitions, too, but we're not going to do that right now. Instead, we'll create a file and we have a few options available for that. We can create a raw disk image or a QCOW2 disk image.
A raw disk image is a chunk of data that we allocate to take up a specific size. A raw disk image works just like a loop-back file system with some other metadata added on top of it. If we want our guest OS to have a 60 gigabyte disk, we create a 60 gigabyte file on the host. All the space is taken up on the host when we create the file, even if the guest OS is only using a little bit of it for files or even if there's no OS on the virtual disk yet. In some products, this is called thick provisioning.
The other option is QCOW2. QCOW stands for QEMU Copy On Write. Among other benefits of this kind of file is that it's not a big monolith like the raw format. If we create a QCOW2 file to represent a 60 GB disk for our guest operating system, the file in the host doesn't take up 60 gigabytes until the guest actually fills it with 60 gigabytes of data. This is a huge space saving feature. It's called thin provisioning in some products and it lets you create disks that are more easily resized and lets you over provision the space available on your host.
But, of course, you want to keep an eye on how much space is actually being consumed, because you're still limited by the amount of disk space available on the host as your guests start filling their disks up. The copy on write feature is also an important aspect of this format. That lets us create a base image, say a clean installation of Linux or an installation that's in some particular beginning state and then use another image layered on top of it, that holds any kind of changes to that base file. The guest OS doesn't know of any difference between these images, it just sees it as that it can use.
Newly-created files are written to and read from the overlay file and any file that the system wants to modify from the base image gets copied to the overlay image and the changes saved there, leaving the base image unchanged. That image can then be used as the base for other machines with the same start state but which need to have different data afterward. That's helpful for generating cookie cutter machines with a particular configuration. Saving you from having to configure a bunch of identical machines manually. If you need to start them up on the fly in response to demand or other business reasons.
For now, we'll just use one image for our basic virtual machine. We can also take snapshots of QCOW2 images, making backups and rolling back changes very quick and easy. So to create ourselves a disk image that will contain the data for our virtual machine, let's write qemu -img create -f for format and QCOW2 and then I'll give it a name. I'll call it my-image.QCOW2.
And then we'll set a size, 60 gigabytes. To thick provision a raw image, I'd replace QCOW2 here with raw. We can use the qemu command to do all kinds of other interesting things as well, like convert and resize images. Having this image ready to go, now we need to install an operating system on it. Take a moment to go download your favorite distro. I've already downloaded some disk images. The desktop and server versions of Ubunto 16.04.
I'll use the qemu -system -x86_64 command and the -cdrom option with a path to our installation image. In my case, it's downloads/ubuntu and let's use the desktop version. This will create a virtual optical drive for our ISO image to mount on. Then I need to specify the disk image file that will be the drive we install onto. In my case that's my-image.qcow2. By default, qemu will start a machine with 64 megabytes of RAM which really isn't good for much at all, so I need to use the -m option to give it, let's say two gigabytes.
And because this is an x86 system on an x86 host, I'll use the enable-kvm option to tell the hypervisor to use kvm. You can leave that off if you want to experience a modern operating system on an emulated processor, which is interesting if you have some time on your hands. Be patient. There are as we saw on the man pages many other options that can be used here. We can specify network settings, choose to emit certain kinds of ports and more. But for now this is a good start. So I'll press enter and run the command to start up the VM.
A graphical window opens up and we can see the boot process and then the installer. When I click into this window, it captures my mouse and keyboard input. And to release that if I want to switch to another window, I need to press control, alt. I'll go through a standard installation fairly quickly here, because the specific details of this installation don't really matter. And we'll speed up the video for the parts that actually take time to install. If you're curious about the options that I'm clicking through check out our courses that focus on installation.
I'll choose Install Ubuntu, and then I'll choose Continue. I'll go through the default options for setting up the disk. Now I'll choose my timezone and my keyboard. I'll set a name, and I'll set my computer's name. We'll call this ubuntuvm. And now I'll set a password.
Okay, once the OS is installed I'll click the Restart Now button. If the system doesn't come back up I can just close out of this window. To start it up again I'll use qemu-system-x86_64, and the disk image for the VM. And if I pressed enter now my system wouldn't boot, because it remember qemu defaults to 64 megabytes of RAM. So I need to tell it -m and memory size, two gigabytes, and -enable kvm.
You need to specify these parameters when you're starting up a VM from the command line every time which is one of the reasons the management software we'll see later comes in really handy. You could also put the command in a script if you wanted to. I'll run that command and my VM boots up. And now we have a virtual machine running in qemu. As far as it knows, it's a real computer, but we know better. I'll log in.
We can explore the hardware available to us here with the lshw command or lspci and so on, or we can install a program to show us these things graphically. Let's take a moment and do that. Here in the terminal I'll write apt install hardinfo. And when that's installed I'll open it up. I can see the various parts of the system, and here under processor I can see that this is reporting as a qemu processor.
And here under PCI devices I can see all of my emulated devices. I'll close that. And I can take a look at the other resources I have such as the memory with 3-h. And here I can see I have two gigabytes of memory. And I can take a look at the disk with df-h and see that here I have a 60 gigabyte disk. And any changes we make in this system like running software updates or making configuration changes gets saved in our disk image and will persist when we shut down and restart this machine.
And when we make any changes to this system like running software updates or making configuration changes, they get saved in our disk image file and will persist when we shut down and restart this machine. I can make a copy of this file and start up a different machine with it or take the disk image file to another host and start it up and have precisely the same environment that I have here. And to back up this machine I just need to copy the disk image file to my backup media. Keep in mind though you don't want to start two VMs from the same exact file. The operating systems will get rather confused if you do that.
Make a copy if you're going to use it twice, or use an overlay file as we'll see how to do a little bit later on.