[tw04]

>I'm not sure I ever envisioned VMware abandoning their proprietary virtualization code in favor of leveraging upstream KVM but in any event it's a terrific success story for the upstream KVM community.

I can pretty much guarantee this move was because they want to can all of the people maintaining the proprietary virtualization code. The odds of Broadcom making any significant upstream contributions, beyond the small bit of code they need for workstation to function, is almost 0. I guess you can call it a "win" in that there's one less competing product in the market, but I don't see it boosting KVM functionality or quality in any meaningful way.

[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.

[intelVISA]

Why pay when better code's free?

Plus KVM is GPL right? That means more open source code (albeit spaghetti, given the origin)