How to Configure Shared VMDK for Windows Server Failover Clustering (WSFC) on VMware

10.3K

If you want to deploy a Windows Server Failover Cluster (WSFC) on VMware ESXi VMs, you may need to config a shared virtual disk (.VMDK) that is accessible to multiple cluster nodes. In a typical WSFC clustered-disk config, SCSI-3 Persistent Reservations (SCSI-3 PR) help coordinate access to the shared storage, while WSFC manages disk ownership and controls which node can bring the clustered disk resource online. Our guide explains how to config a shared VMDK for supported WSFC deployments on VMware vSphere.

Compatibility note. Our guide covers supported WSFC deployments on VMware vSphere. You need to verify compatibility for your specific vSphere release, Windows Server version, and storage config before deployment. Run the full cluster validation tests before putting the cluster into production.

Shared Disk Technologies in VMware

In older WSFC deployments, the Raw Device Mapping (RDM) disks for shared storage clustering often used. However, in modern VMware environments we generally recommend using Clustered VMDK instead of RDM because it provides simpler management and better vSphere integration.

VMware Options for Shared Disk in Clustering

Note that clustered VMDK is the primary method covered in our guide. Multi-writer VMDK is discussed separately for supported legacy workloads.

Prerequisites for Clustered VMDK

• You should use a currently supported VMware vSphere release (preferably vSphere 9.x where the required WSFC, guest OS, and storage configuration is supported). vSphere 8.0 Update 3 is an alternative when required by compatibility/licensing constraints. You should not use vSphere 7.x as the baseline for new deployments because General Support ended on October 2, 2025.
• All hosts managed by the same vCenter instance
• VMFS6 datastore
• Supported storage protocols and array configs depend on the vSphere release. For Clustered VMDK on VMFS, you need to check support for the required protocol and SCSI-3 Persistent Reservations (SCSI-3 PR) on the selected storage array.
• Eager Zeroed Thick provisioned VMDK
• Windows Server 2022 and 2025 require a supported combination of vSphere release, virtual hardware, SCSI controller, and storage config.

Enterprise tip. In addition to VMFS6 datastores, Clustered VMDK is also supported on compatible vSAN configs where documented by VMware.

How to Share a VMDK Disk Between VMs on VMware ESXi

The config process depends on the method you choose:

• Clustered VMDK: you should use native vSphere shared disk support
• Multi-writer VMDK: legacy shared disk config

Follow the steps in the appropriate section below.

Primary Method: Clustered VMDK for Supported WSFC Deployments on vSphere 8.x and 9.x

In the vSphere Client, navigate to Storage view > select the VMFS datastore > Configure > General > Datastore Capabilities > Clustered VMDK > Enable. The exact UI labels may vary by vSphere version. You should verify the datastore config before proceeding to create the shared VMDK.

Keep in mind that this operation must be performed in the vSphere Client connected to vCenter Server. The standalone ESXi Host Client does not provide the datastore-level Clustered VMDK config workflow.

Configure VM Anti-Affinity Rules

Configure VM anti-affinity to prevent cluster nodes from running on the same ESXi host. Follow the steps below:

1. In the vSphere Client, open the cluster containing the ESXi hosts that run your WSFC VMs.
2. Here you need to check if vSphere DRS is enabled for the vSphere cluster managed by vCenter Server. VM-VM anti-affinity rules require DRS; without DRS, you cannot rely on these rules to enforce the placement of WSFC nodes across ESXi hosts.
3. Open Configure > VM/Host Rules and create a VM-VM anti-affinity rule for the WSFC VMs.
4. Select the Separate Virtual Machines rule type.
5. Apply the rule strength required by Broadcom’s supported WSFC config. You should use a mandatory Must rule when required by that config.
6. Check if the nodes run on different physical ESXi hosts and that the cluster has sufficient host capacity to tolerate an ESXi host failure.

Add a new SCSI controller in vSphere client

Suppose you have two ESXi hosts with a shared VMFS backend datastore. These hosts are running two VMs (node1 and node2) that you want to add a shared virtual disk to.

The following steps describe how to config a shared disk using Clustered VMDK for supported Windows Server Failover Cluster (WSFC) deployments on VMware vSphere 8.x and 9.x.

