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.
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
doesn’t provide us a ton of configurations compared to
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
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.
- 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
. 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 called
libvirtdand a command line utility called
However, I haven’t gotten into using
virshso 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.
Normally, trying to install virt-manager should automatically pull in libvirt components as
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.
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*"
virt-manager uses the
qcow2 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
For example, to convert an image from
vdi format to
qemu-img convert -O qcow2 -f vdi <image.vdi> <output_file.qcow2>
Other formats are also supported which can be viewed by invoking:
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
It’s evidently just a tar archive – which can be easily extracted using
There we have our
vmdk virtual disk which can easily be converted to
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 .
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
nmcli connection add type bridge ifname br0 stp no
nmcli connection add type bridge-slave ifname eth0 master br0
nmcli connection down eth0
nmcli 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.