The Other VMware Exit: Storage for Providers Who Move Customers, Not Workloads

Almost every guide to leaving VMware® is written for the same reader. An enterprise infrastructure team, its own applications, its own maintenance windows, one estate to move and one budget holder to convince. The hard parts are technical, the schedule is internal, and the finish line is a day when the old platform gets switched off.

There is a second reader, and the volume of material aimed at them is close to zero. This is the operator whose product is virtualization: the hosting provider, the managed service provider, the regional or sovereign cloud running VMware Cloud Director in front of a few hundred paying accounts. They are re-planning their platform for the same reasons everyone else is. Almost nothing else about their situation is the same.

The difference is not scale, and it is not skill. It is that they do not own the workloads. Every constraint that follows comes from that one fact, and it lands hardest on the storage layer.

What changes when the tenant is a customer

Inside an enterprise, a tenant is a namespace, a business unit, or a project. The boundary is drawn by a platform team and can be redrawn by that same team on a Tuesday afternoon. For a provider, the tenant boundary is a contract. Four things follow, and none of them are engineering problems in the usual sense.

The schedule is not yours. An enterprise picks its own maintenance windows. A provider negotiates one per customer, and some customers will not agree to any window this quarter. There is no fleet cutover. There is a sequence of individual migrations, each needing a data copy, a final sync, and an agreed minute at which something goes offline.

The old platform stays lit until the last account leaves. This is the consequence people underestimate. If a migration takes eleven months because one large customer would not move sooner, the provider runs two complete estates for eleven months, both with real capacity provisioned, both consuming power and rack space, both licensed. The finish line moves whenever a customer moves it.

Noisy neighbours are a billing event. In an enterprise a tenant hurting another tenant’s latency is an internal argument. For a provider it is an SLA with money attached, and the storage layer is where the argument usually starts, because it is the one resource where a single account’s behaviour is most visible to everyone else.

Utilization is margin, not hygiene. An enterprise with a storage pool at 45% utilization has a tidiness problem. A provider with the same number is selling less than it bought, on capital it has already spent. The ratio between capacity purchased and capacity billed is close to being the business model.

Put those together and the storage requirement stops looking like the enterprise one. The provider needs a layer that can be shared hard enough to stay profitable, partitioned hard enough to be contractual, and elastic enough to span two platforms for an unknown number of months.

The isolation trap

Faced with this, the obvious move is to give every customer their own storage. A dedicated array, a dedicated pool, or a dedicated container per tenant. It is easy to explain to a customer, it is easy to audit, and platform vendors ship tenant-aware migration tooling that maps neatly onto it. It is also the pattern that quietly caps the business.

The reason is capacity commitment. Storage assigned to a tenant has to be sized for that tenant’s peak, not its average, because the point of the dedication is that nothing else can borrow it. A customer at 30% of a dedicated 40 TB pool is stranding 28 TB that the provider has already paid for, and unlike an internal team, that customer cannot be told to hand it back. Repeat across a few hundred accounts and the provider’s utilization is not set by demand, it is set by the sum of every customer’s headroom.

That is the same stranding problem bare-metal Kubernetes produces when data gets pinned to individual nodes, except it is worse in one specific way: here the pinning is contractual. Reclaiming node-local capacity is an engineering task. Reclaiming committed customer capacity is a renegotiation.

Worse, dedicated pools make the staged migration more expensive rather than less. Every customer still on the old platform holds its full committed capacity there, while its landing zone on the new platform has to be provisioned in advance to migrate into. During the overlap, a provider running dedicated pools on both sides is paying for roughly twice the capacity it can bill for, for as long as the transition lasts.

So the real question is not whether to isolate. It is whether isolation has to be purchased with dedicated hardware, or whether it can be enforced inside a shared pool.

Planning a platform migration where the accounts move one at a time? Talk to us before you commit to a per-tenant pool layout, because that decision sets your utilization ceiling for the whole transition and is expensive to unwind once customers are on it. Talk to a storage architect

Isolation models, scored on provider economics

Three models are actually in use. They differ far less in what a customer sees than in what the provider’s balance sheet sees.

Table 1: Tenant isolation models compared on the metrics a service provider is actually judged on.

The middle column is the only one where the overlap period does not carry a straight capacity penalty, and that is the column worth designing toward. It only works, though, if the isolation guarantees are real ones. A shared pool where per-tenant limits are advisory is not multi-tenancy, it is an outage waiting for its first busy customer.

What the storage layer has to actually do

Getting the middle column requires four specific properties. They are worth stating as requirements rather than features, because a provider can check each one against whatever they are evaluating.

Enforced per-volume QoS. Not a scheduler hint. A hard IOPS and bandwidth ceiling per volume, applied at the storage layer, so one customer’s backup job cannot consume the fabric. This is what makes a shared pool contractually defensible, and it is the property most worth testing under deliberate abuse before signing anything.