Start by adding a new SCSI controller to both virtual machines.

1. Connect to vCenter Server and edit the settings of the first VM (Node1).

   

2. Select Add Other Device > SCSI controller .
3. Set the controller type to VMware Paravirtual (PVSCSI). You should use a dedicated SCSI controller for the shared cluster disk, separate from the controller used by the OS disk.
4. Set SCSI Bus sharing to Physical (required for clustered disk access in multi-node configurations)

   

   Important. You need to use the same supported virtual SCSI controller type and matching SCSI device address for the shared disk on every cluster node. Keep the OS disk and other non-shared disks on a separate controller with Bus Sharing set to None.
5. On the second VM (Node2), add a new SCSI controller with the same settings.
6. Then add a new virtual disk to the first VM (Edit Settings > Add Hard Disk > New standard hard disk). Configure the following disk settings:
   Location: select a shared VMFS datastore that is available to both hosts
   Disk Provisioning: Thick provision, eagerly zeroed
   Virtual Device Node: select the dedicated SCSI controller and assign an appropriate SCSI device address, such as SCSI (1:0)
   Disk Mode: Dependent
   Sharing: No sharing
   If your environment uses Storage Policy Based Management (SPBM), you should assign a storage policy that supports the shared-disk requirements of your workload and is compatible with Clustered VMDK.
   

   

7. Next, add the existing virtual disk on the second VM (Node 2).
   1) Click Add hard disk > Existing hard disk
   2) Select the VMFS with shared disk created earlier
   

   

   3) Select the first VM directory
   4) Click on the shared VMDK file.
   

   

   5) Attach the same shared VMDK disk to the second VM using the same SCSI controller.
   6) Set the same SCSI device address for a shared vmdk disk on both virtual machines. For example, SCSI(1:0). You need to ensure that all cluster nodes use the same SCSI controller type and SCSI bus/device mapping for the shared disk. Note that inconsistent controller mappings may prevent the clustered disk from being detected correctly inside the guest OS.

Power on both VMs and check if Windows detects the shared disk on both cluster nodes. Rescan disks if necessary.

On Node1 only, initialize the new disk, create the required partition, and format it with the file system supported by your intended clustered workload. Do not initialize, partition, or format the same shared disk independently on Node2.

On Node2, you need to check if the shared disk is detected, but do not perform separate disk initialization/formatting. Follow the supported WSFC storage-config procedure to add the disk to the cluster. Once the disk is managed by WSFC, you should allow the cluster to control its ownership and online/offline state.

Validate and Create the Windows Failover Cluster

Before creating the Windows Server Failover Cluster (WSFC), you need to install the Failover Clustering feature on every node and validate the config. Run the following commands in an elevated PowerShell session.

1. Install Failover Clustering. Run on each cluster node:

   Install-WindowsFeature Failover-Clustering -IncludeManagementTools

2. Validate the cluster config. Run from a node with the required admin permissions:

   Before running Test-Cluster, confirm that the shared disk is visible to all nodes and that the SCSI configuration matches across them. You need to review the complete validation report and resolve relevant failures before creating the production cluster.
   

   $nodes = 'WSFC-NODE1', 'WSFC-NODE2'
   Test-Cluster -Node $nodes -ReportName 'C:\ClusterValidation'

   Replace the example names with your actual Windows Server hostnames. Review the validation report and resolve all relevant errors before deploying the cluster in production.

