Converting VMDK to Physical RDM
I’;ve been having some issues with the conversion of a VMDK to a Physical RDM. This is a request from a client, as the storage and backup vendor has stated that there are advantages to doing this. Not something I have done before, but nothing wrong with that.
I found the KB article with ease: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=3443266
Steps looked straight forward, get the identifier and power down the server, run the commands. Yeah, Nah.
At this point, I’;m going to take the assumption that you already understand how to create an RDM for a VM using the VM settings.
Stop… Error Time, can’;t complete this!!!!
Destination disk format: pass-through raw disk mapping to ‘/vmfs/devices/disks/naa.6xxxxxxxxxxxxxxxx’;
Cloning disk ‘/vmfs/volumes/DS1/VM/VM.vmdk’;…
Failed to clone disk: One of the parameters supplied is invalid (1).
I first found that there are a number of articles referring to the conversion of RDM to VMDK and Physical RDM to Virtual. Unfortunately, articles and posts about the process I am attempting are around vSphere 3.5. Back then the command structure was a lot different and I couldn’;t adapt that.
According to the VMware article, there are two commands to run for the conversion, depending on if you want to convert to Physical RDM or Virtual RDM
The difference in the commands is that Virtual uses “rdm” and physical uses “rdmp”.
However, using rdmp gave the error above. After a good period of time and\ oOn the brink of a bottle-o run, I looked into converting virtual RDM to physical RDM, as well as digging more around RDM in general. Maybe I could convert VMDK > Virtual RDM, then Virtual RDM > Physical RDM.
I found that converting Virtual RDM to Physical RDM is easier then finding bad coffee at Starbucks.
I ran the conversion using rdm instead of rdmp. After that, I removed the VMDK files that it generated.
Edit VM Settings > Add > RDM Disk > Select device used in the conversion command. The default mount setting is physical.
To verify I run
After booting the VM was the final test and everything appears good. The drive mappings in Windows also remained correct which was nice.
All is good in the land of OZ and I hope this gives the client the benefits that they have been told it will.