This is probably one of the most common clustered deployments, but always follows the official documentation from VMware or your application vendor for specific configurations. In this example, I assume that a VM is already configured and the operating system is installed. An initial VM has a single virtual disk on the VMFS datastore connected to SCSI controller 0:

1. Power off the VM and edit the settings of the virtual hardware.
2. Assign a new SCSI controller 1:
   1. Type: VMware Paravirtual
   2. SCSI Bus Sharing: None
3. Create a new RDM disk and attach it to SCSI controller 1:
   • Compatibility Mode: Physical
   • Sharing: Multi-writer:

4. Start the first VM.
5. From the guest OS (assuming it is Windows Server), rescan the storage devices.
6. Bring the disk online and create a new simple volume.
7. Power off the second VM that should be part of the cluster.
8. Assign a new SCSI controller 1:
   • Type: VMware Paravirtual
   • SCSI Sharing: None
9. Assign the disk created in step number 3 using Add existing disk.
10. Set the sharing policy to Multi-writer.
11. Start the second VM.
12. Rescan the storage devices, and you should see the shared disk.
13. Proceed with Oracle RAC/Microsoft Cluster Services deployment.

If you forget to enable the multi-writer flag, the following error will be displayed:

Before the Oracle or Microsoft cluster is configured, do not copy anything to the new disk from within the guest operating system.

You should also configure DRS anti-affinity VM rules to keep the VMs on the different ESXi hypervisor.

Working with clusters is not an easy task, and as already stated, any minor misconfiguration can lead to severe problems. From my perspective, I would recommend switching to scaled-out solutions instead of clustered ones because such deployments provide the same availability as clusters, but they do not involve any advanced configuration on the vSphere level. In-guest bunching arrangements that don't utilize a common plate design, for example, SQL Mirroring, SQL Server AlwaysOn Availability Group, and Exchange Database Availability Group, don't require unequivocal help explanations from VMware. These setups don't require extra VMware consideration with respect to a particular stockpiling convention or various hubs and can be conveyed on VMs in much the same way as on physical devices.