Rob Pankow 
Most VMware® exit guidance is written for one reader: the team with a datacentre full of virtual machines that have to become something else. Convert the disk format, map the datastore to a new storage layer, cut over the workload, repeat a few hundred times. That reader is well served, including by the post on the VMware Cloud Foundation 9 upgrade and its storage design consequences.
Teams running Tanzu Kubernetes Grid are not that reader, and the difference is easy to miss because at first it looks like good news. Their workloads are already containerised. Their storage requests are already Kubernetes objects, written as claims in manifests that a Git repository already tracks. Nothing has to be converted. A StatefulSet that runs on TKG runs on any other conformant distribution without an edit.
Then you look at what is underneath the claim, and the good news narrows. The provisioner that turned those claims into real disks was the vSphere CSI driver, and it is not a component you can carry to the next platform. It exists to talk to vCenter. Leaving vSphere means leaving the thing it talks to.
So the exit for a Tanzu estate is a rebinding problem, not a conversion problem. That sounds smaller. In some ways it is. In one specific way it is worse, because the objects that look most portable are the ones that are not.
What the vSphere CSI driver was actually doing
It helps to be precise about the mechanism, because the imprecision is where migration plans acquire their surprises.
When a pod on TKG asked for storage, the request went to a StorageClass whose provisioner was csi.vsphere.vmware.com. That class did not name a disk or a path. It named a storage policy, a vCenter construct, and handed the request to Cloud Native Storage, which is a service inside vCenter rather than inside Kubernetes.
CNS then created what VMware calls a First Class Disk: a virtual disk with its own lifecycle and its own identity, independent of any virtual machine. That independence is exactly why it worked well. A regular VMDK belongs to a VM. A First Class Disk belongs to itself, which is what lets a Kubernetes volume outlive the pod that mounted it and re-attach to a different node.
The resulting PersistentVolume object recorded that identity in a field called volumeHandle, and the value in that field is the disk’s UUID inside CNS. Three consequences follow, and each one costs somebody a week if it is discovered late:
- The volume handle is meaningless outside vCenter. It is not a path, not an address, not a serial number a different storage system could resolve. It is a primary key in a database that is going away.
- The
PersistentVolumeobject cannot be re-pointed. Itsspec.csiblock, driver name and handle included, is immutable. There is no supported edit that turns a vSphere CSI PV into a PV belonging to another driver. You create new ones. - The policy in the
StorageClasswas a reference, not a definition. A class naming a storage policy did not describe redundancy, striping or quality of service. It pointed at a policy object elsewhere, and that pointer resolves nowhere after the exit. Whoever writes the new classes has to know what the old policies actually required, which frequently means asking someone who has left.
Two more details matter for anyone whose estate has been running for a few years. First, the supervisor and guest cluster arrangement adds a layer: a claim in a TKG guest cluster is satisfied by a claim in the supervisor cluster through the paravirtual driver, so the estate has two levels of binding to unwind rather than one. Second, estates old enough to predate CSI may still carry volumes provisioned by the in-tree vsphere-volume plugin, migrated to CSI in place. Those volumes work, and they are annotated differently, and an inventory that only counts CSI volumes will miss them.
The four things that do not travel
Write the inventory as a table of constructs rather than a list of volumes. The volumes are the easy part.
| vSphere CSI construct | What it actually is | Does it travel? | What takes it over |
|---|---|---|---|
StorageClass naming a storage policy | A pointer to a policy object held in vCenter | No | A class on the new driver whose parameters state the requirement directly, redundancy and QoS included |
PersistentVolume with a volumeHandle | An immutable pointer to a First Class Disk UUID in CNS | No | A new PV, bound by the new provisioner, for a claim you re-create |
PersistentVolumeClaim | A namespaced request for a size and an access mode | Yes | The same claim, pointed at a different class |
VolumeSnapshot and its content object | A handle scoped to the driver that took it | No | An export to a backup target before cutover, then fresh snapshots after |
| Zone and region labels on nodes | Topology derived from vCenter object placement | Partly | Labels supplied by the new platform, with topology-aware binding declared again |
Read the third row twice, because it is the whole shape of this migration. The claim is portable. The volume is not. A PersistentVolumeClaim is a request: a name, a namespace, a size, an access mode, a class to satisfy it. Every one of those survives a platform change, which is why the manifests need so little editing. The PersistentVolume is a binding to a specific disk in a specific system, and none of it survives.
That gap is where the data lives. Re-creating the claim gives you an empty volume of the right size in the right namespace, bound by the right provisioner, and the application starts and finds nothing in it. Moving the bytes is a separate act that nothing in the Kubernetes object model does for you.
The snapshot row deserves its own warning. A VolumeSnapshotContent object carries the name of the driver that produced it, and its handle only resolves against that driver. If your retention policy currently lives in CSI snapshots, that lineage does not import into another provisioner. Decide before the cutover which of it you are legally or operationally required to keep, and export what you must to a target that is not the storage system you are leaving.
Already running Kubernetes on vSphere and mapping out what happens to the storage layer? Talk to us while the StorageClass design and the cutover order are still decisions rather than things you have already committed to. Talk to a storage architect
Choose the cutover method per volume, not per cluster
There is no single migration path for a Tanzu estate, and the plans that stall are the ones that tried to pick one. The right question is per volume: what is in it, who writes to it, and what pause can that workload tolerate.
| Volume class | Cutover method | Interruption | The part that bites |
|---|---|---|---|
| Application with native replication, such as a database or a broker | Add a member on the new class, let it sync, fail over, retire the old one | Seconds, at a failover you choose | Quorum size and version skew while both sides are live |
| ReadWriteOnce filesystem volume that can pause | Provision a fresh claim, copy at file level, swap the claim, restart | One window per claim | Permissions, extended attributes, sparse files and hard links |
| ReadWriteMany volume served by vSAN File Service | Re-provision on the new layer, and re-check whether RWX is still a real requirement | One window per workload | The file service leaves when vSAN does, and nothing inherits its export |
| Volume whose snapshot history must be retained | Export to an external target before the driver is decommissioned | None to export, a window to restore | Snapshot handles are driver-scoped and do not import |
The second row is the default for most estates, and the trap in it is not the copy. It is the assumption that a file-level copy preserves everything the application relied on. A naive copy of a volume holding a package cache or a Git mirror can lose hard links and inflate a sparse file into its full apparent size, which is how a 200 GB claim becomes an 800 GB one and the migration fails on capacity rather than on correctness.
The third row is the one most likely to be missing from an existing plan. RWX on vSphere CSI meant a file volume, and file volumes came from vSAN File Service, which is a vSAN feature. When vSAN goes, that export goes with it. Worth checking honestly at the same time is whether the workload needed shared access at all, because a good share of RWX claims in a mature estate are there because a shared volume was the easy answer years ago, not because two writers exist today.
One sequencing note that costs nothing to get right and a lot to get wrong: keep the old estate able to serve reads until the new one has been verified under real load. The temptation on a per-namespace cutover is to decommission as you go. A driver you have removed cannot give you a rollback.
What to require of the storage layer you land on
Once, this migration is a project. The point of doing it carefully is that the next platform change should not be one, and that is a property of the storage layer you choose now rather than something you can add later.
The requirement to state plainly is that the storage layer must not be a feature of the platform. If the next provisioner is again supplied by, and bound to, whatever runs your compute, you have moved the dependency rather than removed it. The test is simple: can the same driver present the same volumes to a different Kubernetes distribution, and to a hypervisor, without changing the storage system underneath? If yes, the next migration is a re-point. If no, you will do this again in full.
This is where simplyblock’s model is deliberately different. Volumes are presented over an NVMe/TCP or NVMe/RoCE fabric from a storage layer that is not part of the compute platform, so the same CSI driver and the same classes work on Red Hat® OpenShift® Virtualization, on KubeVirt, on a vanilla or vendor-supported Kubernetes distribution, and on bare-metal nodes. A migration between any of those becomes a re-attachment rather than a rebuild, and mixed estates stay workable while a long cutover runs, which matters when the Tanzu clusters and the virtual machines are not moving on the same date. Snapshots, replication and disaster recovery are properties of the volume rather than of the cluster that happens to be mounting it, so the retention policy does not need re-inventing per platform. Both deployment shapes are available: hyperconverged, with storage on the same nodes as compute, and a separated layout where storage and compute scale independently.
What it does not do is make the volume handles portable or move the bytes for you. A vSphere CSI PV still cannot be relabelled into a simplyblock PV, First Class Disk semantics still do not carry across, and the data still has to be copied by a method appropriate to the workload. Any vendor claiming a one-command path out of a platform-bound provisioner is describing the copy they are quietly doing for you, and you should ask what happens to it when a copy fails at 90 percent.
The design question worth settling first is not which tool copies the data. It is which classes exist on the far side, what each one promises, and which workload lands on which. Get that right and the copying is mechanical. Get it wrong and you will discover, months later, that everything landed on the one class somebody wrote first, and the estate has no performance tiering at all. That decision, and the Day 2 operations that follow it, is covered in more depth in the post on storage operations after the VMware exit, and the broader platform-level mapping is in the post on VMware to OpenShift migration storage decisions.
Questions and Answers
What happens to my Kubernetes persistent volumes when I leave VMware Tanzu?
The claims survive and the volumes do not. A PersistentVolumeClaim is a request for a size, an access mode and a class, and all of that carries to any conformant distribution unchanged. The PersistentVolume behind it holds an immutable volumeHandle pointing at a First Class Disk inside vCenter’s Cloud Native Storage, and that pointer cannot be re-targeted at another driver. So you re-create claims against new classes and move the data separately. For teams doing this once and not wanting to repeat it, we recommend landing on a storage layer such as simplyblock that is independent of the compute platform, so the next platform change re-points the class instead of rebuilding the storage tier.
Can I migrate a vSphere CSI PersistentVolume to another CSI driver in place?
No, and it is worth knowing why rather than looking for a flag. The spec.csi block of a PV, including the driver name and the volume handle, is immutable, and the handle is only resolvable by the driver that created it. There is no supported edit and no import path. What you do instead is provision a new claim on the new class and move the contents with a method matched to the workload: native application replication where it exists, a file-level copy for volumes that can pause, or a restore from an external backup.
Does my TKG StorageClass work on a different Kubernetes distribution?
Not as written. The class names csi.vsphere.vmware.com as its provisioner and usually references a vCenter storage policy in its parameters, and neither exists on the new platform. The class has to be rewritten for the new driver, and the useful discipline is to treat that as a chance to state the requirement explicitly, meaning redundancy, quality of service and topology as parameters rather than as a policy name resolved somewhere else.
What replaces vSAN File Service for ReadWriteMany volumes after the exit?
Whatever you choose has to be an explicit decision, because nothing inherits it. RWX on vSphere CSI meant a file volume backed by vSAN File Service, and that service is part of vSAN. Options after the exit are a file layer running on top of block storage, a purpose-built shared filesystem, or removing the requirement. Audit the claims before choosing: in a mature estate a good share of RWX volumes have a single writer and exist because shared access was the convenient answer at the time.
Is leaving Tanzu easier than migrating virtual machines off vSphere?
Easier in the parts that are visible, harder in one part that is not. There is no disk-format conversion, no guest tooling to swap, and the manifests need very little editing, so the workload side really is lighter. What is heavier is that the storage binding was invisible while it worked. A VM migration makes you confront the datastore because you can see it. A Tanzu migration lets you get all the way to a cutover before anyone asks how the bytes inside 400 claims are going to arrive on the other side.
How do I keep CSI snapshots when changing storage platforms?
You keep the data, not the snapshots. A VolumeSnapshotContent object names the driver that created it and its handle only resolves against that driver, so snapshot lineage does not import into a new provisioner. Before the old driver is decommissioned, export whatever you are required to retain to a target outside the storage system you are leaving, restore what you need on the far side, and start fresh lineage there. This is also the point at which it is worth checking whether the retention you are carrying is what the policy actually requires, since a surprising amount of snapshot history exists because nobody switched it off.
