What Replaces the VMware Datastore When You Leave vSphere

The series of questions a team asks when it leaves VMware® vSphere is fairly predictable, and this site has worked through most of them: what replaces vMotion, what replaces HA and DRS, what replaces the backup estate. Each of those is a capability question, and each has a reasonably satisfying answer.

There is a question underneath all of them that gets asked less often and answered worse. Not what replaces a feature, but what replaces the thing. The datastore. The object every one of those features was operating on, the noun in every runbook, the row in every capacity spreadsheet.

The unsatisfying but accurate answer is that nothing replaces it, because its counterpart is not the same kind of object. A datastore is a place. What you get on the other side is a rule. Teams that treat that as a rename rather than a category change hit the same wall a few weeks into the migration, and it is worth understanding before you are standing at it.

A datastore is a place, its counterpart is a rule

Consider what a datastore actually is in operational terms. It has a name. It has a fixed size you provisioned. You can look at it and see how full it is. You put virtual machines into it, and where they live is a decision an administrator made, either directly or through a policy that resolved to a compatible datastore. It appears in vCenter as a browsable container with files in it, and when it reaches 80% an alarm fires.

Now consider a StorageClass, which is what most migration guides will tell you is the equivalent. It has a name, and that is roughly where the similarity ends. It has no size. It is not full or empty, because it does not contain anything. You do not put workloads into it; you reference it, and the cluster provisions a volume that satisfies it. You cannot browse it. It is a declaration of what kind of storage I want, resolved at provisioning time against whatever the driver underneath can supply.

Place versus rule. Noun versus verb. One is a container with a location and a boundary, the other is an intent with neither.

The practical consequence shows up first in capacity planning, and it is the moment most teams notice. The vSphere question is “how full is this datastore,” asked per datastore, and the answer drives a decision about that specific container. The Kubernetes question is “what is the pool doing,” asked once, and it has no per-container decomposition because there are no containers. That is genuinely better for utilization, since capacity is not fragmented into boxes each carrying its own headroom. It is also genuinely worse for the mental model your team already has, and worse for the runbook that says to check the datastore list every Monday.

The second consequence is subtler and does more damage: placement stops being something you decide and becomes something you describe. In vSphere, Storage Policy Based Management already moved teams part of the way here, letting a policy determine which datastores a VM is compatible with, and it remains the closest thing to a clean conceptual bridge in the whole translation. But even under SPBM the policy resolves to a datastore, and the datastore is still a real place you can point at. On the other side there is no place to point at. If a team’s operational instinct is “put this workload on that storage,” it needs a new instinct, not a new syntax.

The construct-by-construct translation

Here is the honest mapping. The third column is the one worth reading carefully, because a partial mapping treated as a direct one is more dangerous than no mapping at all.

Table 1: vSphere storage constructs and their Kubernetes counterparts, scored by how clean the mapping actually is.

Two rows deserve expanding, because they are the ones that surprise people.

VMFS maps onto nothing, and that is correct rather than a gap. VMFS is a clustered filesystem whose job is to let many hosts write to one shared LUN concurrently without corrupting each other, which requires on-disk locking and a lot of careful engineering. That job does not exist once volumes are attached per-workload over a fabric. A volume is presented to the node that needs it, and the arbitration problem VMFS solves never arises. Administrators go looking for the equivalent layer, do not find one, and conclude the new stack is less mature. The opposite is closer to true: the layer is absent because the problem is absent.

RDM is the one place the translation is easier. A raw device mapping existed because sometimes a workload needed the LUN, not a file on a filesystem on the LUN, and vSphere had to provide an escape hatch. In Kubernetes a raw block volume is not an escape hatch, it is a supported volume mode you request in the spec. The awkward special case became an ordinary option.

Mapping your vSphere storage constructs and finding that some of them have no counterpart? Talk to us before you rebuild the datastore model in your new platform, because the constructs that do not map are usually the ones worth not recreating. Talk to a storage architect

What you lose that nobody warns you about

The three None rows above are not equally serious, and the migration guides skip all of them.

The capacity signal is the real loss. A datastore-level fullness figure is a genuinely good operational primitive. It is scoped tightly enough to be actionable, it maps to something a human can reason about, and vCenter will shout at you before it becomes a problem. Replacing it with a single pool-level number is better in aggregate and worse in specificity. You will need alerting on pool utilization, on provisioned-versus-usable ratio if you are thin provisioning, and on per-namespace or per-tenant consumption to get back the granularity you had. None of this is hard. All of it is work that has to be someone’s job before the cutover, not after the first incident.

Storage DRS has no counterpart, and teams wait for one. In vSphere, a datastore cluster rebalances virtual machines across datastores based on space and latency, quietly, in the background. There is no equivalent process in Kubernetes moving volumes between backing stores to even out load. If the storage underneath is a single pool, the rebalancing question largely dissolves, because there is nothing to balance between. If you build multiple separate pools, you have recreated the problem and removed the thing that solved it. That is a reason to prefer one pool over several, and it is not obvious until someone asks why nothing is rebalancing.

