Background
Ever since I got into the world of Linux, I have realised that there exist these
various “rabbit holes” (as I like to call it) that I could get myself into. I
define these “rabbit holes” as the period when you spend your time into adopting
a certain technology into your workflow. Most of these workflows are sometimes
very uncommon. For example one of my first “rabbit holes” was switching to a
tiling window manager. There already isn’t a big percentage of people who use
Linux on their desktops let alone having a tiling window manager setup. One of
the “rabbit holes” that I have recently gotten into – hence the title of this
article – is switching away from VirtualBox to virt-manager. I had already seen
a lot of videos and articles about this QEMU/KVM thingy already. So it was
predictable for me to eventually pick this up.
Introduction
In an earlier blog, we have covered gnome-boxes. However, there’s
also another virtual machine manager that is quite popular named
virt-manager. While very easy to use, I have found that gnome-boxes
doesn’t provide us a ton of configurations compared tovirt-manager.
Furthermore, virt-manager also provides better performance as
compared to VirtualBox since we’re utilising KVM. In this article, I wish
to share some of my experiences and what I have learned from this
rabbit hole.
Before we get into it, though, I want to clarify a few things:
- Hypervisor: A hypervisor is a piece of software that allows us to run and
manage multiple different operating systems on a single machine. Type-1
hypervisor run on the hardware directly while the Type-2 hypervisors run on
top of an operating system installed on the hardware. - KVM – This is the low level kernel module that is responsible for translating
the CPU instructions of guest operating systems into something that the host
kernel can understand. This is basically what allows the Linux kernel to act
as a (type 1) hypervisor[1]. - QEMU – QEMU stands for Quick Emulator. It emulates various hardware and CPU
architectures. QEMU can work with KVM but it can also be used on its own
[2]. However, that imposes various performance issues as the emulation is done
entirely through software. Now, KVM by itself also can’t emulate a lot of
hardware. Therefore, the QEMU+KVM stack is most commonly used as a hypervisor. - libvirt – libvirt is an API that can be used to manage virtual machines through QEMU.
It has a daemon calledlibvirtdand a command line utility calledvirsh[3].
However, I haven’t gotten into usingvirshso that’s another rabbit hole for me. - virt-manager – Finally, this is the GUI program for managing virtual machines. It uses
libvirtfor interacting with the lower level components of our virtualization stack.
We’ll primarily interact with this as a user.
Installing virt-manager
Normally, trying to install virt-manager should automatically pull in libvirt components as
dependencies. However, qemu is an optional dependency so we need to specify it explicitly.
On Arch Linux, I needed only these two packages:
Please make sure to check that the required packages shown in above screenshot
are being pulled in during the installation on your system.
Using virt-manager
virt-manager is a GUI program. As such, its user interface shouldn’t really require a lot of explanation.
One thing to note is that you must have the libvirtd service running in order to use virt-manager.# systemctl start libvirtd
On a small note, starting libvirt also starts a few other services so I run the following
command when I’m done with using my VMs:# systemctl stop "libvirt*" "virt*"
Virtual disks
virt-manager uses theqcow2 storage format for its virtual disks. Since this
article is about migrating to virt-manager, we probably have some virtual
machines with their disks populated. Fortunately, we have the qemu-img utility.
For example, to convert an image from vdi format to qcow2:qemu-img convert -O qcow2 -f vdi <image.vdi> <output_file.qcow2>
Other formats are also supported which can be viewed by invoking:qemu-img --help
VirtualBox images also come in ova format. And you won’t find that format
listed in the help output of the previous command.
However, on inspecting an ova file:
It’s evidently just a tar archive – which can be easily extracted using tar:
There we have our vmdk virtual disk which can easily be converted to qcow2.
SSH into VMs
Whenever I created a virtual machine in VirtualBox, I would configure it to have a bridged
adapter. That way, the VM would also be on my home LAN and I could SSH into it like any
other machine. However by default, the VMs in virt-manager will be connected to the
virtual network (NAT). The IPs will be assigned internally by the hypervisor which your
home router will not know about. So when you try to ssh into the VM using that IP,
the gateway will have no clue what that IP is and hence it doesn’t work.
The way that I was able to get the router to assign an IP to my virtual machine as well
is by first creating a network bridge and then editing the network configuration of the
VM as shown in the screenshot to be of the Bridge source and when the VM boots up
it gets an IP that is accessible to other devices on the LAN.
Setting up a network bridge is well documented on sites like Arch Wiki [4].
I use Network Manager and the procedure was as simple as entering a few
commands. The bridge name is br0 and the interface assigned as a slave to that
bridge is eth0.
nmcli connection add type bridge ifname br0 stp nonmcli connection add type bridge-slave ifname eth0 master br0nmcli connection down eth0nmcli connection up bridge-br0
This way I can easily copy paste stuff to and from the VM and I also don’t have
to constantly escape the keyboard/mouse when using the VM and my host both at
the same time.
After figuring all of that out, I could finally get into using virt-manager as my primary
virtual machines manager. So that’s it for now, I hope you found this article useful.