Per-tenant encryption with separate keys. Isolation that survives an audit means a customer’s data is not readable using another customer’s key material, and ideally not using the provider’s either. Shared-pool architectures are frequently rejected on this point alone, usually because the question was asked after the design was fixed.

Capacity that returns to the pool. Thin provisioning is table stakes; what matters is whether space actually comes back when a volume shrinks or a customer churns, without a maintenance operation. This is the mechanism that converts pool-level utilization from a diagram into a number.

Volumes that detach and reattach across nodes. NVMe/TCP and NVMe/RoCE both give the cluster a fabric where a volume is not owned by the machine it is currently mounted on. For a provider mid-migration this is the property that makes the overlap survivable: a tenant’s data does not have to be copied to move it between hosts, capacity can be added on the side that is filling up, and the CSI layer on the destination platform can attach a volume wherever the scheduler has room. The engineering detail behind this is covered in per-tenant storage isolation on Kubernetes; the point here is commercial rather than technical.

This is where simplyblock’s licensing model stops being a pricing footnote and becomes part of the architecture. 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 difference from the Broadcom bundle is control: no capacity tiers, no bundle terms set by someone else, and one commercial envelope that both estates draw from as accounts land, so the overlap period is not charged twice at a vendor’s discretion. Simplyblock also runs the same way whether it is deployed hyperconverged on the provider’s existing nodes or as a separate storage tier, and it does not care which hypervisor or platform sits above it, which matters when some customers land on KubeVirt, some on Red Hat® OpenShift® Virtualization, and some stay on vSphere longer than anyone planned.

Three honest caveats belong here, because a provider will find them anyway. A shared pool is a shared failure domain, and the blast radius of a serious pool-level incident is every customer on it rather than one; that risk is managed with fault domains and replication, not argued away. Per-tenant QoS has to be proven under load rather than trusted from a datasheet, and the test is worth running against your noisiest real workload. And running two estates in parallel costs money before it saves any, whatever the storage design; the shared pool reduces how much, and shortens how long, but it does not make the overlap free.

Questions and Answers

What is the best storage architecture for a service provider leaving VMware Cloud Director?

A shared block pool with enforced per-tenant QoS and per-tenant encryption, rather than a dedicated pool per customer. Simplyblock is built for this shape: it pools commodity NVMe across nodes, applies hard IOPS and bandwidth limits per volume so one account cannot affect another, and returns capacity to the pool when a customer shrinks or churns. 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.

Why is a dedicated storage pool per tenant a problem for a hosting provider?

Because it caps utilization at the sum of every customer’s headroom. Capacity committed to a customer contract is sized for that customer’s peak and cannot be lent out, so a few hundred accounts each sitting at 30% of their commitment leaves the provider owning capacity it cannot sell. Reclaiming it is a renegotiation rather than an engineering task. Dedicated pools are simple to explain and easy to audit, which is why they get chosen, but they convert a utilization decision into a contractual one.

How do you migrate customers off VMware Cloud Director one at a time?

You plan for a long overlap rather than a cutover. Each account needs its own agreed window, its own data copy and final sync, and the old platform stays fully provisioned until the last one moves. The storage layer should therefore be able to span both estates and shift capacity between them as accounts land, which is what a pooled layer over NVMe/TCP or NVMe/RoCE provides and what per-tenant dedicated arrays specifically prevent.

Can a shared storage pool be isolated enough for a multi-tenant SLA?

Yes, if three properties are enforced rather than configured: hard per-volume IOPS and bandwidth ceilings applied at the storage layer, per-tenant encryption with separate key material, and measurable per-volume provisioned and used capacity for billing. Test the first of those against your noisiest real workload before committing. The genuine trade-off is failure domain: a shared pool means a pool-level incident affects every tenant on it, which is managed with fault domains and replication rather than dismissed.

Is Ceph a reasonable choice for a service provider platform?

Ceph is a good option when raw performance is not the main goal and the provider has, or wants to build, deep in-house storage operations expertise. It is genuinely capable and genuinely multi-tenant. The costs are latency under mixed tenant load and a substantial Day 2 operational burden that a provider has to staff for permanently. If the platform’s differentiator is performance per euro of capacity sold, or if the operations team is small, a purpose-built NVMe block layer is the better fit.

Does simplyblock work if some customers land on Kubernetes and others stay on a hypervisor?

Yes, and for a staged migration that is the normal case rather than the exception. Simplyblock presents block storage over NVMe/TCP or NVMe/RoCE and does not depend on the platform above it, so accounts on KubeVirt, on OpenShift Virtualization, on another hypervisor, or on bare-metal Kubernetes can all draw from the same pool. That is what allows the overlap period to be served from one capacity envelope instead of two.