I had this issue when I was migrating an already existing clustered pair of Linux nodes from one datastore to a new one on a new SAN. I had created a separate folder on my old SAN/datastore where I kept the shared disks. Interestingly, when I migrated the clustered-shared datastores using the VC client, the result was each virtual machine node on the new data store had exact copies of the shared disks, but now located with the virtual machine's vmx file- same folder. So, migrating shared clustered disks creates two copies of those disks, and places each copy in the same folder as the virtual server files. The cluster was now no longer a cluster!
I deleted one set of disks, moved the other set back into a new shared folder and re-added the new copies to the clustered virtual nodes, but I got the "Reason: Thin/TBZ disks cannot be opened in multiwriter mode" error. After much searching, I found that not only did VC create multiple copies of my clustered disks, but the copies were now zeroedthick, and thus would not work as clustered disks.
My solution was this:
VMware KB: Determining if a VMDK is zeroedthick or eagerzeroedthick
By running this command in an SSH shell, on every vmdk disk in the cluster:
vmkfstools -k "My VM.vmdk"
I managed to get it working again!