Shared storage that fits the hypervisor—and the workload.
Modernise VMware or Hyper-V storage without forcing a hypervisor migration. euroNAS software can provide file or block storage from a single server, a highly available pair, a scale-out Ceph platform or a validated Virtual Storage Appliance deployment.
Keep the compute platform. Improve the storage layer.
VMware and Hyper-V both use shared storage, but their preferred protocols, path management and operational expectations are not identical. The architecture must be designed for the selected hypervisor rather than copied unchanged from another environment.
VMware vSphere storage
Present shared datastores through mature SCSI protocols or the native NVMe stack. NVMe/TCP support is available in vSphere 7.0 Update 3 and later; the exact ESXi release, adapter, target and path design must still be qualified together.
- NFS datastores for file-based simplicity
- iSCSI and Fibre Channel for established VMFS designs
- NVMe/TCP or NVMe/RDMA for qualified modern fabrics
- Fused-command support for correct NVMe Compare and Write behaviour
Microsoft Hyper-V storage
Build shared-storage clusters using the protocols documented for Windows Server and validate Cluster Shared Volumes, failover and path recovery with the intended hardware.
- iSCSI and Fibre Channel block storage
- SMB 3.0 with the required availability capabilities
- NVMe-oF only through a separately qualified initiator and driver path
Independent technology guidance: euroNAS is not presented as a VMware or Microsoft partner on this page. Product and protocol suitability must be checked against the applicable compatibility programmes, operating-system release and support policy.
Shared storage is not one protocol.
Choose the data path according to compatibility, latency, operational skills, network design and recovery requirements. A supported transport still requires end-to-end qualification.
| Protocol | VMware | Hyper-V | Architecture notes |
|---|---|---|---|
| NFS | Established File-based VMware datastore | Not the standard path Not presented here for clustered Hyper-V VM storage | Simpler file-based presentation; availability depends on NAS service and network design. |
| iSCSI | Established VMFS block storage | Established Windows Server block storage and CSV | Use separate paths, target portals and the appropriate ESXi or Windows multipath policy. |
| Fibre Channel | Established VMFS through redundant fabrics | Established SAN and optional Virtual Fibre Channel use cases | Requires qualified HBAs, zoning, LUN presentation and redundant fabric design. |
| SMB 3.0 | Not a VMware datastore path | Established Including Multichannel and SMB Direct where supported | Validate the SMB 3.0 and continuous-availability behaviour required by the Hyper-V design. |
| NVMe/TCP | Supported path vSphere 7.0 Update 3 and later | Qualify separately Do not assume a native in-box production path | Uses standard IP networking and the NVMe stack; redundant controllers and network paths remain necessary. |
| NVMe/RDMA | Qualified fabrics Requires compatible ESXi, adapters and network | Qualify separately | Lower transport overhead, but the entire RDMA fabric, firmware and failure behaviour must be validated. |
Redundancy must exist from host to storage.
A dual-controller storage system cannot protect a design that still depends on one adapter, switch, VLAN or host path. Multipathing is an end-to-end architecture.
VMware or Hyper-V hosts
At least two independent host-side paths, with the appropriate HPP, NMP, MPIO or SMB Multichannel policy.
Independent fabrics or networks
Separate adapters and switches or fault domains. Avoid placing both logical paths on one physical dependency.
euroNAS storage
Premium, HA Cluster or eEKAS selected according to the required availability and scale model.
Fused Commands are a small feature with a large consequence.
VMFS uses atomic locking semantics. When an NVMe device advertises fused-operation support, ESXi can issue Compare and Write as a fused pair. The target must process the two commands together and preserve the required atomic behaviour.
Connectivity is not enough
An NVMe namespace may be discoverable and still fail datastore creation or locking operations if fused commands are not handled correctly.
euroNAS target support
euroNAS Premium, HA Cluster and eEKAS NVMe-oF target paths support fused commands and multipath-capable designs.
Validate end to end
ESXi release, native NVMe driver, adapter, transport, target version and path policy must be tested together before production use.
One software family, different availability boundaries.
The products are not interchangeable. Select the platform according to how much storage failure, controller failure and capacity growth the design must tolerate.
euroNAS Premium
A storage operating system for one physical or virtual server.
- File and block services
- Suitable for independent or externally protected workloads
- No automatic storage-controller failover
euroNAS HA Cluster
Two-node storage with two distinct protection models: synchronous mirroring for seamless failover, or asynchronous ZFS replication for scheduled storage protection.
- Synchronous mirror: confirmed writes remain aligned across both nodes for seamless failover
- Asynchronous ZFS replication: the recovery point depends on the last successfully replicated state
- Storage, address and target behaviour must be validated for the selected model
- Requires fencing and tested client recovery
eEKAS
Ceph-based storage for capacity, resilience and services that must grow beyond a two-node mirror.
- Scale-out failure domains
- Distributed data resilience
- Gateway and backend networks sized together
Physical appliance or Virtual Storage Appliance
Depending on the product and architecture, euroNAS can run directly on enterprise server hardware or as a virtual storage appliance. Virtual deployments require deliberate resource reservations, disk presentation, boot sequencing and failure-domain separation so that the storage service does not depend on the same component it is intended to protect.
Protection scope: VM Backup, Instant Backup & Recovery and integrated off-site DR are eEVOS functions. euroNAS storage systems provide storage-level protection through mechanisms such as ZFS snapshots and asynchronous ZFS replication. The recovery point is determined by the last successfully replicated state. Storage replication complements—but does not replace—workload-consistent backup.
Test failure behaviour—not only normal I/O.
A storage design is ready when the intended hypervisor, paths and recovery procedures have been exercised together.
Remove one path
Verify continued I/O, recovery time and path-state reporting when an adapter, cable or switch path fails.
Move the service
Test target relocation or gateway loss and measure the interruption observed by running virtual machines.
Restore connections
Confirm persistent discovery, access policies, multipath controllers and datastore availability after reboot.
Test ZFS replication
Validate asynchronous ZFS snapshot and replication workflows, including the destination, retention, replication interval, expected recovery point and recovery of replicated data.
Technical basis
This page uses current euroNAS product documentation together with Broadcom guidance on NVMe/TCP and fused Compare and Write behaviour, and Microsoft guidance on Hyper-V storage architectures. Version-specific compatibility must be rechecked during implementation.
Broadcom: NVMe/TCP support from vSphere 7.0 Update 3 · Broadcom: VMFS and fused Compare and Write · Microsoft: Hyper-V storage architectures
Map the hypervisor, protocol and failure domains before selecting the product.
We can review host versions, adapter and switch choices, datastore requirements, multipath policies, availability targets and recovery objectives and turn them into a practical storage architecture.
VMware and vSAN are trademarks of Broadcom Inc. Hyper-V and Windows Server are trademarks of Microsoft Corporation. References are descriptive and do not imply partnership, certification or endorsement.