Why use VirtualBox over KVM on Linux hosts? Considering deprecation of VirtualBox on Linux hosts.

References for VirtualBox licensing issues here:

Whonix ™ Virtualization Platforms


On VirtualBox security, ticket VirtualBox 5.2.18 vulnerable to spectre/meltdown despite microcode being installed does look really bad due to non-responsiveness and non-progress.

Spectre Meltdown - Whonix

To learn more, see: VirtualBox 5.2.18 vulnerable to spectre/meltdown despite microcode being installed and the associated VirtualBox forum discussion. [2] Users must patiently wait for VirtualBox developers to fix this bug.

VirtualBox version 5.2.18 or above is required since only that version comes with Spectre/Meltdown defenses. See Whonix vulerable due to missing processor microcode packages? spectre / meltdown / retpoline / L1 Terminal Fault (L1TF) - #22 by Patrick.

Also see the following Whonix forum discussion: Whonix vulerable due to missing processor microcode packages? spectre / meltdown / retpoline / L1 Terminal Fault (L1TF)


Perhaps this feedback can be used to improve chapter Whonix ™ for KVM? @HulaHoop

1 Like

I don’t manage to reconcile those two statements. Does version 5.2.18+ have defenses or not?

I tried to follow the link but it is way too technical for me and I don’t see a clear conclusion at the end of it.

If the host was patched, does the problem in VirtualBox still exists?

It has but seems incomplete as per #17987 (VirtualBox 5.2.18 vulnerable to spectre/meltdown despite microcode being installed) – Oracle VM VirtualBox.

As per #17987 (VirtualBox 5.2.18 vulnerable to spectre/meltdown despite microcode being installed) – Oracle VM VirtualBox possibly yes.

Developer comment from #17987 (VirtualBox 5.2.18 vulnerable to spectre/meltdown despite microcode being installed) – Oracle VM VirtualBox

No, this isn’t expected. Looks like it needs dev attention (including having a look at what exactly goes wrong with specre-meltdown-checker.

It’s not only the spectre/meltdown issue, the bigger one is that virtualbox is not supported very well on most distributions.
It’s not available in Debian stable’s (Stretch) and testing’s (Buster) default repositories main, contrib or non-free. For Debian stretch you need to install it from backports and in buster you will have to wait, until buster get’s stable, thus a backports repository is created for buster.
Oldstable jessie is the only one, that has a offical package of virtualbox in the default repositories.
See here:
https://packages.debian.org/search?keywords=virtualbox

But it gets worse.
Many Linux users, especially beginners, use Ubuntu and all the other ubuntu flavors like Linux Mint.
And in Ubuntu virtualbox is available only in the multiverse repository.
Packages in multiverse are not supported by Canonical, it’s up to the community but no one is responsible for a package in multiverse, there are no maintainers of a package like in Debian, thus these packages usually get no updates at all and will have plenty of known security vulnerabilities after a couple of months of the release of a Ubuntu version.

The story is different for KVM. KVM is officially supported by Canonical and its package is in main. Main is a repository officially supported by Canonical. Multiverse and universe are not supported by Canonical, multiverse and universe usually end up in a collection of vulnerable software packages. It’s highly recommended to not use any packages of these repositories, unless you know what you are doing.

Thanks @Patrick and @Firefox that makes things clearer.
It’s not in Debian Stable because it’s being compiled with a tool that’s considered free by OSI (whatever that is) but not by FSF / Debian. Was not a priority for Oracle 6 and 4 years ago and probably not a priority now either.
Possibly still vulnerable to Spectre/Meltdown although patching the host may solve the problem. No reply from developers on that during the last 8 months.
Not many serious players in this market though. For linux, it’s either VirtualBox, KVM and Xen.

I switched completely from VBox to KVM a few months ago. I disliked it first because of a perceived complexity. VBox was more beginner-friendly.

I gave it another try, and this time I took the time to understand how to setup vbox-guest-additions-like settings like full-screen resolution and clipboard and files sharing. Virt-manager is a great tool, also user-friendly and I have no difficulty using it as I would have VBox.

As nothing would stop anyone from importing the .ova files in VBox on Linux, I guess “deprecation” here means unsupported/you are on your own?

Yes.

1 Like

Well, only advantage I’ve found in using KVM instead of VirtualBox was speed. My tests showed it to be about 15% faster. In spite of that, I found my way back to VirtualBox. Why? much easier to install, configure, update and change configuration. It is a breeze to share files between host and guest (something I spent days trying to understand and make work on KVM – but never fully succeeded. This takes seconds to configure on VirtualBox. And it never fails). Same thing with pen-drive. It is a child’s play on vVirtualbox, but a pain in the neck on KVM (I never managed to make it work smoothly.)

I don’t like the idea of using proprietary code. Never did. Even when it is open source. But, it this case, I think it is worthwhile to use VirtualBox in place of KVM. Perhaps it is different if you are a IT Pro or if you have a lot of time to find the sparse and poor KVM documentation.

From the Debian wiki:

“Packages for VirtualBox are not available in Debian 10 and won’t be in buster-backports either. A recommended alternative is Virtual Machine Manager.”

If VirtualBox is not supported by Debian, it should not be supported on Debian either.

i’m somewhat sympathetic here for user friendliness, whether it’s a mount or an immutable snapshot. but, both are scriptable with kvm. it’s not “it pro” level sophistication. it’s just slightly different. and while it may not matter to many, one downside with virtualbox is the number of extra hoops one must jump trough to get it to work with secure boot. kvm works fine with secure boot without any additional tweaks. to get virtualbox working with secureboot requires more problematic hoops to jump through than getting kvm to do a shared directory.