How to Migrate and Convert Physical RDMs

[kgottleib]

I figured someone needed to step in and straighten this MESS out.   This is what you need to do, fully explained the way each and every post should be.  You must power the VM down to do this, there is no way to do it live.  Period

1)  log into ESX console as root

2)  navigate to your virtual machine folder:  /vmfs/volumes/vmfs-volume-freindlyname/vm-folder/

3) locate the pointer file for your disk, this is not the -rdmp file, this is the servername_1.vmdk, it is only a few KBs, inside it does nothing but point to the actual disk file, which in this case will be the servername_1-rdmp.vmdk.  It is this servername_1-rdmp.vmdk file that maps IO to the actual lun which is always represented by ESX as something like vml.xxxxxxxxxxxxxxx and can be viewed in /vmfs/devices/disks/

The source you are looking to migrate (with this method it is actually a copy which is good, because the source is always left intact) can be a virtual disk, virtual rdm, or physical rrdm, it doesnt' matter, you will always use the servername_x.vmdk file as the source in the command string you are about to see...

but before I continune, if you want to migrate from physical compatibility mode lun to a new physical compatibility mode lun, be sure to have provisioned the lun so ESX can see it.  If you are to convert the physical mode RDM to virtual RDM, the same applies.  If you are to convert it to virtual disk, just be sure you have a vmfs volume with enough space to accomodate the new disk.

4)  here it is:

To migrate and convert physical RDM to virtual disk:

vmkfstools -i servername_1.vmdk /vmfs/volumes/vm folder/servername-newdisk_1.vmdk

To migrate and convert physica RDM to virtual RDM, there are two methods

-  in vi client edit VM settings of powered down VM, remove rdmp mapped disk, then re-add a new hard disk selecting the same disk only be sure to select virtual as the mode, you will log in and see all of your data and mount points are unchanged.

-  from the ESX prompt in the virtual machine folder on the VMFS volume:

vmkfstools -i servername_1.vmdk -d rdm:/vmfs/devices/disks/vml.xxxxxxxxxxxxxxxxxxxxxxxx  /vmfs/volumes/vm folder/servername_1-rdm.vmdk

To migrate physica RDM to a new physical RDM:

vmkfstools -i servername_1.vmdk -d rdmp:/vmfs/devices/disks/vml.xxxxxxxxxxxxxxxxxxxx /vmfs/volumes/vm folder/servername_1-rdmp.vmdk

Command strings EXPLAINED:

vmkfstools -i is the import \ clone command

the servername_x.vmdk is the source, the x will stand for the order of the device, in my example I use 1 which means this is the second disk on the VM.  the first disk file is servername.vmdk, this is typically always the system disk.

the -d is the disk type for the destination you are converting to

the rdm(p) is part of the disk type telling the destination disk what the raw disk mode is, virtual or physical  (the p means physical obviously)

the /vmfs/volumes/vm folder/servername_1-rdm.vmdk  tells us the location of where to store the raw disks mapping file, I have chosen to put it in the virtual machine folder as you can see, you can put it on any vmfs file system, I like to keep things neat and clean.

Figuring out which vml.xxxxxxxxxxxxxxx is tricky..  I the ls-lh command on the /vmfs/devices/disks/ directory to list the unfriendly volume names out and figure out which one is mine by the LUN size, there are other ways to do this, there is a VMware KB article that describes other ways to dump out this information.  and in some cases, depending, there may be a partition involved and it would look like vml.xxxxxxxxxxxxxxxx:1 or :2 or whatever..  vmware's KB references it as vml.xxxxxxxxxxxx:p

you can also use vmhbax:x:x: in the string as such:   /vmfs/devices/disks/vmhbax:x:x:p to represent the raw LUN

check out this article, it has what you need, but not everything.. the example they use for the disk is naa.xxxxxxxxxxxxxxxxx  and I believe this is because there is different storage in use then I have...   SO, be sure to navigate to /vmfs/devices/disks/ to see how vmware lists out the disks as the storage presents them

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=344326...

Hope you find this useful, don't let anyone tell you that you can't migrate a physical RDM.  Its bogus information.  This is how its done.

[idle-jam]

thanks for sharing 😄

[Bandolero]

Hi

Your post will be a crucial  peace of information to perform RDM migrations

Thanks for posting

