Windows Failover Cluster

M

Malavudeen

New Member
Jul 1, 2026
4
0
1
India
Hello,

I’m trying to set up a 2-node Windows HA / Failover Cluster on Proxmox.

Has anyone here successfully achieved this setup on Proxmox? If yes, I’d appreciate any guidance or best practices.
 
Last edited:
If you configure the cluster's shared disk as an iSCSI target and connect to it using the iSCSI initiator on a cluster node, it will function exactly the same as a physical server.

We have test environments ranging from Windows Server 2012 to 2025, and they all operate without any issues.
 
bbgeek17 said:
Hi @Malavudeen , welcome to the forum.

Is there a particular challenge that you are trying to solve? We've had WSFC running on PVE, in the lab, successfully.

Cheers

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
Click to expand...
I currently have NFS shared datastore LUNs and I’m trying to build a Windows HA / Failover Cluster environment without using iSCSI, since I do not have an iSCSI infrastructure available in my environment.

My main question is: Is it possible to share the same virtual disk between multiple guest VMs when using Proxmox VE with NFS-backed storage ?

At the moment, I have a Windows cluster running on VMware vSphere, where this setup is very straightforward because VMware provides features such as:
  • Shared SCSI Bus
  • Shared VMDK
  • Multi-Writer VMDK
  • Cluster-aware virtual disks
These options make it easy to deploy a Windows failover cluster with shared storage between guest VMs.

With Linux HA clusters, I have implemented many similar clustered environments successfully on VMware.

I’m now evaluating whether there is any equivalent approach, workaround, or alternative architecture to achieve a similar shared-disk Windows clustering solution on Proxmox VE, especially when the backend storage is NFS and FC shared LUNs.
I would like to avoid:
  • iSCSI
  • LUN passthrough
  • Physical disk passthrough
I would appreciate any suggestions, best practices, or recommended architectures from anyone who has worked on a similar deployment.

Actually I have a plan to switchover from vmware or any best alternative solution similar like vmware. :)
 
> where this setup is very straightforward because VMware provides features such as:

If you want something that works just like VMware, please use VMware.
Proxmox offers the features available in Proxmox.

If you want to use a cluster, please set up iSCSI. If you can’t set up iSCSI, FC storage will work just fine.

T10 Persistent Reservation is only supported on iSCSI and FC.

How to use your current environment to replace Proxmox's features depends on the person's skills. If you can't do it, then that's just how it is.
 
Last edited:
  • Like
Reactions: Johannes S
Thank you for the clarification.

I completely understand that Proxmox VE provides its own architecture and feature set, I’m not expecting it to replicate VMware vSphere feature-for-feature.

My intention in raising this question was to better understand the architectural limitations around Windows Failover Clustering, particularly when working with existing NFS-based shared storage, since VMware handles this through shared virtual disk mechanisms such as Multi-Writer VMDK and Cluster-aware virtual disks.

I also understand the requirement around T10 Persistent Reservations, that support is generally tied to iSCSI or Fibre Channel storage protocols.

The reason I’m exploring this is because I’m currently evaluating alternatives as part of a possible migration away from VMware and one of the important workloads in my environment is Windows and linux clustering.

So my goal here is not to force VMware design principles onto Proxmox, but rather to understand whether there are alternative design patterns, workarounds, or different hypervisor platforms that can support similar clustering requirements without redesigning the entire storage architecture.

I appreciate your input and the technical explanation regarding storage protocol limitations.
 
I understand the suggestion, but architecturally it introduces a serious limitation.

If we deploy a third VM as an iSCSI target, then:
  • The storage layer becomes dependent on a single VM unless we build another HA layer on top of it
  • Performance and latency are tied directly to that VM’s workload and stability
  • It effectively introduces a new single point of failure unless it is redundantly designed
  • At that point, we are just moving the problem rather than solving it at the infrastructure layer
In a production HA design, the storage layer should not depend on another guest VM unless it is itself backed by a proper clustered storage system.
 
Malavudeen said:
I would appreciate any suggestions, best practices, or recommended architectures from anyone who has worked on a similar deployment.
Click to expand...
For lab purposes you can achieve QCOW sharing by forcing QCOW disk assignment to two VMs via "qm set". However, this would be against both standard PVE practices and certainly against the MSFT cluster qualification, and as such - not suitable for production use case.

You have previously relied on VMware ability to provide shared VMDK to the VMs. However, unless the underlying storage was shared within a VMware cluster and redundant - your VMware server was the single point of failure, similar to the limitations of a single Storage VM solution.

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
You must log in or register to reply here.
Top Bottom
Back