I have read that this is not a supported mix of features in a number of VMware KB’s. However I have just been through this exercise, with my secondary node as it had to be moved from an old data store. It’s quite interesting what happened.
From previous lab tests I know that when the VMs are powered up the validation check should fail, so I decided that powering off both VMs in my 2 node cluster would be a good start. I also took some comfort in the fact that I was only playing with my secondary node!
Having the VMs powered off meant that validation check succeeded. I then did the usual wizard options, selecting the RP etc. When it asked about the disk format I didn’t really know what to do or how this would act on the shared RDMs. So I chose same as source and hoped for the best.
Once the task had finished I went to power up the VMs, the primary node which I had not svMotioned started fine, however on the second node I got this fun error
” Error message from :Reason: Thin/TBZ disks cannot be opened in multiwriter mode..”
Upon looking at the properties of the VM I could see that the svMotion had converted the previous disk files to fully fledged VMDK files. My heart sank wondering what had happened to the primary nodes disks, to my relief they were fine and still showing as Raw Device Maps!
So I then removed these “new” VMDKs from the VM, also opting to delete from disk. I then powered up both nodes to do some tests. Guess what.. It all worked fine.
To move the primary node I think would be a lot more complicated. I think that you would have to power down both nodes, remove the RDM files so that they don’t get converted and then put them back, certainly not an elegant solution. But sometimes needs must and I just thought this little exercise may help someone else should they be in the same boat.