Live data from Hacker News

VMware Workstation Shifting from Proprietary Code to Using Upstream KVM

phoronix.com

31–40 of 43 posts

Re: VMware Workstation Shifting from Proprietary Code to Using Upstream KVM

#31

Earlier quoted context omitted.

Windows basically always runs inside a hyper-v VM these days.

Only if Hyper-V is enabled and/or WSL2 is installed. And Hyper-V is a prerequisite for WSL2. If hyper-V is not enabled, then you’re running on metal. You may notice a longer than normal reboot time when enabling or disabling Hyper-V compared to a normal reboot, and this is why; you’re moving from running on silicon to running in a privileged management VM or vice versa.

Or enabled the security features anyone should be running in first place, thus yeah since Windows 11, it is for all practical purposes.

Same applies to XBox Windows flavour.

Re: VMware Workstation Shifting from Proprietary Code to Using Upstream KVM

#32
post #25

Earlier quoted context omitted.

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 ma…

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

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.

Re: VMware Workstation Shifting from Proprietary Code to Using Upstream KVM

#33
VMware Workstation/Fusion team has always been underfunded and understaffed. Every year, they release a reskinned version with a few minor features to justify the cost to buyers. They really don't have the cycles to maintain a competitive product that would include major changes or large feature advancements. (Fusion is basically a dead product because it can't do performant x86_64 emu/v12n on arm Macs. The closest replacement is UTM, based on QEMU, but it's really slow.)

The problem this introduces is it probably won't work with existing customer tooling built for W/F, won't work with open-vm-tools, and will be incompatible with existing VMs. IOW, this will likely have a net negative impact on users.

Sad.

Re: VMware Workstation Shifting from Proprietary Code to Using Upstream KVM

#34

VMware Workstation/Fusion team has always been underfunded and understaffed. Every year, they release a reskinned version with a few minor features to justify the cost to buyers. They really don't have the cycles to maintain a competitive product that would include major changes or large feature advancements. (Fusion is basically a dead product because it can't do performant x86_64 emu/v12n on arm Macs. The closest r…

Made the mistake of UTM on my dev machine in a job up to about a year ago.

It might be better now, but it wasn't ready at that point, I'll probably check it out again in a few years time.

The speed for Arm Linux on a MacOS host was OK, but the hard locks I was hitting multiple times a day, not so much.

Re: VMware Workstation Shifting from Proprietary Code to Using Upstream KVM

#35
post #31

Earlier quoted context omitted.

Only if Hyper-V is enabled and/or WSL2 is installed. And Hyper-V is a prerequisite for WSL2. If hyper-V is not enabled, then you’re running on metal. You may notice a longer than normal reboot time when enabling or disabling Hyper-V compared to a normal reboot, and this is why; you’re moving from running on silicon to running in a privileged management VM or vice versa.

Or enabled the security features anyone should be running in first place, thus yeah since Windows 11, it is for all practical purposes. Same applies to XBox Windows flavour.

IOMMU is my borrow checker

Re: VMware Workstation Shifting from Proprietary Code to Using Upstream KVM

#36

Earlier quoted context omitted.

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

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.

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.

Re: VMware Workstation Shifting from Proprietary Code to Using Upstream KVM

#37
post #25
post #23

>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 smal…

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 ma…

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

I prefer a bit of competition.

Re: VMware Workstation Shifting from Proprietary Code to Using Upstream KVM

#38
post #25

Earlier quoted context omitted.

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 ma…

>Probably true, although I do still count it as a win. I prefer a bit of competition.

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.

Re: VMware Workstation Shifting from Proprietary Code to Using Upstream KVM

#39
post #8

Earlier quoted context omitted.

This looks like a cost saving maneuver to me. Why do the heavy innovation lifting on your own proprietary virtualization technology when you can have the community do it for you, for free? You can layoff several high-cost developers and stop innovating while extracting as much money from your current customers as possible.

If it's good enough for every cloud but Microsoft Azure, why pay to have your own bespoke virtualization platform with its own errata?

I think monocultures in technology are dangerous and stifle innovation and its how we end up with the situations like nearly every browser is now built on Chromium.

Re: VMware Workstation Shifting from Proprietary Code to Using Upstream KVM

#40
post #25

Earlier quoted context omitted.

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 ma…

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

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.
Post reply on HN