Chris Engelbert 
There is a decision most exit plans reach about six weeks in, after the platform question has been argued to a conclusion and somebody finally opens the storage line of the asset register. The array is not old. It has support paid through a date that sits comfortably past the migration window. The obvious move is to keep it, point the new platform at it, and deal with the storage question in a later budget year.
That is often the right call, and we have written the commercial case for it in full in leaving vSphere without a storage refresh. This article is the technical question that one raises and does not answer. The array keeps presenting LUNs after the hypervisor leaves, which is the part everybody checks. What nobody checks is that three of the features the storage team is proudest of were never entirely the array’s to begin with. They were a contract between the array and VMware®, and only one side of that contract is being replaced.
Three things that were never really the array’s
Take them in the order a storage administrator would rank them.
vVols (vSphere Virtual Volumes) changed the unit of storage from the LUN to the virtual machine. Instead of a big LUN carrying a VMFS filesystem carrying forty VMs, the array exposes a storage container, and every virtual disk, config file, swap file and memory snapshot becomes its own object on the array. That is what made per-VM array snapshots and per-VM array replication possible. It is also the thing that made the array’s own data services legible to a platform team, because for the first time the object the array replicated and the object the platform cared about were the same object.
The machinery underneath it is the part that matters here. vVols requires three things: a storage container, a protocol endpoint through which I/O flows, and a VASA provider. The provider is the array vendor’s out-of-band control channel, and it is registered in vCenter. Every bind, unbind, snapshot and capability query travels that channel. There is no vVols without it.
VASA (vSphere APIs for Storage Awareness) is that channel. It is worth separating from the policy plane it feeds, because those are two different things and only one of them is in scope here. The policy side, meaning storage policies and what they map to on the destination, is covered construct by construct in replacing the VMware datastore, and that translation table is not repeated here. What is in scope is the channel itself: a vendor-supplied service, registered against vCenter specifically, that lets an array describe itself to a platform and take instructions from it out of band. That is an unusual thing for a storage array to have, and it is the single most valuable piece of integration on this list.
VAAI (vStorage APIs for Array Integration) is the oldest of the three and the least visible. It is a set of SCSI commands that the ESXi storage stack issues to a capable array so that bulk work happens inside the array rather than across the wire. Four block primitives matter: ATS for locking, XCOPY for copying, WRITE_SAME for zeroing, and UNMAP for reclaim. None of them is a feature you turn on. They are commands a specific host stack knows to send.
So the dependency is asymmetric, and that asymmetry is the whole article. The array holds the capability. The hypervisor holds the thing that knows to ask for it. When the migration removes vCenter and ESXi, the array does not lose a single feature. It loses its only caller.
The integration contract, construct by construct
Here is what actually happens to each one, and what takes over on a Kubernetes destination such as KubeVirt or Red Hat® OpenShift® Virtualization.
Table 1: What each vSphere storage integration was doing, and what owns that job afterwards.
| Integration | What it actually did | What happens at the exit | What owns the job afterwards |
|---|---|---|---|
| vVols | Made the virtual disk, not the LUN, the array’s unit of management | Stops. The provider has no vCenter to register against | The volume is already the unit. Every VM disk is its own PVC by default |
| VASA provider | Out-of-band control channel between platform and array | Stops. No equivalent protocol exists on the destination | The CSI driver, which is a narrower contract and advertises far less |
| VAAI XCOPY | Array-side block copy for clones and same-array moves | Stops being issued. No general Linux path replaces it | Copy-on-write clones in the storage layer, where no blocks move at all |
| VAAI WRITE_SAME | Pre-zeroing blocks for eager-zeroed thick disks | Stops being issued, and the reason for it goes too | Thin allocation at the pool. Nothing to pre-zero |
| VAAI ATS | On-disk metadata locking so many hosts could share one LUN | Stops being issued, and the problem it solved no longer exists | Nothing, correctly. Volumes are not shared filesystems on a shared LUN |
Two rows on that table are genuinely bad news and three are not, which is a better ratio than most migration inventories produce. The bad news is concentrated in the top two rows, and it is worth being precise about why.
vVols going away is not a capacity problem or a performance problem. It is a granularity problem, and it is temporary in the sense that the destination solves it differently rather than leaving it unsolved. On the Kubernetes side every VM disk is a PersistentVolumeClaim from the moment it lands, so the per-object granularity vVols was invented to deliver is the default rather than an integration you buy and register. What you lose is the array’s own data services operating at that granularity. If your snapshot and replication policies were expressed as array objects because vVols made that possible, those policies have to be re-expressed somewhere else.
VASA is the harder one, and the honest answer is that there is no equivalent. The CSI driver is the closest thing structurally, and the comparison is instructive precisely because of how much smaller it is. VASA let an array publish a capability catalogue that the platform reasoned about and reported compliance against. CSI lets a driver accept parameters on a StorageClass. Those are not the same contract, and a team that built its storage operating model around capability advertisement should plan for that model to change shape rather than to survive the move.
Working out what your array actually owes the new platform? If you are keeping the array through the exit and trying to decide which of its data services need replacing before cutover, that is a conversation worth having with somebody who has done the inventory before. Talk to a storage architect
The offload primitives, and which one still has a job
VAAI deserves its own section because the four primitives fail in four different ways, and only one of them leaves a real hole.
UNMAP is the exception and it is covered elsewhere. Reclaim is the one primitive whose job survives the migration intact, because deleted space still has to be handed back down the stack, and the chain that does it on the destination is longer and easier to break than the vSphere one was. That whole chain is walked link by link in space reclamation after the vSphere exit, so it is not re-argued here. Read it if you are keeping a thin-provisioned array.
XCOPY is the one people miss. It let the hypervisor say “copy these blocks, they are both yours” and the array did the work internally at array speed instead of pulling every block up through the host and pushing it back down. It is what made same-array clones and same-array moves fast, and the related migration question is handled in replacing vMotion and Storage vMotion. The uncomfortable fact is that there is no general path on a Linux host that reproduces it. Linux does not routinely ask an array to copy blocks on its behalf the way the ESXi stack did, so if your clone performance depended on array-side copy, that dependency does not transfer.
It is replaced by something better shaped rather than something equivalent. In a storage layer that implements copy-on-write, a clone is a metadata operation: the new volume references the existing blocks and diverges only where it is written. Simplyblock works this way, creating a writable volume from an existing volume or a snapshot without a copy pass, which means the comparison is not “array-side copy versus host-side copy” but “copy versus no copy at all.” A clone that moves no blocks beats an offloaded copy that moves all of them.
WRITE_SAME was block zeroing, and it existed to make eager-zeroed thick disks cheap to create. The primitive stops being issued, and so does the requirement, because the disk format that needed it is a vSphere construct that does not come with you. Storage on the destination is thin provisioned at the pool, blocks are allocated when they are written, and there is nothing to pre-zero in advance. This is a row where the correct entry in your migration inventory is “not applicable” rather than “to be replaced.”
ATS is the most interesting of the four, because the answer is that the problem is gone. Atomic Test and Set existed because VMFS was a clustered filesystem, many ESXi hosts wrote metadata to the same LUN, and the older mechanism for arbitrating that, a SCSI reservation, locked the entire LUN for the duration. ATS replaced a LUN-wide lock with a block-level compare-and-write so that one host updating metadata did not stall every other host on the datastore.
None of those conditions holds on the destination. A volume is attached to the node that needs it, there is no shared clustered filesystem carrying dozens of guests on one shared device, and there is no metadata region that many hosts contend on. Teams sometimes go looking for the ATS equivalent and conclude something is missing. Nothing is missing. An entire class of contention was designed out, and the honest entry on the inventory is that the requirement was an artefact of the datastore model rather than a property of virtualization.
Where the capabilities come back from
If the array is staying, there are two ways to arrange it, and they have very different outcomes for everything above.
The first is to present the array’s LUNs straight to the new platform and let its CSI driver, if the vendor ships one, take over. This works. It also means the array is now a block target with whatever narrow feature set its driver exposes, and the three integrations in this article are simply gone. For an estate that was not using vVols and never leaned on VAAI, that is a perfectly reasonable landing place, and it is the cheapest path through the migration.
The second is to put a storage layer between the array and the platform, and it changes the question from “what does the array still integrate with” to “what does the storage layer supply.” Simplyblock pools block devices and presents logical volumes over NVMe/TCP or NVMe/RoCE, with erasure coding, snapshots, copy-on-write clones, QoS and cross-cluster replication handled in software above whatever the capacity happens to be.
The part that matters for this particular decision is what counts as capacity. Backing devices are not restricted to local NVMe. Any whole Linux block device can be taken into the pool, which includes SAS and SATA behind an HBA, virtualized disks, cloud volumes, and LUNs an existing array presents to the storage nodes. So the array you are keeping can become the capacity underneath a modern storage layer, and the data services you lost with VASA come back from software rather than from the array’s own control plane.
Two caveats belong in the same paragraph, because this is where vendors usually stop talking. Support for non-NVMe block devices is newer than the NVMe path and local NVMe remains the production performance recommendation, so an array-backed pool is best understood as a transition and asset-sweating arrangement rather than the shape you would design from nothing. And simplyblock formats the devices it takes in. The capacity is reused; the data still has to be migrated onto it. This is not wrapping your existing LUNs and leaving the bytes where they are. Consuming the array’s capacity, yes. Re-presenting its existing LUNs untouched, no.
What that buys, set against the table above, is fairly specific. Per-volume granularity, which is what vVols was reaching for, is the default rather than a registered integration. Snapshots, clones and replication operate on volumes the platform already understands, so the object the storage layer protects and the object the platform schedules are the same object again. The clone path replaces XCOPY with something that does not copy. And the storage layer is the same product whether it runs hyperconverged on the compute nodes or separated onto its own, which matters during a multi-year exit because that choice can change once without changing vendors.
The thing to take from all of this is smaller than a recommendation. Before you decide to keep the array, write down which of its features your operating model actually depends on, and mark the ones that only worked because vCenter was there to ask. That list is usually shorter than people fear and longer than they expect, and it is much cheaper to write in a planning meeting than to discover during a cutover weekend.
Questions and Answers
Do vVols still work after we migrate off vSphere?
No. vVols is not a feature the array provides on its own. It requires a VASA provider registered in vCenter, a storage container, and a protocol endpoint, and every bind, snapshot and capability query travels the VASA channel to vCenter specifically. Remove vCenter and the provider has nothing to register against, so the per-VM object model stops. The array keeps every block it was holding and keeps serving LUNs normally. What ends is the arrangement that made each virtual disk a separately manageable array object. On a Kubernetes destination that granularity comes back a different way: every VM disk is its own PersistentVolumeClaim from the start, so per-object management is the default rather than an integration you register. What does not come back automatically is the array’s own snapshot and replication policies operating at that granularity, so if your data protection was expressed in array objects because vVols made that possible, plan to re-express it in the storage layer or the platform before cutover.
What replaces the VASA provider on Kubernetes?
Structurally the closest thing is the CSI driver, and it is worth understanding how much smaller a contract it is. VASA let an array publish a capability catalogue that vCenter reasoned about, matched against storage policies, and reported compliance on. CSI lets a driver accept parameters on a StorageClass and provision against them. There is no capability advertisement protocol and no compliance reporting in the same sense. A team whose storage operating model was built on capability advertisement should expect that model to change shape rather than survive the migration. The practical consequence is that the properties you used to discover from the array now have to be asserted by you in the StorageClass definition, and verified by you rather than reported by the platform. The policy translation question itself is covered in our post on replacing the VMware datastore.
Does losing VAAI hurt performance after the migration?
For three of the four block primitives, no, and for one of them it depends on what you replace it with. WRITE_SAME existed to pre-zero blocks for eager-zeroed thick disks, and both the primitive and the disk format it served are vSphere constructs that do not travel, so there is nothing to replace. ATS existed because many hosts shared one LUN under a clustered filesystem and needed block-level locking instead of a LUN-wide SCSI reservation; volumes on the destination are not shared filesystems on a shared device, so that entire class of contention is designed out. UNMAP has a real successor and a longer chain on the destination, which we cover separately. XCOPY is the one to think about. Array-side copy genuinely made clones and same-array moves fast, and there is no general Linux path that reproduces it. A storage layer with copy-on-write clones addresses it better than an equivalent would, because the clone becomes a metadata operation and no blocks move at all.
Can we keep our existing array and still get modern data services?
Yes, with two conditions stated plainly. Simplyblock’s backing devices are not restricted to local NVMe, and LUNs an existing array presents to the storage nodes can be taken into the pool, so the array you already own can become capacity underneath a storage layer that supplies erasure coding, snapshots, clones, QoS and cross-cluster replication in software. That is a real answer to “we are not refreshing storage this year.” The first condition is that non-NVMe block device support is newer than the NVMe path and local NVMe remains the recommendation for production performance, so treat an array-backed pool as a transition and asset-sweating option rather than a design you would choose from scratch. The second is that simplyblock formats the devices it takes in, so the capacity is reused but the data is still migrated. It is not array virtualization in the sense of wrapping existing LUNs in place.
Should we just point the new platform straight at the array instead?
You can, and for some estates it is the right answer. If you were not using vVols and never depended on VAAI offload, presenting LUNs directly to the destination and using the vendor’s CSI driver is the cheapest path through the migration and it works. Be clear about what you are choosing: the array becomes a block target with whatever feature set that driver exposes, and the three integrations in this article do not come back in any form. The case for putting a storage layer in between is not that direct attachment fails, it is that the capabilities you lose with vCenter have to come from somewhere, and software above the capacity is the only place left that can supply them uniformly across whichever platform you end up on. Decide it by listing what your operating model actually uses, not by which option sounds simpler on a slide.
