Storage vMotion Disks in a Clustered Virtual Environment

I want to go over the gotchas in moving storage around in a MSCS environment in VMware. I came across this one today where I was unable to power on a machine after I storage vMotion over to a new datastore. Now I already knew there was probably going to be an issue because lets just face it, it is a Microsoft cluster. I have never seen the great benefit of having a cluster under a HA and DRS environment in VMware. However, I realize there are some special cases when there has to be an added layer of protection.

Once the VM disks are built and set as RDM’s,  and the passive node has it’s RDM’s set as stub files in the datastore of the active node; what happens to the disk when you vMotion it?… Well, for whatever reason everything will verify successfully if you have the server shut down to do a cold migration.    However, you will get errors if the VM’s are powered on. In my case I decided to move the active node to another datastore option when it was shut down.  This will let you continue with no problems at all.     But in doing so will take every stub file and create them as VMDK’s. This in turn will totally break the cluster.   From there you will not be able to power back on your cluster note.   Instead you will be greeted but this nasty error: Thin/TBZ disks cannot be opened in multiwriter mode.

Ok, the server is busted.   Panic, delete and start over…No!  It’s is a VM on VMware so you must have done something right.   As long as you haven’t manually deleted the RDM storage yet, this will be a very easily recoverable fix.

Edit the migrated node and *delete* the once stub files that are now VMDK’s

Once they have been deleted, you should just easily re-attach them as RDM’s

Browse back to the original datastore where you stored your local drive of the VM.   Then look for your RDM you should have stored with your virtual machine.  Point the stub file back to the RDM like you created in the beginning.   This should get you back to looking like  it was before the vMotion.

From here you will be able to power on the VM with no problems.   There will be no reason windows will need to re-signature the disk, because it was never powered on.   That would have generated a lot more issues.