[jchw]

Probably true, although I do still count it as a win. It's less out-of-tree kernel modules to deal with. Presumably, this also means you can use KVM/libvirt virtual machines alongside VMWare virtual machines in the future.

Now we just need Oracle to decide not to want to maintain the Virtualbox kernel modules. Seeing as someone already did most of the work of porting it, they don't even need to do a lot of work to make it happen.

[AndrewDavis]

> Now we just need Oracle to decide not to want to maintain the Virtualbox kernel modules

If I remember correctly you can already select KVM as the backend in Virtualbox. And in Windows you can use HyperV as your backend. Not sure about MacOS land.

[Nullabillity]

As far as I can tell, VirtualBox supports KVM and Hyper-V personalities for its paravirtualization, presumably to be able to reuse virtio/hyperv guest drivers. The host side still seems to require their custom kernel module.

[jchw]

Yep. That said, Virtualbox still has some advantages mostly not related to the actual hypervisor and more related to the UI and other emulation details, so I use this patch to use Virtualbox on top of KVM on my machine.

https://github.com/cyberus-technology/virtualbox-kvm

From my PoV, it mainly is just missing support for more networking options. It's said that it isn't tested much on AMD, but I'm using it on multiple different AMD boxen with no issues.

[ch_123]

Under Apple Silicon, you are forced to use the hypervisor which is inbuilt in macOS. Both VirtualBox and VMware use said hypervisor, and do not have the original backends for macOS on Apple Silicon.

[tonyedgecombe]

>Probably true, although I do still count it as a win.

I prefer a bit of competition.

[jchw]

Linux KVM has plenty of competition: for one thing, there's Xen, but also the integrated hypervisors from other operating systems, including Hyper-V, bhyve, macOS Hypervisor, etc.

But rather than have multiple companies working on incompatible implementations of the virtual machine monitor component, it's better if possible for them to standardize on a single one. KVM is not a full virtualization solution, after all. Look at this patch: it may very well be all that is needed for VMWare Workstation to use KVM internally. That ought to demonstrate how these kernel modules are effectively interchangeable.

Virtualbox and VMWare will still act and feel the same when they use KVM internally, just like they do on Windows when they use Hyper-V internally, or macOS when they use the Hypervisor framework internally, or like Virtualbox-KVM already does, some networking omissions aside.

The benefits of sticking to KVM are clear. If anyone has a problem in production, fixing it benefits every KVM user. If anyone wants to migrate between virtualization solutions, it's much easier when you can use multiple of them at the same time, whereas today you can't boot any of upstream Virtualbox, VMware, or KVM virtual machines at the same time on Linux.

(edit: And the benefits of not using out-of-tree kernel modules is even clearer; out-of-tree modules taint your kernel, preventing you from reporting bugs upstream, often prevent you from being able to upgrade to the latest kernels, are a pain to deal with when using secure boot, etc.)

KVM and hardware virtualization solutions can be useful for more than just virtualization, too; unlike Vbox and VMware, KVM offers a general interface for using these processor features. For example, there are some cases where it might be useful for Wine.

So personally I think it's fine. KVM is just a foundational part of a virtualization solution, and there's plenty of competition in the overall space.