There is a slide, and you have seen it, where a virtual machine sits inside a pod inside a Kubernetes node and everyone nods. It is a true slide. It is also the point where a storage discussion begins that the people in the room are usually not the right people to have.

I want to write down the questions I now ask in the first hour, because getting them wrong does not show up until the pilot is running and somebody says “the migration is slow and we do not know why”.

RWX is not optional, it is structural

Live migration of a VM between nodes requires the disk to be reachable from both nodes at once. In Kubernetes terms that is a ReadWriteMany volume. In vSphere terms this was simply what a datastore was, so nobody ever had to say it out loud.

So the first question is not “which storage do you have” but “does your CSI driver give you RWX block volumes, and is that mode supported for the thing you actually bought”. Plenty of drivers offer RWX over a filesystem and not over block. Plenty offer block and not RWX. The difference decides whether live migration works, which decides whether node maintenance is a routine evening or a scheduled outage.

If the answer is no, you have not lost. You have learned that your cluster does cold migration, and you can plan around it. What you cannot do is find out in month three.

Snapshots and clones are a driver feature, not a platform feature

The platform exposes VM snapshots. Whether they are any good depends entirely on whether the CSI driver implements the snapshot and clone APIs and how the array behaves underneath. A driver that technically supports snapshots but implements clone as a full copy will make VM provisioning feel like 2009.

Ask for the driver’s capability matrix. Actual matrix, from the vendor, with the version number on it. Then ask which version of the array firmware that matrix assumes, because the answer is frequently a microcode level that your array is two revisions behind.

Your existing array can often come along, on exactly one path

This is the part I find most misunderstood. Teams assume that moving from VMware to a Kubernetes-based platform means abandoning the storage investment. Often it does not: if there is a maintained CSI driver for your array, with RWX block support, the array continues to serve the VMs and the money you spent is still working.

But it is a narrow path. It depends on the specific array family, the specific driver, and a minimum firmware level. Verify all three before the design review. This one constraint has, in my experience, been the single highest-leverage fact in choosing between candidate target platforms, and it is usually discovered by accident.

Sizing is not the same shape any more

On vSphere you sized datastores. Here you size StorageClasses, and the unit that matters is the PVC. Two things change:

The overhead per VM is different. Each VM carries its disks as PVCs plus the pod overhead, and if you are used to thin provisioning at the datastore level you need to check where thin provisioning now happens: array, CSI driver, or nowhere.

Capacity accounting moves. Somebody used to look at datastore free space in a dashboard. Now free space lives in the array and in the cluster’s view of it, and those two can disagree. Decide in advance which one is authoritative and who watches it.

The organisational part

Here is the uncomfortable observation. In most companies the storage team and the Kubernetes team do not share a ticket queue, a vocabulary, or a change window. Virtualization on Kubernetes forces them to, because a StorageClass is a storage decision made in a Kubernetes object by someone who may not have array credentials.

The technical problems on this list all have answers. The organisational one is the one that actually delays projects, and no support matrix will tell you about it. If I could give one piece of advice to someone starting this journey, it would be to put the storage engineer in the room on day one and give them something to own, rather than sending them a YAML file in month two and asking why the performance is poor.

The short version

Before you agree that OpenShift Virtualization is your target platform, get four facts in writing: RWX block support in your CSI driver, snapshot and clone support, the minimum array firmware, and who owns the StorageClass. Everything else in the migration is schedulable work. These four decide whether the schedule is honest.