VMware's biggest problems remain its lack of product cohesion and complexity relative to its cost, and while their recent conference suggested they're working to address these concerns, I worry it's about half a decade too late for it to be of value. Aria should have been a single product suite and appliance when they pivoted to public cloud, and vRealize Automate shouldn't have been so overly complex as to require professional services for deployment and maintenance. NSX seems powerful on the surface, but really only seems to thrive when the network team either relies upon it directly, or gives you a widely trunked subnet to work with and carve out. vSphere and ESXi are excellent stalwarts, but they're not as usable/automation-friendly as they should be in the modern era of IaC. Pre-Broadcom, VMware's strength was its ubiquity and core feature set for VMs relative to its pricing; post-Broadcom, not so much.
As for the alternatives, I'm not really sold on any of them from commercial vendors.
* Nutanix has never turned a yearly profit, doesn't support commodity hardware very well (especially if you want the full feature set), and is already expensive on its surface. The pivot towards cloud-hosted services in lieu of on-prem services suggests it's trying to emulate larger and more successful competitors, rather than focusing on its core business strategy (HCI). It's a shame, because if they went the VMware route (software only on commodity hardware), I think they'd be more successful.
* Virtuozzo was the best commercial competitor to VMware on paper, but I never got to do a proper PoC. They're more focused on consumption-based services and XaaS, which is a plus, but I'm cautious endorsing them further as I have no direct experience with them - though I did suggest a PoC at the time, to explore their IaaS and PaaS suites.
* OpenShift, while a very neat tool (VMs managed the same way as Kubernetes, huzzah!), doesn't really fit modern Enterprise needs either. I applaud any tooling that tries to make infrastructure scalable like containers are, but Enterprise workloads remain "VM first" for the most part, which OpenShift isn't really aiming for. If you're already working mostly with containers, I'd strongly suggest evaluating OpenShift, but most companies aren't, and Red Hat/IBM is very focused on selling VM-heavy customers on this container transition despite most of our workloads not supporting containers at all, and those that are available as containers often have strong warnings against orchestration support with K8s/OpenShift.
* Microsoft's own stack is kind of a known quantity that I'd really only recommend if you're already a huge Microsoft customer, or rely heavily on MSPs/outsourced labor to support it. If you're not already on Microsoft, there's no reason to switch to it.
* Proxmox was considered, but didn't make it into my final proposal due to prior evaluations not finding it Enterprise-suitable.
* Red Hat Cockpit + KVM is surprisingly powerful! It'd be my default recommendation for SMBs, as RHELS pricing is fairly comparable to what vSphere licenses used to be, and once your engineers are onboarded into the world of Linux, they can convince you to migrate distros to something cheaper without significant disruption.
When looking through free/Open Source projects, I initially narrowed it down to two:
* Apache CloudStack was my 1st choice in my research, and the PoC was great. The initial buildout can be annoying, as it's typical Apache faire (in my experience anyway) of multi-page-manuals for a "quick start", but once the initial manager is up and running, the rest moves pretty quickly.
* OpenStack was considered, but its complexity and composition of dozens of individual projects made it untenable to support in our environment.
* OpenNebula was not considered at the time, but I've been looking into it on my downtime and considering my own PoC, since I dislike Proxmox for my homelab.
My instincts tell me that we're a few years out from a "great reshoring" of workloads into more appropriate placements: companies reluctant to move to public cloud will do so for customer-billable workloads because they can have an easier time judging/fixing margins on it and scaling to demand, while Enterprise and stable workloads will likely move back on-prem where sovereignty and security are paramount and cost savings can be achieved through longer hardware lifespans. In that context, nobody does a particularly good job of creating a "Universal Cloud" abstraction layer to free engineers from juggling dozens of APIs, CLIs, codebases, and pipelines for each specific vendor or workload; not even Kubernetes does this well, and it's arguably the best presently-available technology suited to cross-cloud management and orchestration. Broadcom jumped the gun on price increases, because given another year or two of product improvement and shifting landscapes of both technology and geopolitics, they'd essentially have a captive audience to squeeze for higher margins; instead, we have ample time to consider alternatives that are quite comparable to VMware in capabilities, and often substantially cheaper to boot.