3. Create the cluster. After validation, use the command:

   New-Cluster -Name WSFC-PROD `
     -Node WSFC-NODE1, WSFC-NODE2 `
     -StaticAddress 192.168.10.50 `
     -NoStorage

   Replace the cluster name, node names, and IP address with values appropriate for your network. The static IP must be available and valid for the cluster network. You should use -NoStorage when you want to config shared storage separately after cluster creation.

4. Add the shared disk to the cluster. After creating the cluster, you need to confirm that the intended shared disk is available to WSFC. Use Failover Cluster Manager or PowerShell to identify and add the disk.

   First, list the disks available for clustering:

   $availableDisks = Get-ClusterAvailableDisk
   
   $availableDisks |
   Format-Table Number, Name, ScsiAddress, Size -AutoSize

   Identify the intended shared VMDK by verifying its disk number, size, and SCSI address against your vSphere config. Then select the verified disk:

   $targetDiskNumber = 3 # Replace with the verified disk number
   
   $disk = @(
   $availableDisks |
   Where-Object { $_.Number -eq $targetDiskNumber }
   )
   
   if ($disk.Count -ne 1) {
   throw "Expected exactly one matching disk; found $($disk.Count)."
   }
   
   $disk | Add-ClusterDisk

   Don’t forget to replace the example disk number with the actual value returned by Get-ClusterAvailableDisk. Do not rely on the disk name alone. You should check if the selected disk is the intended shared VMDK before adding it to WSFC.

   Finally, check the cluster disk resources:

   Get-ClusterResource |
   Where-Object ResourceType -eq 'Physical Disk'

   Confirm that WSFC manages the intended shared disk and controls its ownership and online/offline state. Do not independently bring the shared disk online on both nodes.

Configuring WSFC Cluster Parameters for VMware

For supported WSFC deployments with shared disks on VMware vSphere, Broadcom documents specific cluster parameter values. Some of these values may already match the Windows defaults, depending on the Windows Server version. You need to verify the recommended values for your exact vSphere and Windows Server config before applying changes.

Run the following commands in an elevated PowerShell session on a cluster node:

$cluster = Get-Cluster -Name 'WSFC-PROD'

$cluster.QuorumArbitrationTimeMax = 60
$cluster.SameSubnetThreshold = 10
$cluster.CrossSubnetThreshold = 20
$cluster.RouteHistoryLength = 40

You need to replace WSFC-PROD with your actual cluster name. These values must be checked against the Broadcom support guidance for your specific vSphere release and WSFC config.

Verify the configured values using the following:

$cluster = Get-Cluster -Name 'WSFC-PROD'

$cluster |
Select-Object Name,
QuorumArbitrationTimeMax,
SameSubnetThreshold,
CrossSubnetThreshold,
RouteHistoryLength

Do not change these settings independently of the supported config guidance. You should validate cluster health and failover behavior after applying the changes.

Now you can proceed to config WSFC/other supported clustered apps. Note that Oracle RAC deployments on VMware should follow Oracle and VMware official support/certification guidance.

Supported Workloads and Cluster Types

Clustered VMDK is intended for supported Windows Server Failover Clustering (WSFC) configurations on VMware vSphere. Typical use cases include:

• Microsoft Windows Server Failover Clustering (WSFC)
• SQL Server Failover Cluster Instance (FCI), when the complete configuration is supported by Microsoft and Broadcom

Note that Oracle RAC uses a different shared-disk config from WSFC. Multi-writer VMDK remains a supported option for compatible Oracle RAC deployments on VMFS and vSAN, subject to the requirements of the specific vSphere/VCF release and Oracle certification matrix. Do not assume that support for Clustered VMDK in WSFC automatically applies to Oracle RAC.

Many modern apps, including SQL Server Availability Groups (AG), Exchange Database Availability Groups (DAG), and Kubernetes workloads, use app-level replication or other storage architectures and do not necessarily require shared VMDKs.

Important. Do not enable Multi-writer mode for a Clustered VMDK disk.

Note. The maximum number of WSFC nodes with Shared Clustered VMDK is 5.

Configure the Quorum Witness

A quorum witness helps the Windows Server Failover Cluster maintain quorum when a node becomes unavailable. For a two-node cluster, you need to config a witness in order to reduce the risk of losing quorum during a single-node failure.

Choose the witness type based on your infrastructure:

• Cloud Witness — recommended when the cluster can reach Azure and your organization permits using an Azure Storage account. It avoids maintaining a separate file server or shared witness disk.
• File Share Witness — suitable when a reliable, independent file server is available. Place the share on infrastructure that does not depend on the cluster nodes/same failure domain.
• Disk Witness — use a supported shared disk when the storage design and cluster config call for it. Do not use the disk hosting the clustered app/data as the witness.

Option 1: Configure Cloud Witness

Cloud Witness requires an Azure Storage account and outbound HTTPS connectivity from the cluster nodes to the Azure Storage service over TCP port 443. You need to check if your firewall and proxy policies allow the required Azure Storage endpoints before configuring the witness.

Run the following commands in an elevated PowerShell session on a cluster node (don’t forget to replace the placeholder with your Azure Storage account name):

$accountName = 'AzureStorageAccountName'
$accessKey = Read-Host 'Enter the Azure Storage account access key'

Set-ClusterQuorum `
-CloudWitness `
-AccountName $accountName `
-AccessKey $accessKey

