What Happens to Your VMware VDI Desktops When You Leave vSphere

Every VMware® exit plan we see covers the server estate in detail. Databases, application tiers, the middleware nobody wants to touch, the licensing math. Then somebody in the third meeting asks about the desktops, and the room goes quiet.

That gap is not laziness. VDI was usually bought by a different team, on a different budget, with a different vendor conversation attached, and it often runs on its own vSphere clusters with their own sizing rules. It is also the workload in the estate with the tightest storage requirements, because a desktop that responds slowly is a help desk ticket from a named human being rather than a graph nobody is watching.

This post takes the desktop half of the estate and does the same translation the rest of this series does for server features: requirement by requirement, what vSphere plus vSAN was actually providing, what the destination platform provides instead, and which of those translations is decided by a storage choice rather than a platform choice. It is the third installment after the vMotion and Storage vMotion translation and the HA, DRS and Fault Tolerance translation.

One correction before anything else, because it changes who you call. Horizon is not a Broadcom VMware product any more. VMware’s End-User Computing division was divested by Broadcom to KKR and now operates as an independent company, Omnissa, so the product is Omnissa Horizon. Most people still type “VMware Horizon” and most internal documentation still says it, but your support contract, your roadmap conversation, and your renewal negotiation are with a different vendor than your vSphere ones. That matters for a VDI exit plan, because the desktop half of your estate may not be on the same renewal clock as the server half.

The VDI storage requirements, translated

Strip VDI down to what it asks of storage and there are five requirements. Score each on what vSphere plus vSAN provided, what the mechanism is on the other side, and whether a default StorageClass gives it to you.

Table 1: The five things a desktop pool asks of storage, and what each becomes after the vSphere exit.

Two rows are worth reading twice. The first row is the one people expect to be hard and it genuinely is. The fourth row is the one nobody expects, and it is the one that stops a migration in its tracks, because a desktop pool that cannot tolerate a node drain is a desktop pool you cannot patch.

The other useful observation is what is missing from the list. Nothing in that table is about the connection broker, the display protocol, or session management. Those are real and they are most of what your users actually experience, and they are not storage problems. The last section says exactly what you still have to choose there, because a post that quietly implies a storage layer replaces Horizon would be worthless.

The boot storm is a storage problem, not a compute one

The boot storm is the canonical reason VDI deployments bought all-flash. Several hundred desktops power on, or several thousand users log in, inside the same fifteen minutes. Each one reads its operating system, its profile, its agents, and its applications off shared storage at the same time as everyone else. The result is a dense burst of small random reads with almost no locality between desktops beyond the base image they share.

Planning rules of thumb from the vSphere era are worth keeping as a sanity check rather than a specification: a steady-state office desktop in the region of ten IOPS, and a boot or login peak several times that, often quoted at five to ten times steady state. Treat those as a first sizing pass and then measure your own pools, because the multiplier depends entirely on your image, your agent stack, your antivirus posture, and how tightly your login window is clustered. What is not in doubt is the shape: reads dominate during the storm, writes dominate the rest of the day, and the peak is what you have to survive.

vSphere answered this in two places. All-flash vSAN provided the raw device throughput, and host-side caching of the read-only base image meant that the thousandth desktop reading the same operating system block did not go to disk for it. Both answers were sized for the peak and idle for the other twenty-three hours, which is exactly why VDI storage always looked over-provisioned on a capacity report and exactly right on a latency report.

Where the same burst lands on Kubernetes

On the destination platform, the boot storm becomes a question about the pool behind the PVCs, and the honest answer depends on which storage architecture you picked.

With node-local storage, each desktop draws from the device in the node its VM happened to be scheduled onto. That produces a per-node IOPS ceiling divided by however many desktops the scheduler placed there, and it means your morning login latency is partly a function of scheduler decisions nobody reviewed. It also means the headroom you bought is stranded: a node with spare IOPS cannot lend them to a node that is saturated.

With a pooled layer addressed over the network, every desktop volume draws from the aggregate of the devices in the storage nodes, so the burst is absorbed by the pool rather than by one server. That is the property VDI actually needs, and it is the same property a shared datastore was providing, arrived at differently. With simplyblock the volumes live in a pool reached over NVMe/TCP or NVMe/RoCE rather than being mounted per host, so a desktop is not tied to the device in the machine running it, and per-volume QoS means the desktop pool and the database sitting next to it are not competing for the same unmanaged queue.

The sizing argument that follows is unusually clean, because it comes with a number. Take your measured peak IOPS per desktop, multiply by the desktops that log in inside the same window, and that is the figure the pool has to absorb without its latency curve bending. On a pooled layer you satisfy it once, for the whole estate. On node-local storage you have to satisfy it in every node, for the worst case placement, which is how you end up buying compute you do not need in order to buy IOPS you do.

