VMware and Hyper-V Together: Storage for the Mixed Estate You Actually Have

Read any VMware® exit plan and you will find the same unstated assumption in the first paragraph: that the thing being exited is a vSphere cluster, and only a vSphere cluster.

That is almost never true. The data center that is leaving VMware usually has a vSphere estate at its center and three or four other things around it: a Hyper-V failover cluster that arrived with a subsidiary and never got absorbed, a set of cloud instances that began as a six-week pilot and are now in the change-management system, a rack of physical servers running the workloads that were too awkward or too licensed to virtualize, and sometimes a Nutanix cluster that came in with an acquisition. Consolidation is the actual project. vSphere is just the largest single line item in it.

This matters for storage more than for compute, because compute consolidation is the part that looks solved. One platform can run all of it. KubeVirt, Red Hat® OpenShift® Virtualization, or bare-metal Kubernetes will accept virtual machines from every one of those sources, and the migration tooling to get them there exists and is boring. What does not consolidate by itself is the storage underneath, because each of those four source estates arrives carrying its own shared-storage model, its own disk artifact, and its own idea of what a snapshot is.

The four source estates and the four storage models they bring

Take them one at a time, because the differences are structural rather than cosmetic.

The vSphere cluster. Virtual disks are VMDK files on a VMFS datastore, and the datastore sits on either vSAN or a SAN LUN. The admin reasons in datastores and thinks about capacity per datastore, snapshots as VM-level delta chains, and performance as a property of the datastore the VM happens to live on.

The Hyper-V failover cluster. This is the leg that most exit plans have no page for, and it is worth being precise about, because the mechanism is genuinely different rather than a Microsoft-branded copy of the VMware one. A Cluster Shared Volume gives every node in a Windows Server failover cluster simultaneous read-write access to the same LUN, formatted NTFS or ReFS, and surfaced as a clustered file system called CSVFS under a consistent path on every node. Clustered VMs keep their VHDX virtual disk files on it. One node at a time is the coordinator that owns the underlying physical disk resource, filesystem metadata updates are synchronized across nodes over SMB 3.0, and when a node loses its direct path to the storage its I/O is redirected across the cluster network to the coordinator instead of failing. Underneath the volume there is either a SAN LUN, an SMB3 file share from a scale-out file server, or Storage Spaces Direct pooling the internal drives of between two and sixteen servers. In the Storage Spaces Direct case the resilience is mirroring or erasure coding across servers, the volumes are ReFS presented as Cluster Shared Volumes, and quality of service is expressed as minimum and maximum IOPS per virtual machine. If the cluster has been modernized, that same stack is what sits under Azure Local, Microsoft’s current name for its on-premises Azure-connected infrastructure product, which is licensed per physical core and supports only the hyperconverged deployment shape.

The cloud instances. Each virtual machine has its own managed disk, or several. There is no shared storage layer at all in the on-premises sense, no datastore, no cluster volume, and no pool. Capacity is per instance, performance is a per-disk tier you selected in a dropdown, and the snapshot is a per-disk cloud API object. Everything about this leg is priced and reasoned about per unit, which is exactly why the bill grew, and why the workloads are coming back. The data-gravity side of that return trip is its own planning exercise.

The physical servers. Local disks, no shared storage, no live migration, and usually no snapshot beyond whatever the application or the backup agent provides. This is also the leg that frees the most rack space, power and support contract when it finally moves, which is why it keeps appearing on consolidation business cases and then falling off the technical plan.

Four estates, four shared-storage models, four disk artifacts, four snapshot semantics, four performance models. The compute side of the consolidation collapses that to one. The storage side does not collapse on its own.

What consolidating compute does not consolidate

Here is the failure mode, stated plainly. You land all four estates on one Kubernetes platform, point every workload at whatever the default StorageClass happens to be, and declare the consolidation done. What you actually have is one control plane sitting on top of four capacity pools, four failure domains, four snapshot formats and four performance tiers. That is the same fragmentation the consolidation was supposed to remove, now with a Kubernetes API in front of it, and it is harder to see because everything answers kubectl.

