Do we really need a Hyper-V cluster for 50 users?

First pin down the recovery target. If a host fails, does the business need the VMs to restart automatically, or is a planned recovery within a few hours acceptable? Those are different budgets. A cluster adds moving parts and cost, so I wouldn’t treat it as the default just because there are several servers to virtualize.

A single properly sized host plus a separate backup or recovery machine can be a reasonable design if downtime for a hardware failure is tolerable. Test restoring the VMs and make sure the backup copy is not sitting only on the primary host. If the client needs automatic failover, then price the whole cluster, storage, networking, and support together rather than comparing server prices alone.

For shared storage, a supported iSCSI array is the conventional route for a small Hyper-V failover cluster. Check the vendor’s compatibility guidance, support terms, controller redundancy, and how it connects to both hosts. Don’t assume a general-purpose NAS is equivalent just because it offers iSCSI. The storage device and its network become critical parts of the cluster, so test failure and recovery before relying on it.

Also verify the usable capacity after redundancy and leave room for growth, snapshots if applicable, and backup staging. The quoted 10 TB may be fine for the current data, but capacity planning should include Vault growth and the space needed for VM disks.

I’d be cautious about Storage Spaces Direct for a two-node setup unless the team is comfortable operating and troubleshooting it. It has specific hardware and networking requirements, and the licensing and support picture needs to be clear before buying. A lower purchase price does not help much if nobody can confidently maintain the design.

For a small environment, a supported shared-storage cluster may be easier to hand over, while one host with a separate recovery target may be simpler still. Get a partner to validate the exact configuration and workload rather than assembling components from a parts list.

Don’t size the hosts only for normal operation. If one host goes down, can the other run the Remote Desktop and Vault workloads at the same time? The two proposed systems have 128 GB each, so check measured memory use and peak CPU demand, especially for the engineering software and simultaneous remote sessions.

Plan separate, reliable backup as well. A cluster can keep services available during some host failures, but it is not a backup or disaster-recovery plan. Document restore priorities and do a recovery test before calling the project done.

There isn’t one answer in this budget range. Some teams favor a supported SAN and cluster, while others consider that too much infrastructure for four VMs and choose simpler recovery with a separate backup host. NAS-based shared storage and do-it-yourself hardware can reduce upfront cost, but support, compatibility, and failure testing matter a lot.

I’d ask vendors to quote two designs against the same recovery requirement: a supported cluster, and a non-clustered setup with a recovery system. Include licensing, backup software, networking, support, and a tested recovery plan in both totals. Then the tradeoff is visible instead of getting lost in the hardware quote.