The VMware Compatibility Matrix After the Exit: What Breaks When Nobody Certifies Your Stack

Somebody on the migration team will type “vmware compatibility matrix” into a search box about three weeks after the decision to leave is made. They will land on the Broadcom Compatibility Guide, filter it down to the servers already racked in their own data centre, and find that the page works perfectly. The hardware is certified. The firmware revisions are listed. Every answer is still there.

None of it applies any more. What was being certified was never the hardware on its own. It was a relationship between that hardware and an operating system the estate is in the process of removing, and the moment the hypervisor changes, the entire lookup becomes a historical record.

The awkward part is that the matrix does not fail all at once, and it does not fail loudly. It fails in a specific order, over roughly a year, and each stage costs something different.

What the compatibility matrix was actually doing

It helps to be precise about what is being lost, because “the VMware® compatibility matrix” is not one instrument. It is two, and they answer different questions.

The first is the hardware compatibility list, published as the VMware Compatibility Guide and now, after the acquisition, as the Broadcom Compatibility Guide. It names server models, CPU series, and I/O devices, meaning storage and network adapters, and for each of those it names the specific driver and firmware version pairs that were tested. The granularity is the point. It does not say a controller model works. It says a controller model works at a given firmware level with a given driver build.

The second is the Product Interoperability Matrix, which is the software half. Which vCenter version runs with which ESXi version, which upgrade paths are supported, and which third party solutions are certified against which release. This is where the question “which vSphere release does my array’s storage provider support” actually lived, and it is the half that most exit plans forget to account for.

Then there is the part that matters most and gets discussed least. The hardware list was not advisory. vSphere Lifecycle Manager performed host level and cluster level hardware compatibility checks, comparing the firmware and driver versions actually running on a host against the certified list, and reporting the drift. The matrix was a control inside the product, not a website somebody was supposed to remember to visit.

So the real asset was never the list. It was a single accountable party who had tested the combination, published the result, and built the enforcement into the platform. That is the thing that does not survive the exit, and no destination platform hands it back in one piece.

What breaks first: the hardware is fine and nobody will say so

The first failures arrive during the build, and they are quieter than teams expect.

Start with the drives and the controllers. Your NVMe devices, HBAs and network adapters were certified against ESXi drivers. On bare metal Linux the question becomes a kernel driver question instead, and here the honest answer is favourable: mainline Linux supports commodity server hardware at least as well as any single hypervisor’s driver set, and usually better, because the driver has more users and a faster fix cycle. Most of the hardware will simply work.

“Will simply work” is not a certification, though, and the difference shows up the first time something is wrong. There is no longer a page that says this adapter, at this firmware level, with this driver, was tested and passed.

Firmware pinning is where that gap first bites. The compatibility list named exact firmware revisions because storage and network firmware carries errata, and a known bad level on a drive or an HBA is a real failure mode with a real fix. In the new stack there is no equivalent pin for most components. Nothing fails at install. What happens instead is that a drive firmware level with a documented erratum stays in production for a year because no list existed to check it against, and the resulting latency spikes get attributed to the storage layer, the network, or the application, in that order, for several weeks.

The third hardware break depends entirely on which destination was chosen, and almost nobody is told this at decision time. Red Hat® OpenShift® has a genuine bare metal hardware certification programme, with certified servers published in the Red Hat Ecosystem Catalog, so a meaningful part of the certification authority does carry over for teams landing there. Upstream Kubernetes, k3s, RKE2 and Talos have no hardware certification programme at all. That is not a criticism of those distributions, it is simply a thing they do not do, and a team that picked one of them on operational grounds has also, without discussing it, accepted full ownership of hardware qualification.

The cost of this first stage is rarely an outage. It is support ambiguity. When a node wedges at three in the morning and the server vendor asks what you are running, the answer is no longer a combination anybody certified, and the conversation gets longer.

Not sure who certifies what in your target stack? If you are mapping a vSphere estate onto new hardware and cannot get a straight answer about which party stands behind which layer, talk it through with someone who has done the mapping before. Talk to a storage architect

What breaks next: the version matrix nobody replaced

The hardware half is the half people worry about. The software half is the one that actually costs money, and it arrives later, which is precisely why it is expensive.

The Product Interoperability Matrix answered a question that does not disappear when vSphere does: can these software versions run together. After the exit that single question splits into at least four independent release calendars, each owned by a different party.

Kubernetes itself publishes a version skew policy, and it is a real contract with real limits. A kubelet may run up to three minor versions older than the kube-apiserver, a range that widened from two at version 1.28. A kubelet must never be newer than the API server it talks to. In a highly available control plane, API server instances must stay within one minor version of each other. Minor releases land roughly every four months, so this is a calendar that moves whether or not anybody on your team is paying attention to it.

The CSI driver adds a second axis. Every storage vendor publishes its own support matrix of driver version against Kubernetes version, and those matrices are not synchronised with the Kubernetes release cadence, with each other, or with your distribution’s lifecycle. The kernel adds a third, because NVMe over fabrics behaviour, multipath handling and queue management are all kernel version sensitive in ways that a CSI driver’s documentation will not always mention.

Where there was one matrix maintained by one vendor, there are now four calendars: the Kubernetes release cycle, the distribution’s lifecycle, the storage driver’s support matrix and the kernel. Nobody publishes the intersection.

