Why have I migrate from VirtualBox to qemu + libvirtd

tl;dr : Rolling release is not a good idea, it can break your VirtualBox. You can migrate to qemu (libvirtd) + virt-manager + xfreerdp if you have a working .ova backup.

I’ve been using Linux (or GNU/Linux or GNU+Linux if you’re that type of person…) since 2012. I started with the usual suspects: Ubuntu (12.04 if I recall correctly). I tried really hard to use Unit, then recently GNOME, but neither of them was right for me. I always ended up using KDE - or for a few years actually cinnamon with Linux Mint. In 2019 July I wanted to try something completely new (but still with KDE), so I moved to openSUSE Tumbleweed rolling release.

I failed with the first installation, more specifically I screw up my system with a wrong NVidia driver (and that was the point in my life when I could agree with Linus 100%). Fortunately, I have an Ansible role to reinstall almost everything from scratch, and that’s what I did. And this time I completely left out nvidia from the picture.

So I’ve been using Linux as my daily driver for 8+ years now, but every now and then I need a Windows machine around, as well. This is because vendors still doesn’t support Linux as much as they should. I mean this is the “Dev(Sec)Ops era” for God’s sake…

So to get to the actual topic. A rolling release is probably not the best choice for a stable workstation setup. I mean it is great, if your life does not depend on it, and you want to play with the latest and greatest version of everything. But things can break, and when they break is usually when you least have time to deal with that.

I have to use Citrix Receiver to be able to connect to my company workstation. If you check the website you will see that they’re supposed to support all major Linux distribution (RHEL, Ubuntu, SUSE). I have tried Fedora 31, Ubuntu 18.04, openSuse Tumbleweed and Leap in a VirtualBox, as well. None of them was working, I got weird SSL errors, and after googling around I found the intended solution for that, but those 1, 2, 3 failed me, as well.

So I chose the best worst option: have a Windows 10 running in VirtualBox. It’s a shame, I know, but sometimes being able to work is more important than spending hours/days solving something which might break in a next update. This worked relatively well for a few months, then at the end of January some of the main Tumbleweed rolling upgrade completely crashed VirtualBox for me. I was no longer able to start any type of VM at all.

Note to myself: openSuse is great for a daily driver, but for a workstation I should stay on Leap and not Tumbleweed… My next installation will be definitely Leap…

So here is the situation, and I have to solve it. I have had a working backup of my Windows 10 in .ova format, so I searched for possible migration solutions. I also wanted to try out Gnome Boxes for a while now, so this seemed a good opportunity. But in the end Boxes wasn’t good for me (for a reason I can not recall, maybe I haven’t found easy ova migration solution and I just wasn’t up to more search).

So in the end I decided on libvirtd with virt-manager. I found online how to convert my .ova to .qcow2:

1
2
3
4
5

$ # First we have to simply untar the ova file
$ tar xvf Windows10_VM_backup.ova

$ # then we can use qemu-img to convert the vmd file to qcow2
$ qemu-img convert -O qcow2 Windows10_VM_backup1.vmd Windows10_VM.qcow2

Then I just had to make sure all the related services are working + adding my user to the libvirt group so it won’t ask root password every time when I open virt-manager

1
2
3

$ sudo virsh net-autostart default
$ sudo systemctl start libvirtd
$ sudo usermod -aG libvirt myuser

And the last thing: I have a multi monitor setup and according to the official documentation + forums I should be able to use the spice protocol. Of course, it didn’t worked for me… So next idea: let’s use Remmina to connect my local Windows 10 VM using RDP protocol.

And again, the universe is against me. I was not able to connect, because I have no clue what credentials the RDP expects from me. I configured a default user during Windows 10 installation + something which Microsoft now calls PIN code instead of password. I tried with the combination of these and I was not able to log in. Okay… no problem I have created a new Windows user, with a password, added it to the allowed RDP users list and I was good to go. Except I was not able to easily configure Remmina to use 2 of 3 monitors…

Google and xfreerdp for the rescue!

This is how someone can list his/her monitors:

1
2
3
4
5

$ xfreerdp /monitor-list
      * [0] 1920x1080   +0+118
        [1] 1280x1024   +3840+312
        [2] 1920x1080   +1920+0

And this is how you can connect with xfreerdp using specific monitors with full screen:

1

$ xfreerdp /multimon /monitors:0 /u:rdpuser /v:<ip_or_hostname_of_target>

So far I am really satisfied with my results. With VirtualBox I always had to manually rearrange my virtual monitors to the correct physical monitors. With xfreerdp I no longer have this issue.