[kgottleib]

Thank you for your kind reply.

I did want to update something above:

the naa.xxxxxxxxxxx number is the LUN ID as presented to ESX, you can also see this # in many places throughout the gui.  ESX will map this ID to a vml.xxxxxxxxxxxxxx number and you can see the mapping by running ls -lh /vmfs/devices/disks/

After having done more, I have now found it particular easy to figure out what vml.xxxxxxxx you need to use for your command string, the naa.xxxxx #s all appear in numeric order and only the last portion of this naa.xxxxxx number is unique, so it actually becomes very easy to figure out which LUN is which by looking at both the size of the LUN and the tail of the naa.xxxxxxxxxxxxxxxx.  

the best part of all this is that windows will recognize the new LUN or virtual disk you migrate your data to as if it were the original disk, no juggling of windows partition assignments needed.  YOu can do this in MSCS configuration as follows:

1)      1. Take the source disk resource offline in MSCS

2)      2. Power down both VMs

3)      3. Remove the primary \ source disk from both VMs

4)      4. Identify the vml# of the LUN to be used as RAW DISK

5)      5. Execute vmkfstools –i source_disk –d rdmp:/vmfs/devices/disks/vml#xxxxxxxxxx /vmfs/volumes/volume/VMfoldername/vmdisk-rdmp.vmdk

6)      6. Add the LUN to the VM as a new RDM in physical mode and adjust the virtual device node to what the source disk was, then set the virtual scsi    adaptor's sharing mode to physical

7)      7. Power VMs up

😎      8. Bring the source disk recouse back online

9)      9. Extend the disk with diskpart if desired to get the extra space included with the new LUN (the cluster resource must be online to do this)

[henrypan1]

Cool kgottleib

Any update on ESX 5?

Thanks & Happy 2013

Henry

[kgottleib]

Ill look into it and post soon. Thanks and happy new year to you also.

Ken

Sent from my iPhone

[Dipopobe]

Hello kgottleib,

Tried your steps and keep getting this issue with "Failed to open 'Xen-DC_2.vmdk': Failed to lock the file (16392)." tried everything from looking for a .lck file, which is non existing and shutting down the vm at which point it complains of not finding the vmdk file to checking if any other vm's have acess to the LUN which is not so.

Any pointers would be well appreciated, will need to use VConverter instead if everything else fails.

Thanks

Dipopobe

[kgottleib]

Hi There - thanks for your inquiry.  Locked file typically means that the VM is live, or the file is in use.  There is a VMware KB about locked files, not sure what the link is but you can do a search for it and follow the instructions to unlock the file.

Now, you state when you power down the VM you get an error message stating that the file can't be found.. I would look at the VM's .vmx file and see if the scsi disk exists in the and what path is shown to the file.  Perhaps you have lost the path to this particular LUN that is attached to the VM??  Navigate to the ESXi host's configuration tab and check out the status of the storage devices to see if the path is down.

[kgottleib]

This article has just been tested in vSphere 5.1 and all commands are the same.  Enjoy!

[kgottleib]

Since this "HOW TO" was first written there has been a lot of KBs and other blog posts on this topic, and some are extremely useful in understanding the processes and behaviors around migrating and working with RDMs. 

Just the other day I was presented with an issue where a VM migrations were performed on VMs hosting MS cluster.  Soon as I was invited into the call I heard everyone talking about how the RDMs were converted to VMDKs.  And after hearing this, I immediately pointed out that the best course of action would be to leverage vmkfstools -i to migrate the VMDK into a raw LUN using the techniques outlined in this VMware KB:

VMware KB: Converting a virtual disk into a Raw Device Mapping

However, this recommendation turned out to be premature, why?  becuase when I finally looked at what resided on the storage, I was looking at servername_3.vmdk and servername_3-rdm.vmdk. 

What does this tell me?   that there is a mapping file for a virtual mode RDM present.

So what happened?  the RDM wasn't converted during the migration after all?   Bingo.  To get a better understanding of the various scenarios I refered to this article by Cormac Hogan of VMware:

Migrating RDMs, and a question for RDM Users. | VMware vSphere Blog - VMware Blogs

Best to review the above links to gain a higher level of knowledge and understanding around RDMs, when they are accidentally converted, and how to convert them using the vSphere client and or vmkfstools command utility.