You should treat the storage account access key as a secret. Do not hardcode it in scripts, commit it to source control, or expose it in logs. For production environments, you should prefer your organization’s approved secret-management solution and restrict access to the storage account key.

Verify the quorum config after applying the change:

Get-ClusterQuorum

Option 2: Configure File Share Witness

Create and secure a dedicated SMB share on an independent file server first. Then run the command below:

Set-ClusterQuorum -FileShareWitness '\\FSW01\WSFC-PROD-Witness'

You need to replace the example UNC path with your actual witness share. Check if the cluster nodes have the required share and NTFS permissions.

Option 3: Configure Disk Witness

In case a supported disk is available and intended for use as the witness, you should identify its cluster disk resource and config it as the quorum disk:

Get-ClusterAvailableDisk
Get-ClusterResource

After the disk has been added to WSFC, you need to use its exact resource name:

Set-ClusterQuorum -DiskWitness '<ExactClusterDiskResourceName>'

Do not guess the resource name or select a disk until you have verified its identity and purpose.

Verify the quorum configuration

After configuring the witness, you need to verify the cluster’s quorum settings. Use the following command:

Get-ClusterQuorum

Confirm that the reported witness type and resource match the intended design. Follow your organization’s security and availability requirements when selecting and configuring the witness.

Clustered VMDK Limitations

Although Clustered VMDK is the recommended shared-disk technology for modern WSFC deployments, note that some vSphere features remain unsupported. Depending on the vSphere version, these include VM snapshots, online Storage vMotion, VM cloning, and certain hot hardware changes.

Using Multi-writer VMDK for Supported Clustered Applications

Multi-writer VMDK is a supported shared-disk mechanism for specific clustered apps, including Oracle RAC, when the complete config is supported by Broadcom and the application vendor. It allows multiple VMs to access the same virtual disk concurrently, relying on the guest OS and app clustering software to coordinate writes.

For Windows Server Failover Clustering (WSFC), you need to use the supported Clustered VMDK config described in the previous section instead. Do not enable the Multi-writer flag on a Clustered VMDK disk.

See the Broadcom documentation for Multi-writer VMDK and the Broadcom guidance for Oracle RAC on vSAN. You need to check the requirements for your specific vSphere/VCF release and datastore type.

Multi-writer VMDK allows multiple VMs to open the same virtual disk concurrently in supported configs. It does not provide file-system-level or app-level coordination by itself. The guest OS and app must use a supported clustering/concurrency-control mechanism in order to prevent conflicting writes and data corruption.

Not supported features for VMDK disks with Multi-Writer mode

Limitations listed below apply to Multi-writer VMDK configs.

The following vSphere features are not supported for VMDK disks with Multi-Writer mode enabled:

• VM suspend
• Snapshots of VM with dependent disks
• VM cloning
• Changed Block Tracking, and vSphere Flash Read Cache (vFRC)

Note that Clustered VMDK does not require Multi-writer mode/Independent disk mode. These settings belong exclusively to legacy shared disk configs.

Backup and Snapshot Notes

Don’t forget that application-consistent snapshots and backup operations may be limited for shared-disk cluster configs. You need to check if your backup product supports the selected shared-disk config and WSFC-aware backup and restore. Unsupported snapshot/recovery operations can compromise cluster and app consistency.

Monitor Cluster Storage Performance

After deploying a WSFC with shared VMDK disks, you should regularly monitor storage latency and datastore performance. High disk latency, storage congestion, or path failures may affect cluster stability and app performance. You need to use vCenter performance charts and your storage vendor’s monitoring tools to detect issues before they impact production workloads.