Share VMDK Disk Between Multiple VMs on VMWare

10.1K

If you want to deploy a Windows Server Failover Cluster (WSFC) on VMware ESXi virtual machines, you need to share a virtual disk (.VMDK file) between 2 (or more) virtual machines. All VMs in the WSFC should be able to read and write to this shared disk simultaneously. This guide explains how to share a VMDK disk between multiple VMware virtual machines.

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 only recommended method for shared disks in WSFC for modern vSphere environments (7.0+).
• Keep in mind that Multi-writer VMDK is a legacy compatibility mechanism and should be only used when Clustered VMDK is not available due to storage/version limitations.

Prerequisites for Clustered VMDK

• ESXi 7.0/later on all hosts
• All hosts managed by the same vCenter instance
• VMFS6 datastore
• Fibre Channel storage/NVMe TCP in vSphere 8.0+
• Eager Zeroed Thick provisioned VMDK

Enterprise tip. In addition to VMFS6 datastores, Clustered VMDK is also supported on compatible vSAN configs where documented by VMware. You should always verify support for your vSphere version, storage platform, and workload before deployment.

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 (Recommended for WSFC on vSphere 7.0+)

Configure VM Anti-Affinity Rules

You need to configure anti-affinity VM rules in vSphere to improve cluster availability (so cluster nodes do not run on the same ESXi host). This helps you to avoid simultaneous node failure if a host becomes unavailable.

Before adding the shared disk, you need to enable Clustered VMDK on the datastore. To do this go to Storage view > Configure > General > Datastore capabilities > Clustered VMDK > Enable.

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.

Below you will find the steps that describe configuring a shared disk using Clustered VMDK (native method in vSphere 7.0+).

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

1. Edit the first VM settings (Node1) in vSphere Client (ESXi host client).

   

2. Select Add Other Device > SCSI controller .
3. Set controller type to LSI Logic SAS. Be sure to create a new SCSI controller, don’t use a default SCSI 0 controller.
4. Set SCSI Bus sharing to Physical (required for clustered disk access in multi-node configurations)

   

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:
   Controller location: select the existing SCSI controller you created earlier
   Location: select a shared VMFS datastore that is available to both hosts
   Disk Provisioning: Thick provision, eagerly zeroed
   Virtual Device Node: select the SCSI controller created earlier
   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.

Then power on the VMs, log in to Windows and initialize a new disk using Computer Management Console (compmgmt.msc) > Storage > Disk Management > Rescan Disk.

Validate Windows Failover Cluster Config

Before creating the WSFC cluster, you should run cluster validation tests from Failover Cluster Manager/PowerShell:

Test-Cluster

Microsoft recommends resolving all validation errors before putting the cluster into production.

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/shared disks are typically used for:

• Microsoft WSFC (Failover Cluster)
• SQL Server Failover Cluster Instance (FCI)
• Oracle RAC
• Some legacy clustered apps

Keep in mind that many modern apps (like SQL AG, Exchange DAG, Kubernetes, etc.) do not require shared disks and instead use app-level replication.

Important. Clustered VMDK does not require Multi-writer mode or any legacy configuration. Note that this behavior applies to legacy shared disk configs only and is not applicable to Clustered VMDK.

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

WSFC Quorum Considerations

When deploying Microsoft WSFC, you should also config a proper quorum model. Here are the typical options:

• Disk Witness
• File Share Witness
• Cloud Witness

Keep in mind that incorrect quorum config may cause cluster split-brain scenarios/prevent cluster failover during node failures.

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. You should always consult the VMware compatibility documentation for your environment before deployment.

Using Multi-writer VMDK (Legacy/Not Recommended)

Keep in mind that this section is provided for legacy compatibility scenarios only. We do not recommend you this method for new WSFC deployments.

Virtual machine file locks prevent access to other virtual machines’ hard disks and avoids data corruption caused by multiple writers on the non-cluster-aware file systems.

Not supported features for VMDK disks with Multi-Writer mode

Note that multi-writer VMDK is a legacy compatibility mechanism that exists primarily for backward compatibility. We do not recommend it for modern WSFC deployments in vSphere 7.0+ environments.

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

• In legacy Multi-writer VMDK configs, support for vMotion and Storage vMotion depends on the vSphere version and deployment case. Clustered VMDK has its own set of limitations. For example, online Storage vMotion, VM snapshots, and VM cloning are not supported for Clustered VMDK deployments. You should always verify feature support for your vSphere release before deployment.
• VM suspend
• Snapshots of VM with dependent disks
• VM cloning
• Changed Block Tracking, and vSphere Flash Read Cache (vFRC)

Note. For ESXi versions prior to 6.0 Update 1, MultiWriter mode can be enabled in the VM properties: Options > General > Configuration Parameters. Add the option:

scsi1:0:sharing= "multi-writer"

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. Before deploying WSFC with shared VMDK disks, you should verify backup software compatibility with:

• Clustered VMDK
• Multi-writer VMDK
• WSFC-aware backup operations

Incorrect snapshot usage may lead to app/cluster corruption.

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.