Live data from Hacker News

VMware Workstation Shifting from Proprietary Code to Using Upstream KVM

phoronix.com

21–30 of 43 posts

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

#21

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.

Virtualization (Hyper-V) can also be enabled, without enabling the Hyper-V Manager or WSL2 Windows Components, if the "Core Isolation" security setting is enabled.

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

#22

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.

The biggest telltale for me is that hyper-v and wsl breaks anything that uses the ethernet mac as part of a host-id, and mobaxterm is unable to run it's X11 server because something about the hyper-v virtual ethernet screws it

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

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

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

#24

Earlier quoted context omitted.

I believe (IANAL) the implementation of KVM is GPL because it's part of Linux, but that's not viral into user space.

I'm no expert on licensing but I seem to remember GPL requires making available source if using and if the GPL project is modified, though I could be entirely mistaken.

They’re making modifications to kernel code, which they’re upstreaming. They don’t need to open anything that’s on the user side of the syscall interface.

There’s plenty of closed source software that runs on Linux, VMware workstation included.

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

#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 make it happen.

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

#26
I think this is great, at least on a personal level.

I've been running esxi to host my home infrastructure for many years. But Broadcom took that away.

As such, I've been looking around for a replacement, and if KVM can now support VMWare VMs natively, that will make my migration process a lot simpler.

Or am I missing something important?

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

#28
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…

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

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

#29
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…

Why pay when better code's free?

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

Post reply on HN