For the past six months, almost every conversation about leaving VMware has followed the same script. We spend an hour on virtual machines: where to move them, how many nodes, how to protect them. Then, at the very end, someone from development asks: “And what about Kube?” And it turns out the customer has long had a second floor — Kubernetes on vSphere virtual machines, sometimes Tanzu, sometimes several vanilla clusters that different teams built in different years.
The first floor is virtualization, the second is the container platform on top of it. The second floor gets remembered last, even though it has to move either way. In issue 09 we looked at where to take the virtual machines. This one is about what to build on top of them, which combinations of floors work, and why the automation that took years to build doesn’t disappear along with vSphere.
Ties
What leaves along with vSphere
Kubernetes on virtual machines moves easily. What’s hard to move are its ties to the platform that nobody remembers.
With Tanzu, it’s clear-cut. The separate TKG Standalone line ended at version 2.5.x, and VKS runs only on top of Supervisor inside vSphere. When vSphere goes, Tanzu goes with it, and you need to pick a replacement.
Vanilla Kubernetes is more interesting. The cluster itself doesn’t care about the hypervisor, but over the years it accumulates surrounding tooling that’s bolted to vSphere: the vSphere CSI driver, the cloud provider, a load balancer on NSX or an external ADC integrated with vCenter, node templates, and the automation that creates them. And persistent volumes sit in a format that won’t open on another platform without moving the data.
When we ask a customer to list their ties, the list is almost always shorter than reality. Everyone remembers CSI, half remember the load balancer, and hardly anyone remembers the volumes. That’s why the first step in migrating the second floor isn’t choosing a platform — it’s an inventory of the ties. Without it, migration timelines are always optimistic.
Architectures
Five ways to build the second floor
There are at least five working combinations of the first and second floors. Below are the ones that come up most often in projects.
There are at least five working combinations. Nutanix on both floors: virtual machines on AHV, containers in NKP on the same AHV. Red Hat on both floors: OpenShift directly on physical servers, with virtual machines inside it. A Nutanix and Red Hat hybrid: infrastructure and virtual machines on Nutanix, containers in OpenShift on AHV virtual machines. SUSE on both floors: SUSE Virtualization on physical servers with Rancher on top. And a Nutanix and SUSE hybrid: RKE2 clusters on AHV managed by Rancher.
There are more than five combinations: you can attach existing clusters of other distributions to Rancher, and you can build vanilla Kubernetes on any hypervisor. But these five cover most of the projects we see in banking and telecom, so we’ll go through them one by one.
Nutanix
Nutanix and NKP: one vendor for both floors
A Kubernetes cluster is created from the same console as virtual machines, and one vendor is responsible for the seam between the floors.
NKP is built on Cluster API and upstream Kubernetes: Cilium as the network layer, MetalLB for load balancing on AHV, and a CSI driver and default storage class on every cluster. Starting with version 2.17, NKP is deployed from Marketplace in Prism Central — a Kubernetes cluster is created from the same console as virtual machines. For stateful workloads, the NKP catalog includes NDK with application-level replication and recovery — the same asynchronous replication as in the previous issue, only for pods and volumes.
The main argument is the line of responsibility. If a pod doesn’t get its volume, there’s no need to figure out whose problem it is: CSI, storage, and the platform all come from one vendor. For a bank where two or three people run the second floor, that outweighs any feature list.
The limitation is just as clear: NKP’s ecosystem of certified operators is smaller than OpenShift’s. If an application vendor ships its product as an operator for OpenShift, that argument outweighs the convenience of a single console.
Red Hat
OpenShift all the way
The virtual machine becomes a Kubernetes object. For some teams that’s natural; for others it’s a change of profession.
Here the model itself changes. In OpenShift Virtualization, a virtual machine is described by a manifest, lives in a namespace, and is subject to the same RBAC and network policies as pods. For a team that thinks in Kubernetes terms, that’s natural. For administrators with a vCenter background, it’s a change of profession, not a tool upgrade.
The requirement is strict: physical servers, a separate hardware pool. Storage is either OpenShift Data Foundation on the nodes’ disks or an external array through its vendor’s CSI. For those who need only virtual machines at first, Red Hat offers the OpenShift Virtualization Engine edition — no container features, bare metal only, with an upgrade path to the full edition later. One detail that often gets missed: RHEL subscriptions for guest systems aren’t included and are purchased separately.
This option is strong when an organization standardizes on Kubernetes across the board and applications arrive as operators. It’s weak when the fleet has hundreds of classic machines running Windows and Oracle that nobody is going to rewrite.
Hybrid
Hybrid: Nutanix below, OpenShift above
The most common option in bank roadmaps. It works if you draw the line between the floors correctly.
This option shows up most often in banks’ plans for the next 2–3 years. Virtual machines move from vSphere to AHV, and scattered vanilla clusters are consolidated into OpenShift on virtual machines on the same Nutanix.
Support is not an issue. AHV is a Red Hat–certified hypervisor, and RHEL and OpenShift are fully supported on it. Since OpenShift 4.11, installation on Nutanix has been automated: the installer creates the machines itself through Prism Central. Volumes for pods come from Nutanix CSI — block through Volumes, shared file through Files.
It’s important to draw the line correctly. OpenShift here is responsible only for containers; virtual machines live on AHV and are protected with Nutanix tools. If a slide shows virtual machines “both in Prism and in OpenShift,” that’s two different architectures glued into one picture.
OpenShift here is responsible only for containers; virtual machines live on AHV and are protected with Nutanix tools.
The price of a hybrid is two support contracts and areas of responsibility divided up in advance. The Nutanix and Red Hat pairing has been well proven, and engineers at both vendors know the seam well. But tickets get resolved faster if the customer has their own specialist who understands both floors: they collect diagnostics from both sides right away and open a case with whichever vendor owns the problem area.
SUSE
SUSE: the full stack or just Rancher
The same fork as with Red Hat: build everything on physical servers, or put only the management layer on top of someone else’s infrastructure.
The full stack is SUSE Virtualization on bare metal, which we covered in issue 09: virtual machines through KubeVirt, Longhorn distributed storage. Rancher connects to it as a managed object and creates guest RKE2 clusters on its machines, while the platform itself provides them with load balancing and volumes.
The second path is Rancher alone on top of Nutanix. Nutanix offers a node driver and a UI extension for Rancher: you pick a Prism Central project, a network, and node pools, and the machines for an RKE2 or K3s cluster are created on AHV automatically. Nutanix CSI is installed from the Rancher catalog as a partner chart, and there’s a joint Nutanix and SUSE guide for the pairing.
What sets this apart from the OpenShift hybrid is its role. Rancher has lighter requirements and doesn’t impose its own application model. It shines when there are many clusters of different origins that need to be brought under one system of permissions, monitoring, and policies without rebuilding each one. With a zoo of five clusters from different years, Rancher often becomes the first step toward order, and the distribution gets chosen later.
Surrounding tooling
Storage, networking, and access
Three questions that vSphere answered by default and that the new platform needs answers to.
Persistent volumes don’t move as is between CSI drivers of different platforms — the data is moved by backup or by application replication. That’s a separate line in the migration plan, not an implementation detail.
The load balancer, which on vSphere was often provided by NSX, is on the new platform MetalLB in NKP, the built-in SUSE Virtualization load balancer, or an external ADC. Incoming HTTP traffic is worth checking right away: in March 2026 the Kubernetes community retired Ingress NGINX — the most widely used ingress controller — and it will receive no more security fixes. If you’re rebuilding the ingress perimeter anyway, it makes sense to look at Gateway API from the start.
Access is simpler: everyone supports AD integration via LDAP or OIDC, and the image registry is Harbor in NKP, built-in in OpenShift, and a standalone Harbor for Rancher.
Protection
Protecting the second floor
Manifests in Git protect the configuration, not the data.
Many people believe that because the manifests are in Git, the cluster is protected. Git will restore the Deployment and Service, but not the contents of the volume of the database that ran in the pod. An etcd backup brings back the cluster state, not application data.
Real protection is built on tools that understand both manifests and volumes: Velero and OADP built on it in OpenShift, NDK on Nutanix, and enterprise systems like Commvault, where Kubernetes is a separate workload type with its own licensing. From there, it’s the same conversation about RPO, RTO, and where copies are stored as in the previous issue, only the object being protected is a namespace with its volumes rather than a machine.
Automation
The world doesn’t end with VMware
The years invested in Terraform and Ansible don’t disappear along with vSphere.
A fear we hear at almost every meeting: years went into Terraform modules, Ansible playbooks, and image templates, it’s all written for vSphere, and it all gets thrown away in the move.
It doesn’t. Terraform describes the desired state, and a provider does the work with the platform. There’s one for vSphere and one for Nutanix — official, from Nutanix itself. SUSE Virtualization has its own provider whose versions keep pace with the platform, and Rancher is managed through the rancher2 provider. OpenShift Virtualization virtual machines are manifests, and Terraform creates them through the Kubernetes provider.
A module that creates a machine with cores, disks, networking, and cloud-init changes in the resource definition and the provider block. The logic, variables, pipeline, and approvals stay. That’s days of work, not a rewrite. The same goes for Ansible — there are collections for every platform. Argo CD and Flux don’t even notice what the cluster runs on.
The logic, variables, pipeline, and approvals stay. That’s days of work, not a rewrite.
One detail for those starting to automate Nutanix now: in the provider release planned for the fourth quarter of 2026, Nutanix is retiring the old resources on API v0.8–v3. Write against the v2 resources on top of API v4 from the start.
Automation built the right way survives a hypervisor change. Automation built on clicks in vCenter won’t — but then it never really existed.
Checklist
What to ask before choosing the second floor
Ten questions after which choosing a platform becomes a calculation rather than a preference.
Bottom line
In place of a conclusion
The second floor rarely becomes the reason for leaving VMware, but it’s almost always the reason for delay. The ties to the platform are hidden in drivers and volumes, not in plain sight.
There are at least five working options, and none of them is best in general. One vendor for both floors means fewer seams. Two vendors mean more freedom of choice and a clear division of responsibility.
If you’re planning to leave vSphere and Kubernetes is still just one line in the plan, let’s talk. We’ll start with an inventory of the ties: it’s a couple of days that saves months.