Clone provisioning is where the money is, and where the trap is

The second requirement is the one that decides both your provisioning time and your capacity bill, and it is the one most likely to be translated incorrectly.

Horizon’s Instant Clone model exists to avoid storing hundreds of copies of the same Windows install. A golden image is snapshotted, a read-only replica of it is placed where the clones will run, a parent virtual machine is brought up from that replica, and each desktop is created against it with only a small differencing disk of its own. The differencing disk grows while the user is logged in and is discarded when they log off and the desktop is refreshed, which is why a non-persistent pool of a thousand desktops does not consume a thousand desktops’ worth of capacity. User state lives outside the desktop, in a profile container and an application delivery layer, precisely so the desktop itself can stay disposable. Confirm the exact internal disk set and the refresh behaviour against the documentation for your own Horizon release before you use it as a migration input, because the internals have changed across versions and the vendor has changed too.

Strip the product names off that and you have a general requirement: provision N volumes from one base image, near-instantly, and pay capacity only for what each one diverges by.

Kubernetes has exactly that primitive. You import the golden image once, into a PVC, and then create each desktop volume as a clone of it, either through a VolumeSnapshot and a dataSource reference or through a direct PVC-to-PVC clone. KubeVirt wraps the same thing in a DataVolume so a VM definition can point at a source volume or snapshot and get its disk populated on creation. The API is clean and every CSI driver that supports cloning presents the same interface.

And that identical interface is the trap. The API does not tell you whether the clone is a metadata operation or a full byte copy, and that single implementation detail is the difference between a desktop pool that provisions in seconds and one that provisions overnight.

Table 2: Two implementations of the same CSI clone call, and why the difference decides your VDI capacity plan.

Ask your storage vendor which of those two rows they implement, in writing, before you size anything. If the answer is the first row, the desktop pool refresh that used to take minutes becomes a maintenance window, and the capacity you budgeted for deltas has to cover full images instead. With simplyblock a clone is a metadata operation against a shared base, and capacity is consumed as each desktop diverges from it, which reproduces the economics the replica-plus-delta model was giving you without reproducing its per-host replica placement.

The reclaim half of the same problem is quieter and shows up a month later. Non-persistent desktops are a continuous cycle of allocate and discard: every logoff frees a session’s worth of writes, every login allocates more. If discard and UNMAP are not passed cleanly from the guest filesystem through the CSI driver to the pool, consumed capacity ratchets upward and never returns. Check this on day one with a pool refresh and a capacity reading either side of it, because it is trivially easy to verify and expensive to discover in month three.

Planning the desktop half of a VMware exit and not sure what the pool has to absorb? Talk to us while the StorageClass and clone-behaviour questions are still open, because both are much cheaper to answer before the pool is built than after. Talk to a storage architect

Desktop mobility is the requirement nobody writes down

The third translation is the one that catches teams who got the first two right, and it is the same trap the two previous posts in this series documented, arriving in a new place.

In vSphere, every host in the cluster mounted every datastore, so a desktop was never tied to the host running it. That was so ordinary that it never appeared in a requirements document. It is what let you put a host in maintenance mode in the middle of the day, and it is what let the cluster restart desktops elsewhere after a host failed.

Most default StorageClasses hand out node-local ReadWriteOnce volumes. A desktop pool built on one works perfectly in testing, because nothing in testing drains a node. The first time you patch a hypervisor node with desktops on it, you find out: the volumes are attached to the node you are trying to empty, and a dead or cordoned node’s kubelet is in no position to release them cleanly. The desktops do not move, and depending on how you got there you either wait out a detach timeout or stare at a multi-attach failure.

The fix is a single decision, made once, in the StorageClass. A volume the pool serves to any node over the fabric, with ReadWriteMany block access, means a desktop can be live-migrated off a node you want to patch and restarted on a surviving node after one fails. That is the same decision that enables live migration for server VMs, which is worth noticing: if you made it correctly for the server estate, the desktop estate inherits it at no additional cost. See accessmodes in Kubernetes storage for what each mode actually permits, and the OpenShift Virtualization storage architecture post for the RWX block mechanics in detail.

There is a licensing observation attached to this that VDI teams feel more sharply than server teams. Desktop density per host is the entire economics of VDI: the whole point is to run as many desktops per socket as the user experience tolerates. Under the Broadcom bundle, every core you added to increase that density re-priced your platform and your storage along with it, on terms you did not control, which is why VDI hosts were where the bundle hurt most. 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. Combined with thin clones, where the capacity that counts is one base image plus divergence rather than one image per desktop, the storage footprint stays small, and because data volume does not change the price it never becomes a licensing event.

What storage does not solve, and you should not let anyone tell you otherwise

