gesadmin
Contributor
Contributor

RDM: convert from physical compatibility mode to virtual compatibility mode

Using ESX 3.5, I would like to know how I can convert a RDM in physical compatibility mode to virtual compatibility mode. I'm sure I need to use vmkfstools -i but I don't know what other options I need to include with it. The reason I need to do this is because there were a couple of virtual machines created before my time here that mistakenly use RDM's. Ultimately my goal is to convert them to virtual disks, but when I attempt to vmotion and relocate the config file and disks (with the disks as RDM physical currently) I receive "Incompatible device backing for device 0". Any help would be great.

0 Kudos
13 Replies
kjb007
Immortal
Immortal

VMotion will work with physical compatibility with vmotion, so I'll assume you mean svmotion.

What you can do is shutdown the vm. Remove the disk. Re-add new disk, and select virtual mode compatibility, and select your LUN. That should be all.

-KjB

vExpert/VCP/VCAP vmwise.com / @vmwise -KjB
0 Kudos
gesadmin
Contributor
Contributor

I've tried shutting down the vm, removing the disk, and from there I've tried adding an existing disk and also a RAW device mapping. When I choose to add from an existing disk it adds the disk back in Physical compatibility mode and won't allow me to change. When I add a RAW device mapping my LUN is not listed there anymore. I hope I'm making sense.

0 Kudos
kjb007
Immortal
Immortal

Are you using an RDM mapping file, or selecting the LUN from a list? When you select existing disk, since the device file was created as a passthrough, it will always read in as physical mode. You should, however, remove the disk, save the config, rescan, and then edit the config again, and select RDM, and select the LUN from a list.

If this fails, you can create a new RDM file using vmkfstools, vmkfstools -r /vmfs/devices/vmhba2:2:2:1 diskname.vmdk. Then, go back into your vm config and add an existing disk using the mapping file you just created.

-KjB

vExpert/VCP/VCAP vmwise.com / @vmwise -KjB
0 Kudos
gesadmin
Contributor
Contributor

OK, I waited a few minutes and then went through the process of adding a new RDM and my LUN was visible again. I was able to successfully convert it to virtual which is good, but I am still unable to do storage vmotion between the RDM and a virtual disk. Every time I try I receive the "incompatible device backing specified for device 0". I have checked and rechecked all of the devices and it doesn't look like there should be a problem. Thanks for your help thus far.

0 Kudos
Texiwill
Leadership
Leadership

Hello,

Which method are you using for SVMotion? Plugin, RCLI, or powershell? I use the plugin with no major issues however, I only SVMotion VMDKs, for RDMs, I create a new RDM on the target system then use the Guest OS to copy the data from one to the other. Works out much cleaner this way. You can however now make a VCB or any other type of backup of the RDM and restore it as a VMDK.


Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.

Blue Gears and SearchVMware Pro Blogs: http://www.astroarch.com/wiki/index.php/Blog_Roll

Top Virtualization Security Links: http://www.astroarch.com/wiki/index.php/Top_Virtualization_Security_Links

--
Edward L. Haletky
vExpert XII: 2009-2020,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
0 Kudos
kjb007
Immortal
Immortal

Do you have any snapshots on the vm?

-KjB

vExpert/VCP/VCAP vmwise.com / @vmwise -KjB
0 Kudos
gesadmin
Contributor
Contributor

Sorry for the delayed response. No, I do not have any snapshots of the VM. I ended up creating a support ticket regarding this issue and so far support has been unable to solve it. I do appreciate the help thus far. I'll post back with the resolution once it's found.

0 Kudos
gesadmin
Contributor
Contributor

I've tried only with the plug-in so far. When I attempt to complete the SVMotion process it errors stating:

"The requested Storage VMotion would move a virtual machine's disks without assigning the virtual machine a new home, but such a move is not supported on host <hostname>"

I believe in reading the whitepapers that SVMotion will not work if I attempt to perform it without moving the VM to a new host, is this correct??

0 Kudos
kjb007
Immortal
Immortal

SVMotion is actually meant to move a virtual machine's storage from one datastore to another, on the same host. Not between hosts. Once the storage has been moved to a 2nd datastore, and that datastore is available on another host, then barring any other vmotion requirement shortfalls, you can vmotion the vm to a new host.

I've done my svmotion's using the perl script and not through the plugin, but the options to move a vm storage, can include the entire vm, or certain disks at a time, as well as the vm config file itself. Not sure if that's what you're having an issue with using the plugin. Have you tried the RCLI svmotion script?

-KjB

vExpert/VCP/VCAP vmwise.com / @vmwise -KjB
0 Kudos
gesadmin
Contributor
Contributor

"SVMotion is actually meant to move a virtual machine's storage from one datastore to another, on the same host. Not between hosts"

I apologize if my earlier posts were confusing, but this is exactly what I'm attempting to do. The VM has RDM's currently . I've created three new LUN's on my SAN and have presented them to the host that this VM resides on. I right-click the VM, select Migrate Storage and see all of the datastores that the host has access to. I select one of the RDM's and drag-n-drop it onto one of the new datastores that I've just created. I click apply on the GUI and after a few seconds I receive the error above. It seems to me that I am attempting to do the SVMotion to a different datastore on the same host, but it is not liking it. Perhaps I should attempt it with the script. I'll look around for it, but in the meantime if you could point me to it and also provide some examples of this in use that would be fantastic.

0 Kudos
kjb007
Immortal
Immortal

svmotion.pl is included with the VMware Remote CLI, either the install or the appliance. The help file for it is fair, and it allows an interactive format as well where it asks what it needs, and creates the command line on its own.

Start the interactive version.

svmotion --interactive

Relocate a virtual machine's storage (including disks) to new_datastore:

svmotion --url=https://myvc.mycorp.com/sdk

--username=me

--password=secret

--datacenter=DC1

--vm='[old_datastore] myvm/myvm.vmx:

new_datastore'

-KjB

vExpert/VCP/VCAP vmwise.com / @vmwise -KjB
0 Kudos
kgottleib
Enthusiast
Enthusiast

Sorry for the late post to this, but 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.

0 Kudos
kgottleib
Enthusiast
Enthusiast

Sorry for the late post to this, but 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.

0 Kudos