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
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.