The table is the useful form of this, because it separates what genuinely changes from what merely gets a new name.

Table 1: What each leg of a mixed estate arrives with, and what changes when all four land on one storage layer instead of four.

The last column is not a claim that a storage layer solves consolidation. It is a claim about which specific problems move from “four instances of this problem” to “one instance of this problem”: capacity planning, snapshot policy, quality of service, and the failure domain. Those four are the ones worth consolidating deliberately, and they are the four that a default StorageClass quietly leaves fragmented.

Consolidating more than one hypervisor into a single platform? Talk to us when the source estate includes a Hyper-V cluster, returning cloud instances or never-virtualized physical servers, and you need one storage design that covers all of them rather than one per source. Talk to a storage architect

The compute-to-capacity ratio is the part nobody sizes for

There is a sizing problem hiding inside the mixed estate that does not exist when the source is a single cluster, and it is the strongest argument for separating the storage decision from the compute decision.

The four estates arrive with wildly different ratios of compute to capacity. The never-virtualized physical database server is the extreme case at one end: eight cores, thirty terabytes, and an I/O profile that has been tuned against local NVMe for years. The Hyper-V cluster is often the opposite, because it was sized for VM density and its capacity per node is modest. Returning cloud instances are usually compute-heavy and capacity-light, because that is the shape that cloud pricing selected for. The vSphere estate sits somewhere in the middle by definition, since it is the largest and most averaged part of the estate.

Now size a hyperconverged design for all four at once. Storage and compute scale together on the same nodes, so the node count and node specification have to satisfy whichever dimension is worst. Add the capacity-heavy database server and you buy cores you will not use. Add the compute-heavy returning cloud workloads and you buy drive bays you will not fill. The mixed estate makes this worse than a homogeneous one, because the averaging that made hyperconvergence work on a uniform vSphere estate is exactly what stops working when the inputs diverge.

Simplyblock is built for both shapes, and the choice is a real one rather than a marketing position. Run it hyperconverged, with storage and compute co-located on the same nodes, when the estate is uniform enough for one node specification to fit everything. Separate the storage tier from the compute tier over an NVMe/TCP or NVMe/RoCE fabric when it is not, which for a genuinely mixed estate is the common case. The comparison of converged, hyperconverged and disaggregated models covers that trade-off in general terms; what the mixed estate adds is that the divergence between the legs is itself the deciding input.

Two structural properties follow from landing all four legs on the same pool, and both are worth naming because they are the ones that survive contact with a real migration:

• Capacity pools instead of capacity silos. Thin provisioning across one pool means the capacity-heavy leg and the compute-heavy leg draw from the same place. Four separate silos strand free space in whichever silo does not need it, and the mixed estate guarantees the imbalance rather than merely risking it.
• **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. That matters specifically here because a consolidation project collapses four storage estates into one budget line, and that line should have no capacity tiers to outgrow and no bundle terms of its own.

Every leg also ends up with the same snapshot primitive, taken at the volume rather than by a host API, which is the property that makes the backup estate translation a single exercise rather than four. Whether the destination is KubeVirt, OpenShift Virtualization or bare-metal Kubernetes, the CSI driver presents the same volume type and the same snapshot object.

What a storage layer does not fix

Being honest about the boundary is more useful to this audience than being expansive, because the people running a mixed estate have already been sold the expansive version.

Windows guest licensing does not get cheaper because the volume moved. Active Directory integration, Group Policy, and the operational habits built around System Center Virtual Machine Manager or Windows Admin Center are management-surface concerns, and a storage layer has nothing to say about them. If the Hyper-V cluster is where your Windows administrators live, they will need a destination story for the management plane that is separate from the storage story, and it will be the slower of the two conversations.

