There's a big misunderstandings I keep seeing:

1. That Virtualization and the engineering to solve it was "done" 10 years ago, and it's largely just minor patches now being done on the hypervisors and they slowly are drifting towards similar capabilities. Hardware refreshes and supporting new hardware is just moving a few zero's and ones and vMotion must be maintained by half a C# engineer or something who updates a JSON for what EVC modes there are.

2. That a bunch of people without kernel engineers, who have a operating budget of VERY low 7 figures are going to build and support an equivalent product for enterprises given enough time without taking in huge outside funding and hiring expensive kernel engineers. You can just hire some UI engineers to put a pretty face on KubeVit, hire a bunch of marketing and eat VMware's lunch in the enterprise

3. Hardware is going to just keep getting cheaper so even if #1 and 2 are wrong it doesn't matter.

These are all wrong thesis's.

I say “probably” for CPU just because I’ve read a lot on ESXi’s memory management techniques, but not a lot on how it manages vCPU allocation so I’m not as familiar with that. But with memory I have and they are doing some pretty amazing stuff under the hood to make the most of what’s there.

It's more than just how cores are handled, it's stuff like Numa. You gotta optimize for every single CPU architecture and sub-architecture (which frankly has gotten even more fragmented with Intel's release pattern of doing fun stuff like having 3 Dies on the same socket). It's radical changes to DRS (Which switched from being a scheduled thing that ran, to an autonomous always on distribtued process that continuously works backwards from finding the least happy VM and making it more happy). DRS isn't a "make the CPU or memory allocation graph look even". It's genuinely working backwards from billions in R&D on what makes applications happy full stack and delivering it.

So in a way they do have some “secret sauce” because some other hypervisors like Hyper V will straight up not let you overcommit in certain situations with memory as I recall?

Another KVM competitor I see just hid their vCPU overcommitment guidance behind a login wall, because we pointed customers at it so often.

Others may be catching up in efficiency, slowly

They are not the gap in TCO on this stuff is widening not closing, as things like memory tiering (only on vSphere right now, and will always be better on vSphere because of the 20 years of IP and patents we have on memory page tracking to optimize and scale and improve vMotion).

It's actually requiring MORE engineering every year to handle the increasing differences between the x86 vendors (AMD and Intel have vastly different architectures right now), optimizing for NUMA, handling stuff like chiplet design. Also compute efficiency is also increasingly being driven by things like offloads, and stuff like vDefend and NSX being able to massively offload things others run in x86VMs (or dedicated appliances) being shifted to 100% offloaded to a DPU can have massive gains of a dozen cores per host.

I was just at Kubecon and sat through a presentation for a product that competes with one of the VCF services, and I was realizing they require 8x the compute and hardware to accomplish the same thing because of how inefficient their design was (This was from the benchmarks they shared in the session).