This is the honest part, and skipping it would make everything above less credible.

A desktop is not just a disk. Between the user and that disk sit a connection broker deciding which desktop they get, a display protocol carrying pixels and peripherals over the network, session and entitlement management, profile and application delivery so a disposable desktop still feels like the user’s own, and client licensing terms for the guest operating system that are entirely independent of your hypervisor choice. None of that is a storage function, and simplyblock does not provide any of it.

Table 3: The VDI stack, and the one row a storage layer is responsible for.

The first question in a VDI exit plan is therefore not a storage question at all: does your broker support the hypervisor you are moving to? That is a vendor support matrix question, and you should get the answer in writing from the broker vendor before you design anything, because it determines whether you are keeping your current broker on a new hypervisor, moving to a different broker or a desktop-as-a-service offering, or running desktops as ordinary VMs on OpenShift Virtualization or KubeVirt with a lighter-weight access layer in front of them. Those three paths have very different costs and very different user-visible consequences.

What is genuinely useful is that the storage decision is the same in all three. Whichever broker you land on, the desktops need volumes provisioned fast from a golden image, capacity charged on divergence, enough pooled IOPS to swallow the login window, and mobility across hosts so you can patch. That is why it is worth settling the storage layer early even while the broker question is open: it is the part of the design that does not have to be re-done when the broker answer changes. The VMware to KubeVirt migration guide covers the mechanics of moving the VMs themselves once you have chosen.

Questions and Answers

What replaces VMware VDI storage when you leave vSphere?

A pooled block layer plus a CSI driver that does thin clones, which together provide what vSAN and the Instant Clone model were providing between them. Concretely you need three properties: enough aggregate IOPS to absorb the login window rather than a per-node ceiling, clone-from-golden-image as a metadata operation rather than a byte copy, and ReadWriteMany block volumes so a desktop is not welded to the node running it. Simplyblock provides all three from one pool reached over NVMe/TCP or NVMe/RoCE, with per-volume QoS so the desktop pool and your other workloads do not fight over the same queue. The part it does not replace is everything above the disk, which is the next answer.

Is Horizon still a VMware product?

No, and this trips up exit planning regularly. Broadcom divested VMware’s End-User Computing division to KKR, and it now operates as an independent company called Omnissa, so the product is Omnissa Horizon rather than VMware Horizon. Practically, that means your desktop estate and your server estate are on two different vendor relationships, two different roadmaps and quite possibly two different renewal dates. Verify your own contract position rather than assuming the VMware exit timeline covers the desktops, because it may give you either more room or less than you expect.

How do you size storage for a VDI boot storm?

Measure peak IOPS per desktop in your own environment, multiply by the number of desktops that log in inside the same window, and require the pool to absorb that figure without its latency curve bending. The old planning rules of thumb, roughly ten IOPS steady state and five to ten times that at peak, are a reasonable first pass and nothing more, because the real multiplier depends on your image, your agent stack and how tightly your login window is clustered. The structural point is where the headroom lives: on a pooled layer you satisfy the peak once for the whole estate, while on node-local storage you have to satisfy it in every node for the worst case scheduler placement.

Can you run VDI on KubeVirt or OpenShift Virtualization?

The desktops themselves are ordinary virtual machines, so yes, and the storage requirements translate cleanly. The open question is the layer above: whether your existing connection broker supports the destination hypervisor, which is a vendor support matrix question you should answer in writing before designing anything else. Your realistic options are keeping your current broker on a hypervisor it supports, moving to a different broker or a hosted desktop service, or running desktops as plain VMs with a lighter access layer. Settle the storage layer early regardless, because it is the same decision on all three paths.

Does a default StorageClass work for a VDI desktop pool?

Usually not, and it fails quietly, which is worse. Most defaults hand out node-local ReadWriteOnce volumes, and a desktop pool on those looks fine until the first time you drain a node with desktops on it. Then the volumes will not release from the node you are emptying, desktops do not move, and host patching stops being routine. Use a StorageClass backed by a pool that serves volumes to any node with ReadWriteMany block access. It is one decision, made before the pool exists, and it is the same one that makes live migration work for server VMs.

How does clone provisioning for virtual desktops work on Kubernetes?

You import the golden image once into a PVC and create each desktop volume from it, either through a VolumeSnapshot with a dataSource reference or a direct PVC clone, which KubeVirt wraps in a DataVolume so a VM gets its disk populated at creation. The API is identical across CSI drivers and tells you nothing about the implementation, which is the thing that matters: a metadata clone against a shared base provisions a thousand desktops effectively immediately and charges capacity only on divergence, while a full byte copy provisions at pool write throughput and charges a thousand full images. Ask which one your driver does before you size the pool, and check that discard and UNMAP reach the pool so reclaimed capacity actually comes back.