Introduction

Previously I have talked about how we can use Vagrant to make managing virtual machines easier. You can read about this article here: Let’s Use Vagrant to make Virtualbox less Tedious.

While there are many types of virtualization and containerization techniques and tools available when writing this post, I’m specifically talking about virtualization and not containerization.

Virtualization vs Containerization

Newcomers might get lost when they learn about these things and don’t know when to use what. These buzzwords might include Docker Containers, LXC (Linux Containers), Virtual Machines, Vagrant, VirtualBox, VMWare, etc.

To let you be more clear, let’s divide all of the things into 2 categories:

1. Containerization
2. Virtualization

Talking about their similarities, they both provide some kind of isolation from the host system. This gives us the ability to mess around the guest OS more confidently knowing that we can also spin up a new one if something goes wrong.

Containerization

What has made containers so popular today is its low overhead. What I mean by that is, that every containerization engine, say LXC or Docker, etc. uses the host systems’ kernel. It is half the work/overhead needed from virtualization. If what I’m saying does not make sense, this article about User and Kernel space will help a bit.

In terms of use cases, containers are good for:

1. Quick test or development work. Not that you can’t do this on virtual machines, but this one is lighter.
2. Deployment using Docker, Kubernetes or other orchestrator

This article is not about containers, so I’ll stop blabbering about it here.

Virtualization

Virtualization has been longer than containerization if I am correct. The first thing I did as a consumer was to run VirtualBox on my Windows machine.

Virtualization goes a bit deeper than containers in terms of isolation. It does not share kernel space with all its virtual machines. It can affect things in positive and negative ways. Negatively because the startup time is longer than containers. Positively because both the host and the guest system are more isolated from each other. Meaning that there is less chance of malicious programs lurking in your host system if things aren’t handled tightly.

Well, I’ll not go deep into the explanation. Various articles and videos explain that. I’ll link a few here:

• Virtualization vs. Containerization in System Design https://www.geeksforgeeks.org/virtualization-vs-containerization/
• Containers vs VMs: What’s the difference? https://www.youtube.com/watch?v=cjXI-yxqGTI

This article is more about my personal experience of switching from one virtual machine manager to another, but still using Vagrantfiles to manage the VMs maintaining the infrastructure as code.

Kernel-based Virtual Machine

Kernel-based Virtual Machine (KVM) has been as long as 20 years from now. And I have only recently known about it. Both KVM and VirtualBox can work in conjunction. But it is out of the scope of this article.

KVM is kind of an API and we need a daemon (libvirtd), and a client (virt-manager) to use it. This video: https://www.youtube.com/watch?v=BgZHbCDFODk explains how to set up and manage VMs using the GUI. Although the instructor uses an Ubuntu based system. There should be no issue in following your distro’s manual.

Running Linux Distro on KVM with Vagrant

You don’t need virt-manager to work with the VMs as it is similar to VirtualBox’s GUI. But it’s good to have if you feel lost.

The important part for Vagrant to work with KVM is the libvirtd. It’s the daemon we talked about in the last section. It’s like the containerd we have in the Kubernetes/Docker world.

Next, let’s see how can we convert our VirtualBox-based Vagrantfile to KVM.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

Vagrant.configure("2") do |config|
  # The most common configuration options are documented and commented below.
  # For a complete reference, please see the online documentation at
  # https://docs.vagrantup.com.

  config.vm.box = "debian/bookworm64"
  config.vm.box_check_update = false
  config.vm.network :public_network, bridge: "enp4s0", ip: 192.168.122.11
  config.vm.define "proteus" do |node|  # the string provided here appears in vagrant status
    node.vm.hostname = "proteus"  # This appears in your router's host listing, and in the VM itself

    # Provider-specific configuration so you can fine-tune various
    # backing providers for Vagrant. These expose provider-specific options.
    node.vm.provider "virtualbox" do |vb|
      vb.name = "proteus"  # This appears in the VirtualBox UI
      vb.memory = 4096
      vb.cpus = 2
    end
  end

  # Enable provisioning with a shell script. Additional provisioners such as
  # Ansible, Chef, Docker, Puppet and Salt are also available. Please see the
  # documentation for more information about their specific syntax and use.
  config.vm.provision "shell", inline: <<-SHELL
    apt-get update
    apt-get install -y build-essential tree bat git curl

    su - vagrant -c "git clone https://github.com/santosh/.dotfiles.git && cd .dotfiles && make install"
  SHELL
end

As you may have figured it out already, there is only one thing we need to modify i.e. the node.vm.provider. Here is a diff to the file after the modification:

1
2
3
4
5
6
7
8
9

@@ -23,8 +23,8 @@ Vagrant.configure("2") do |config|
-    node.vm.provider "virtualbox" do |vb|
-      vb.name = "proteus"  # This appears in the VirtualBox UI
-      vb.memory = "2048"
-      vb.cpus = 1
+    node.vm.provider "libvirt" do |vb|
+      vb.memory = 4096
+      vb.cpus = 2
   end

One more important change is to remove the vb.name line. This is because the name of the VM is picked up from the directory name. libvirt will throw an error if you kept the name field around. You can see the name of the VM by running virsh list --all in the terminal. virsh -c qemu:///system list --all if that does not work.

Additionally, you need to install the vagrant-libvirt plugin. You can do this by running the following command:

1

vagrant plugin install vagrant-libvirt

After you have done this, everything about Vagrant stays the same. vagrant ssh to the VM, or use the IP and private key to connect to the VM. Everything is the same. Now you know you can get rid of VirtualBox now.

Something still feels off to me. Like I’m prompted for a password when I run vagrant up. I suppose this is related to some NFS stuff going on. I’ll try to figure that out as I’m still new to KVM. If you happen to know the solution, please let me know in the comments below.

Conclusion

In this post, we have seen how we can use Vagrant to manage VMs on KVM. We have also seen how we can convert our VirtualBox-based Vagrantfile to KVM-based Vagrantfile. This is a step forward to ditch VirtualBox and use something more native to Linux.

I hope you have learned something new today. If you have any questions, feel free to ask in the comments below. I’ll try to answer them as soon as possible.