Red Hat Woos VMware Shops with OpenShift Virtualization Engine
26 comments
·January 16, 2025whalesalad
NexRebular
Or if you'd like to help preventing linux monoculturalization of datacenters, MNX Triton or vanilla SmartOS are very good options too.
yjftsjthsd-h
My impression, strengthened by https://wiki.smartos.org/managing-instances-with-vmamd/#usin... , is that SmartOS preferentially operates at the per-host scale, which is probably a disadvantage in a datacenter setting. (I don't know enough about MNX Triton to comment)
whalesalad
The cool thing about proxmox is that it is - again - "just debian" so there is really no vendor lock-in. Yes they do have commercial support/update subscriptions but the community offering is open (https://github.com/proxmox). So I do not worry too much about lock-in or monoculturalization. At the end of the day it is a wrapper around fundamental components of Linux. They do not have any proprietary secret sauce that would F you down the road.
Correction I see now that the projects you reference are Solaris based. I am down with that cause too - but if you are a BSD/Solaris shop expect to do a lot of things on your own. The linux virtualization space is substantially larger (not necessarily suggesting it is better...)
throw0101c
> If I were building a datacenter today I would go with proxmox.
I use Proxmox as well in a small-ish deployment, but have also heard good things with Xcp-ng.
At a previous job used OpenStack.
null
antithesis-nl
Well, the Enterprise-hypervisor market is certainly wide open right now, due to Broadcom turning the financial screws on VMware customers hard. There are, broadly, two categories of potentially-profitable VMware customers up for grabs:
-Large enterprises that previously purchased hardware-with-accompanying-VMware-licenses from OEMs like Dell-EMC: Broadcom refused to even honor pre-acquisition license keys from these sources, leaving many private data centers in the lurch, unless they paid a huge premium for a new Broadcom-originated annual subscription (whereas the original key was one-off)
-Service providers with an ongoing "small-percentage-of revenue per year, payable in arrears" agreement, that were suddenly forced into a "hard vCPU and vRAM limit" subscription, payable for at least 2 years upfront.
However, the magic word for both customer segments is "vMotion", i.e. live-migration of VMs across disparate storage. No OSS and/or commercial (including Hyper-V) solution is able to truly match what VMware could (and can, at the right price) do in that space...
lenerdenator
> However, the magic word for both customer segments is "vMotion", i.e. live-migration of VMs across disparate storage. No OSS and/or commercial (including Hyper-V) solution is able to truly match what VMware could (and can, at the right price) do in that space...
Someone's gonna start working on that soon. Necessity is the mother of invention.
To me, this will be the UNIX wars moment for virtualization.
Originally, UNIX was something AT&T/Bell Labs mainly used for their own purposes. Then people wanted to use it for themselves. AT&T cooked up some insane price (like $20k in 1980s money) for the license for System V. That competed with the BSDs for a while. Then, some nerd in a college office in Finland contributed his kernel to the GNU project. The rest is history.
UNIX itself is somewhat of a niche today, with the vast majority of former use cases absorbed by GNU/Linux.
This feels like an effort by Broadcom to suck up all of the money in the VMWare customer base, thinking it's too much of a pain in the ass to migrate off of their wares. In some circumstances, they're not wrong, but there's going to be teams at companies talking about how to show VMWare the door permanently as a result of this.
Whether Broadcom is right that they can turn a profit on the acquisition with the remaining install base remains to be seen.
tart-lemonade
Third is academia. Even with a marginal academic discount, it doesn't come close to offsetting the price hikes. When the choice is between slashing personnel budget and minimizing the usage of/completely migrating away from VMware before the next renewal, there's really no choice in the matter, especially with the difficulty of firing employees.
SteveNuts
Hashicorp has some Nomad drivers for Qemu and a beta version that uses libvirt. However it's fairly immature and lacks a lot of features they would need to be competitive there.
Since IBM already has OpenShift I'm not sure how much time and effort they want to put into Nomad virtualization, but I'd love it as an alternative to Kubernetes.
noja
What can VMware do in this vmotion space?
The docs says open source can do a live migration, see https://www.linux-kvm.org/page/Migration and https://docs.redhat.com/en/documentation/red_hat_enterprise_...
trebligdivad
libvirt+qemu can do live migration across disparate storage; I know quite a lot of people want to use it. I'm curious in which ways you find the vMotion stuff does well with that.
zellyn
I think Oxide's stuff does live migration, but I don't know how well it runs on non-Oxide hardware.
houseofzeus
I think most of these solutions including OpenShift Virtualization, Hyper-V, Proxmox, etc. do live migration. What the previous post is talking about is some of the more advanced VMware live migration features like storage live migration and cross-cluster live migration and some of the automations layered over the top of them.
antithesis-nl
As far as I can tell, Oxide is all about compute, not storage -- i.e., as long as you can guarantee a stable storage layer, your Oxide racks will be fine.
VMware used to go a bit further, in that they allowed your compute nodes to fail and/or your storage nodes to fail, without adverse effects.
If Oxide can do that, out-of-the-box, right-now, they'll be having a field day. Otherwise, my reservations about Oxide's business model remain...
zellyn
I _think_ their storage layer is fault tolerant. Not sure though. Hopefully one of them will weigh in here.
wesapien
vMotion is about host failure. If a blade server dies, the vms can be spun up on another blade. Storage is same.
blown_gasket
You're thinking of high-availability, which registers the vmx file of the VM to a physical server that isn't dead, then powers the VM back on. Whereas vMotion is either a cold or live-migration of the VM + memory state (if the VM is powered down, there is no memory state to migrate).
antithesis-nl
> vMotion is about host failure
No? It's also about load balancing and draining compute/storage resources in preparation for maintenance.
Most pertinently: as long as your alternative doesn't cover any vMotion use-cases, customers will remain 'in talks' with Broadcom...
lenerdenator
What're the FLOSS technologies underlying OpenShift? Sounds like KVM?
natebc
Openshift is Kubernetes+.
Openshift Virtualization Engine is kubevirt (aka kvm/libvirt).
lyarwood
https://github.com/kubevirt specifically for OpenShift Virtualization
samcat116
Probably kubevirt if I had to guess (which would then use KVM under the hood)
houseofzeus
Yes you are correct, it is kubevirt and leveraging KVM as the hypervisor coupled with the QEMU/Libvirt userspace pieces.
whalesalad
everything ultimately boils down to kvm or qemu, usually
mjtechguy
Former RedHatter here. This is a strong move on their part. I am definitely going to be checking this out.
Up until now I have been using Harvester (https://harvesterhci.io/) from Suse/Rancher and it’s based on similar concepts (KVM and kubevirt).
It works well but there are bugs and key features that are missing that would make it a true VMWare replacement.
If I were building a datacenter today I would go with proxmox. It's "just debian" under the hood and can be customized and controlled a multitude of ways (UI, CLI on the box, Terraform, API, etc)