The disk-format conversion is also real work. VMDK, VHDX and cloud disk images all have to become something the destination platform can attach, and the physical servers have to be converted at all before they have a virtual disk to convert. Tooling exists, the process is well documented, and the migration guide for moving VMware VMs to KubeVirt walks the vSphere side of it. What a consolidated pool changes is not whether you do the conversion but how many distinct destinations you convert toward: one volume type and one snapshot model rather than a per-source decision each time. The zero-copy migration architecture piece expands the any-hypervisor claim that this post has been unpacking, and the current field of VMware alternatives is worth reading with the mixed-estate assumption in mind rather than the pure-vSphere one, because most of that field is written for the pure case.

Pass-through disks deserve a specific mention, because they are the mixed estate’s version of raw device mapping. A physical disk attached directly to a Hyper-V virtual machine cannot live on a Cluster Shared Volume, which is why it exists as an exception in the first place. On a fabric-attached block layer the exception disappears: a raw block volume handed to the guest is the normal case, not the workaround. That is one of the few places where the translation is genuinely simpler on the destination side than it was on the source side, and it is worth checking your estate for, because those disks are usually attached to the workloads with the strictest performance expectations.

Questions and Answers

Can one storage layer serve both a VMware and a Hyper-V source estate?

Yes, and that is the point of choosing the storage layer independently of the hypervisor. Simplyblock presents block volumes over an NVMe/TCP or NVMe/RoCE fabric through a CSI driver, so once workloads from either source are running on KubeVirt, OpenShift Virtualization or bare-metal Kubernetes, they consume the same volume type, the same snapshot primitive and the same QoS model. What the storage layer does not do is run the source platforms side by side indefinitely; it removes the need for a separate storage design per source once they land on the destination.

What replaces a Cluster Shared Volume after a Hyper-V migration?

Structurally, nothing does, and that is a simplification rather than a loss. A Cluster Shared Volume exists so that multiple failover cluster nodes can share one LUN with a coordinator node arbitrating metadata and absorbing redirected I/O when a node loses its storage path. On a fabric-attached block layer each volume is attached to the node that needs it, with no coordinator role and no redirection path to plan around. The parts you do have to re-express explicitly are the per-virtual-machine IOPS floors and ceilings you had configured, which become per-volume QoS policy, and the resilience level, which becomes a property of the storage pool rather than of the volume.

Does moving off Storage Spaces Direct mean giving up hyperconverged storage?

No. Simplyblock runs hyperconverged, with storage and compute on the same nodes, and it also runs as a separate storage tier over a fabric. The reason mixed estates often choose the separated shape is not ideology, it is the compute-to-capacity ratio: when a capacity-heavy physical database server and a compute-heavy set of returning cloud instances have to fit the same node specification, a design that scales the two dimensions together forces you to over-buy one of them. If your estate is uniform enough that one node specification fits, the hyperconverged shape is the simpler operational choice.

How should the never-virtualized physical servers be sequenced?

Sequence them after at least one virtualized leg has completed, but do not defer them indefinitely, because they are usually where the rack space, power and support-contract savings actually are. The storage prerequisite is the one that gets missed: a physical server has no shared storage and no virtual disk, so the volume it will run on has to exist and be sized before the conversion, and its I/O profile has been tuned against local drives for years. Measure that profile first, then size the pool and the QoS policy against the measurement rather than against the nominal drive specification.

Is Azure Local a destination or another source estate in a consolidation?

Treat it as a source in this context. Azure Local is Microsoft’s current on-premises Azure-connected infrastructure product, it uses Storage Spaces Direct underneath, it supports only the hyperconverged deployment shape, and it is licensed per physical core. If the consolidation goal is one platform with platform-aligned storage licensing and free choice of hypervisor, a per-core on-premises product with a fixed deployment shape is another estate to absorb rather than the place to absorb the others into.

Does simplyblock license per core, and what does that mean for a consolidation project?

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. In a consolidation the practical consequence is one storage budget line that follows the platform you consolidate onto, with no capacity tiers to renegotiate as the four estates land on it.