Introduction

Homelabs are something amazing. They enable you to learn, try out new things, and test your environments, and the only person that knows around a homelab is the owner, no one else. It is almost like a small little playground for developers where they can make and break things. And if done right, it doesn't matter what you break, because you can always revert back to a previous state of your machine. But what are the essentials of a homelab?

Well... it's not quite easy to say. Of course, it will be different for every developer, but the heart of it all is the ability to spin up multiple virtual machines (VMs) in a short amount of time. This gives you the priceless flexibility to test ANYTHING without breaking nothing. Do you want to try out DHCP for the first time without messing up your home network? Spin up a new VM. What about exploiting the infamous EternalBlue vulnerability on Windows? Spin up a new VM. Need to test the kubernetes architecture for an upcoming project? Spin up a few new VMs. Whenever you want to test or try something out for the first time, a VM is probably your best option. But how exactly do you create a VM the "best way"? Again... it's not easy to say. There are so many things you have to know that it can get difficult to even start with this exciting technology.

Basics of virtualization

Let's quickly rewind to the basics. A virtual machine is an guest OS that sits on top of your host OS. This guest OS is managed by a hypervisor, for example the Kernel-based Virtual Machine (KVM). There are several different hypervisors out there, but we will stick to KVM since it is the go to hypervisors for most Linux distributions. The hypervisor decides how much CPU, memory, storage, shared folders, and so on will be assigned to your virtual machine. In short, the hypervisor is responsible for the configuration and management of the virtual machine. Now at this point you might ask, why not just take the easy path and use a GUI like VMware or VirtualBox? A good question, which we will solve later in this article. For now, let's concentrate on libvirt.

In theory, you could just create and manage your virtual machine in the CLI with a very low level software like Quick Emulator (QEMU). But because QEMU works very closely with KVM, it is also very complicated. You would have to spend days of reading through the QEMU documentation to understand what you need to do. Which we of course don't want to do. So, what do we do? Exactly! We abstract all the complicated parts away. This leaves us with exactly one very important abstraction: libvirt. Libvirt sits on top of the KVM and provides a convenient way to manage virtual machines and other virtualization functionality without interacting too much with those lower level systems.

Introducing libvirt

As I said, libvirt abstracts away the complexities of the hypervisor. There are several benefits to that. First, no matter what hypervisor your system uses, libvirt can communicate with it. Second, and more importantly, there are tools that sit on top of libvirt, for example virsh, virt-manager, and virt-clone. Those tools are specifically designed for usability, while still maintaining a high level of control. The documentation is clean and you don't have to read too much to get started with your first VM.

Let's quickly summarize the tools to give you a rough overview:

• virsh: An interactive shell, and batch scriptable tool for performing management tasks on all libvirt managed domains, networks and storage. This is part of the libvirt core distribution.
• virt-manager: A general purpose desktop management tool, able to manage virtual machines across both local and remotely accessed hypervisors. It is targeted at home and small office usage up to managing 10-20 hosts and their VMs.
• virt-df: Examine the utilization of each filesystem in a virtual machine from the comfort of the host machine. This tool peeks into the guest disks and determines how much space is used. It can cope with common Linux filesystems and LVM volumes.
• virt-clone: Allows the disk image(s) and configuration for an existing virtual machine to be cloned to form a new virtual machine. It automates copying of data across to new disk images, and updates the UUID, MAC address, and name in the configuration.

There are of course a lot more tools, each having his own purpose. But those are the ones I use most often.

But why are we not using something commercialized, like VirtualBox? For the same reason most developers don't use Windows: It is a commercialized platform with its own ecosystem and a company that sits behind it. Just like Windows, it takes away a huge amount of decisions for you. Of course, this has upsides (especially for beginners), but also major downsides.

Why not commercialized platforms?

The first downside is the decreased learning effect with a commercialized virtualization platform. You don't have to know what a hypervisor is, how to set up a network, or how to manage your images correctly. With libvirt, you have to know all this stuff, which makes you profoundly better at system administration overall.

The second one is vendor lock. You are bound to a commercial company, and if they make a decision you don't like, you have no option than to either change your tech stack or accept those changes. That is not a problem with libvirt, because libvirt is open-source. Even if you wanted to use some hypervisor other than KVM, you could do that. Libvirt supports all kinds of hypervisors without a doubt.

And the biggest downside is the lack of control. Software like VirtualBox or VWware do not have CLI tools and are operable via a GUI only, which means you don't know where the images or configuration files are saved. Quite frankly, you don't really know where anything is saved, and even if you did, it would probably not benefit you very much. The decrease in control is massive, and it is also against one of the foundational principles of Linux: Everything is a file. With libvirt however, you get exactly that. A dedicated folder under /var/lib/libvirt where everything you need is saved, from ISOs to all of your images and configurations. And the best thing, it is all accessible through the terminal.