6 Replies Latest reply on Mar 18, 2011 3:31 PM by kgottleib

    Storage migrations with RDMs

    Buck1967 Novice

      I'm migrating images to a new storage frame. Things are working really well but I've hit ran into a few images that were implemented many many moons ago with RDMs. The kicker is they are in physical compatibility mode so I can't simply migrate them and convert them to a vmdk. Any thoughts on an approach to migrate them? Only approach that comes to mind is to use VMconverter. That would require a small down time so I'll need to schedule that out. I have a lot more flexibility on when I can migrate the images if I could use storage motion since it does require downtime for the images. At least there are only a few that fall into this category but the are the images that have some of the larger disk attached at like 500G-1TB...

       

      Buck

        • 1. Re: Storage migrations with RDMs
          AndreTheGiant Guru
          User ModeratorsvExpert

          Have a look at this KB:

          http://kb.vmware.com/kb/1005241

           

          Andre

          • 2. Re: Storage migrations with RDMs
            Buck1967 Novice

            Good info, but this is the limitation I'm trying to over come...

             

            • Physical Mode RDM pointer files can be relocated to the destination datastore, but cannot be converted.

             

            What process are people using if the want to convert a Physical Mode RDM disk to a vmdk?

             

            Buck

            • 3. Re: Storage migrations with RDMs
              a.p. Guru
              vExpertCommunity WarriorsUser Moderators

              You have to remove the RDM from the VM and select to delete the virtual disk, which effectively only deletes the mapping file. Then you have to recreate the mapping file on the destination host or folder by adding the disk to the VM as a RDM.

               

              André

              • 4. Re: Storage migrations with RDMs
                TomHowarth Guru
                User ModeratorsvExpert

                What is your end position, is it a machine without RDM's attached or is it a Guest on the new storage with new RDM's

                 

                the approach is different for both.

                 

                if it is the former than just storage migrate,  do not click the advanced button and this will convert your RDM into a standard VMDK, (I found this out by accident when I forgot to press the advanced button to exclude my RDM's)

                 

                the alternate method to have RDMs at the end point is harder.

                 

                you will need to migrate the VMDK files and recreate and move the data from the RDM on the retired Array to the replacement array,  consult with your vendor on migrations strategies, as they may acutally havea tool to help you.

                • 5. Re: Storage migrations with RDMs
                  kgottleib Enthusiast

                  Buck - I realize this post is old, but I just came across it and thought I would fill you in on how to migrate RDM LUNs in physical compatibility mode.  I have read so many posts stating it can't be done but it is actually much easier than you could imagine, but the VM has to be powered down.  Here's how:

                   

                  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. 

                   

                  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.

                  • 6. Re: Storage migrations with RDMs
                    kgottleib Enthusiast

                    Forgot one thing, 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=3443266

                    1 person found this helpful