>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.
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.
> 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.
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.
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.
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.
> Boadcom is selling VMware’s End-User Computing (EUC) Division to KKR for $4 billion... This includes its Horizon desktop and application virtualization platform, and Workspace One unified endpoint management platform.
AIUI they already had to do something similar on Windows. Enabling certain features causes Windows to boot itself inside Hyper-V, and VMwares own hypervisor can't run nested under the Hyper-V hypervisor, so VMware gives up and runs its guests directly on Hyper-V instead.
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.
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
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.
Having used Workstation, the graphic performance inside its GUI is really nice, it's better than anything else on the market by a far margin. It performs better than virt-manager/qemu on Linux.
Could this move require VMWare/BC to release source code that could improve qemu/virt-manager? KVM is GPL if not mistaken.
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.
off topic, but has anyone succesfully registered their Workstation Pro single user license with broadcom? I followed the instructions they send to my email like a month ago, but it still says on the broadcom portal that i am not eligible to download latest version despite me having a valid license.
context: Broadcom has made Pro free for private users but you still need to register with them to download it.
Sign up on their portal with a new burner email account and use that to request the license. Their site is totally broken for existing users and you’ll just end up going in circles with their support.
I didn't have any trouble, although I have owned full versions of Workstation and Fusion in the past. Having said that, their licensing portal is awful and i wouldnt be surprised at all if things were getting lost somewhere in the back end.
Broadcom licensing site is a disaster. The usability is terrible; took me an hour going in circles, but eventually I was able to find where to click. It was something completely unintuitive. But it works. Maybe. Sometimes.
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.
Its worth noting that Workstation and ESXi formats are essentially different anyway, traditionally you needed to use VMware converter to convert between the formats. Pretty sure KVM has supported the VMware disk formats forever so you probably can already migrate the VM's without too much work (just installing a few drivers inside the guest OS etc).
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.
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.
>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.
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.
> 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.
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.
>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.
Why pay when better code's free?
Plus KVM is GPL right? That means more open source code (albeit spaghetti, given the origin)
VMware Workstation wasn't part of the end-user computing division spinoff to KKR?
https://www.sdxcentral.com/articles/news/broadcom-unloads-vm...
> Boadcom is selling VMware’s End-User Computing (EUC) Division to KKR for $4 billion... This includes its Horizon desktop and application virtualization platform, and Workspace One unified endpoint management platform.
AIUI they already had to do something similar on Windows. Enabling certain features causes Windows to boot itself inside Hyper-V, and VMwares own hypervisor can't run nested under the Hyper-V hypervisor, so VMware gives up and runs its guests directly on Hyper-V instead.
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.
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
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
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.
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.
Having used Workstation, the graphic performance inside its GUI is really nice, it's better than anything else on the market by a far margin. It performs better than virt-manager/qemu on Linux.
Could this move require VMWare/BC to release source code that could improve qemu/virt-manager? KVM is GPL if not mistaken.
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.
Wouldn't KVM be part of the kernel interface to userspace? The emulated devices aren't really part of KVM, are they?
I was thinking due to modified code and copyleft/GPL it could force copyleft on Workstation, but I may have misunderstood how it works.
I wonder how this will work on Windows Workstation hosts?
off topic, but has anyone succesfully registered their Workstation Pro single user license with broadcom? I followed the instructions they send to my email like a month ago, but it still says on the broadcom portal that i am not eligible to download latest version despite me having a valid license.
context: Broadcom has made Pro free for private users but you still need to register with them to download it.
Sign up on their portal with a new burner email account and use that to request the license. Their site is totally broken for existing users and you’ll just end up going in circles with their support.
I didn't have any trouble, although I have owned full versions of Workstation and Fusion in the past. Having said that, their licensing portal is awful and i wouldnt be surprised at all if things were getting lost somewhere in the back end.
Broadcom licensing site is a disaster. The usability is terrible; took me an hour going in circles, but eventually I was able to find where to click. It was something completely unintuitive. But it works. Maybe. Sometimes.
Wouldn't that violate GPL?
It looks like they are upstreaming the kernel side changes, I don't see why the usermode side couldn't be proprietary?
Maybe not, but they do have a history of poor behavior:
https://www.zdnet.com/article/linux-developer-abandons-vmwar...
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?
Its worth noting that Workstation and ESXi formats are essentially different anyway, traditionally you needed to use VMware converter to convert between the formats. Pretty sure KVM has supported the VMware disk formats forever so you probably can already migrate the VM's without too much work (just installing a few drivers inside the guest OS etc).
Seems like everyone is switching from vmware to kvm - including vmware.
I wonder if they’ll stop trying to fleece their remaining customers as much.
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.