Per-datastore operational habits need explicit replacements. Snapshot schedules attached to a datastore, backup jobs scoped to one, maintenance procedures that drain a datastore before work: each of these has a Kubernetes-side answer, and none of them carries over by itself. Write them down during planning as their own migration items. They are small individually and they are the ones that get discovered in production.

One thing worth being explicit about, because it is a fair question and the answer is no: simplyblock does not replace vCenter, and it does not give you the datastore browser back. There is no view where you open a container and see files in it. What changes is where the bytes live and how capacity is expressed. The management plane is a separate question with a separate answer, and any vendor telling you their storage layer restores the vCenter experience is selling you something else.

What the pool gives back

The trade is worth stating plainly rather than pretending it is all upside.

You give up a set of per-container capacity boxes and the tooling built around them. You get one pool, and with it the utilization that fragmentation was costing you. When capacity is not divided into datastores each sized for its own peak, the headroom you carry is the cluster’s headroom rather than the sum of everyone’s. On estates of any size that difference is usually large, and it is the single strongest financial argument for not recreating the datastore model in the new platform.

Simplyblock is built around that pool. It aggregates NVMe across nodes and serves volumes over NVMe/TCP or NVMe/RoCE, running either hyperconverged on the same nodes as your workloads or on separate storage nodes. The constructs in the table above land on it in the way the table describes: policy parameters carry through, raw block is a volume mode, thin provisioning is a pool property. Simplyblock is priced like the platform it runs on: by the CPU capacity of your worker nodes, counted the same way your OpenShift or Kubernetes subscription counts them, and data volume does not change the price.

The counter-honesty belongs here too. A single pool is a single failure domain, wider than one datastore, and that is a trade you should make deliberately rather than by default. You are adding a fabric to the data path, which wants a network designed for it. And you are asking a team to give up an operational model it knows well in exchange for one it will have to build habits around. The capacity gain is real and so is that cost.

For the rest of the storage-side detail on the Kubernetes end, persistent volume fundamentals covers the object model properly and there is no reason to restate it here. What this post is for is the translation itself, and the honest summary of that translation is: two constructs map cleanly, one maps better than it used to, and three do not map at all. Plan for the three.

Questions and Answers

What is the Kubernetes equivalent of a VMware datastore?

There is no single equivalent, and that is the useful answer rather than an evasion. The closest counterpart is a StorageClass combined with the storage pool behind it, but a datastore is a place with a fixed size that you provision virtual machines into, while a StorageClass is a rule the cluster provisions volumes from. It has no size and contains nothing. For teams making this move we recommend a single pooled block layer such as simplyblock underneath one or two classes, rather than several pools that recreate the per-datastore fragmentation you are leaving. Plan capacity at the pool, not the class.

Does VMFS have a Kubernetes counterpart?

No, and none is needed. VMFS is a clustered filesystem that lets multiple hosts write safely to the same shared LUN, which requires on-disk locking to arbitrate concurrent access. When volumes are attached per-workload over a fabric, that arbitration problem does not arise, so the layer that solved it is absent. Administrators frequently read this absence as immaturity in the new stack. It is the opposite: the layer is missing because the problem it existed to solve is missing.

How do vSphere storage policies map to Kubernetes?

This is the cleanest mapping in the whole translation. SPBM lets you express requirements as a policy and have the platform place the virtual machine on storage that satisfies it, and StorageClass parameters do materially the same job for volumes. If your team already provisions through storage policies rather than by picking datastores by hand, the conceptual move is short. The one thing that does not carry over is compliance reporting, since there is no built-in equivalent of a policy-compliance view telling you which workloads have drifted out of spec. Build that check yourself if you rely on it.

What happens to raw device mappings after a migration?

They get easier. An RDM existed as an escape hatch for workloads that needed the LUN rather than a file on a filesystem on the LUN. Kubernetes has a raw block volume mode that is an ordinary, supported option rather than a special case, so a workload that needed an RDM asks for raw block and gets it. Simplyblock serves raw block volumes over NVMe/TCP directly, which is generally closer to what those workloads wanted in the first place.

How do I monitor storage capacity without datastore alarms?

You have to build it, and it should be a planned migration item rather than something discovered after an incident. A datastore alarm is a good primitive because it is scoped narrowly enough to act on. Replacing it takes three things: alerting on overall pool utilization, alerting on the provisioned-to-usable ratio if you are thin provisioning, and per-namespace or per-tenant consumption tracking to recover the granularity the per-datastore view gave you. Simplyblock exposes pool and per-volume metrics for this, but the thresholds and the escalation path are yours to define.

Is there an equivalent of Storage DRS?

No, and if your storage is one pool the question mostly dissolves, because there is nothing to rebalance between. Storage DRS exists to move virtual machines across multiple datastores to even out space and latency, which is a problem created by dividing capacity into separate containers in the first place. A single pooled layer removes the division and therefore the need. If you build several independent pools in your new platform, you will have recreated the imbalance without the background process that used to correct it, which is a strong argument for consolidating rather than replicating the old layout.