The failure shape here is specific and worth naming, because it is the most common expensive surprise of the whole exit. It is the cluster upgrade that the storage driver did not support yet. It does not break at install, when the team is large, attentive and still assembled. It breaks at the first or second minor upgrade, three to six months after go live, when the migration programme has closed and the people who made the choices have moved on.

Table 1: The compatibility failure sequence, in the order it actually happens.

Who owns the question now, and what actually helps

The honest answer is that the certification authority fragments into three, and nothing puts it back together. The hardware vendor stands behind the server. The Kubernetes distribution stands behind the platform, to whatever degree it runs a certification programme at all. The storage layer stands behind its own driver against a list of platform versions. The intersection of those three is unowned, and it is now your integration responsibility. That is a real, recurring operational cost, and any vendor who tells you it goes away is selling past the problem.

What can be done is to reduce the number of axes rather than pretend they are gone.

This is where the storage layer’s own hardware requirements matter more than they look. A storage product with a narrow hardware compatibility list of its own simply reintroduces the problem you just left, one layer up: a new list, a new set of certified devices, and a new reason the hardware you own is not allowed.

Simplyblock’s backing devices are not restricted to local NVMe. Any whole Linux block device can be taken into the pool, which includes SAS and SATA behind an HBA, virtualized disks, cloud volumes, and LUNs that an existing array presents to the storage nodes. The practical effect on this specific problem is that the hardware question at the storage layer becomes a performance recommendation rather than a certification gate. The drives you already own are candidates rather than exceptions.

Two caveats have to travel with that, because without them it reads as a bigger claim than it is. Non NVMe device support is newer than the NVMe path, and local NVMe remains the production performance recommendation, so an array backed pool is best understood as a transition or asset sweating option rather than a greenfield design. And simplyblock formats the devices it takes in, which means capacity is reused but data is still migrated. The precise line is that consuming an array’s capacity is possible, while re presenting its existing LUNs non destructively is not. If you are working through that specific question, leaving vSphere without a storage refresh covers it properly.

It is worth being equally clear about what this does not fix. Removing the storage layer’s hardware list removes one axis of three. The Kubernetes version skew policy still applies to your cluster. The kernel still matters for the data path. The server vendor still has its own support position, independent of everyone else. The compatibility problem gets smaller and better understood. It does not get solved, and the teams that plan for a recurring qualification cost do considerably better than the ones that assumed the matrix was a VMware® problem they were leaving behind.

Simplyblock’s own vSAN alternative positioning has named hardware compatibility list lock in as a buyer problem for a while. This is the part of that argument that deserves stating plainly: the lock in was never only about which drives were on the list. It was about who was accountable for the answer, and that is the thing to go looking for in a replacement.

Questions and Answers

What replaces the VMware compatibility matrix after a migration?

Nothing replaces it as a single instrument, and that is the honest answer. The hardware half is partly picked up by your distribution if it runs a certification programme, as Red Hat® OpenShift® does through the Red Hat Ecosystem Catalog, and not at all if it does not. The software half is replaced by several independent matrices: the Kubernetes version skew policy, your CSI driver’s support matrix and the kernel. The most useful thing you can do is reduce the number of separate lists your stack depends on. Choosing a storage layer that accepts any whole Linux block device, as simplyblock does, removes one of them outright, which is why it is worth checking a storage vendor’s hardware requirements before its feature list.

Is the VMware hardware compatibility list the same as the interoperability matrix?

No, and conflating them is the most common planning error here. The hardware compatibility list, published in the Broadcom Compatibility Guide, covers physical components: server models, CPU series, storage and network adapters, and the specific driver and firmware versions tested with each. The Product Interoperability Matrix covers software versions: which vCenter runs with which ESXi, supported upgrade paths, and certified third party solutions. They break at different points in a migration. The hardware list stops applying the day you change hypervisor. The interoperability question survives the move and simply re forms around new products.

Does my existing server hardware still work after leaving vSphere?

Almost always, yes, at the level of it functioning. Mainline Linux drivers cover commodity server hardware well, frequently better than a single hypervisor’s driver set. The gap is not function, it is accountability and firmware discipline. You lose the published statement that a given adapter at a given firmware level was tested and passed, and you lose vSphere Lifecycle Manager’s automatic drift checking against that statement. Replace it deliberately: keep your own inventory of firmware levels, track vendor errata for the adapters and drives you actually run, and decide who owns that review.

How does the Kubernetes version skew policy affect storage?

Directly, because storage is one of the things most likely to block an upgrade. The skew policy sets the limits for the cluster’s own components, with kubelets permitted to run up to three minor versions behind the API server and never ahead of it. Your CSI driver sits on top of that with its own supported range, and the intersection of the two is the real upgrade window. When a driver lags a new Kubernetes minor, clusters sit on an unsupported version for months. Check the storage vendor’s track record of supporting new Kubernetes minors promptly, because that cadence is a recurring operational constraint rather than a one time integration detail.

Does a Ceph based platform solve the hardware certification problem?

It changes its shape rather than solving it. Ceph runs on broadly available hardware and has no restrictive vendor hardware list, which genuinely helps, and Ceph remains a good option when performance is not the main goal. What it adds back is a substantial operational surface of its own, with its own version compatibility concerns between the cluster, the CSI layer and the platform, and a tuning burden that scales with how much performance you are trying to extract. The certification question becomes an expertise question, which for some teams is a good trade and for others is the same cost wearing different clothes.