So, here's my scenario: ESX 3.5 Enterprise (build 64607), vCenter 2.5. I am migrating my virtual machines to a new SAN as the old one is no longer sufficient. All of my machines are done being moved but one. The one machine left has 4 physical RDMs setup that house 250+ SQL Server database files (.mdf, .ldf, etc.). I am unable to use storage vMotion to move the virtual machine. I am just using the simple menus built into the vSphere client (right-click the vm and choose Migrate Storage). See the following screenshots:
The only thing I can conclude is that the physical RDMs are a limitation. However, I am finding conflicting information on this. Several blog posts out there indicate that physical RDMs cannot be migrated, but virtual RDMs can. But the following VMware KB article indicates ESX 3.5/VC 2.5 svmotion works find with physical RDMs (http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=100524...). I have seen suggestions to convert the RDMs to virtual, but I believe this will cause more problems than solutions. First, to do this you must remove the RDM from the vm and recreate the disk. I know this preserves the data, but SQL Server is extremely picky when it comes to losing communications with an mdf. Also, as I understand it, when using storage vmotion on a virtual RDM, the process actually converts the disk to a vmdk file. I do not want this converted, I want to maintain it as an RDM.
So, my questions are 1) is this possible with my setup and 2) can anyone point me in the right direction to accomplish this?
sVMotion could only move the p/vRDM descriptor files but not the data stored on the LUN's configured as p/vRDMs.
If you must stay on p/vRDMs, simply perform the following activities to migrate your data to the new array.
This procedure should allow you to migrate to the new array.
Thanks for the reply Ralf.
I'm not looking to migrate the data on the LUNs that the RDMs point to. I have already done that. The RDMs are currently pointing to the new storage. I'm just wanting to move the pointer. My concern is the following steps you have outlined:
My concern is that this step will have adverse effects on MS SQL Server as the operating system will interpret the reconnected RDMs as new disks and therefore not recognize the database files properly. SQL is pick about this and it's bitten me in the past.
got the point.
To the best of my knowledge, SQL isn't capable to use RAW devices, therefore, a NTFS partition is a must have.
And therefore SQL itself will only requires access to the file pathes, it doesn't use GUID's or UUIDs.
But the OS might have a problem with such change, but only under special conditions like
All components listed above do store additional information about a used LUN and might be affected of the change.
MSCS is easy to handle, the other topics are a bit more complex.
But you could easily check the solution by performing the following add ons.
I have completed my tests and wanted to report back to everyone. I created a duplicate vm with an identical configuration (Windows Server 2008, SQL Server 2008 R2, data and log files stored on two different physical RDMs). After finishing the setup I verified that database communication was functioning normally. I shut down the vm, removed the physical RDMs with the delete option, migrated the vm to a different storage array, added the RDMs back and everything started up normally. I tested a few more variations such as adding the RDMs back in the wrong order and choosing different virtual SCSI ID. Still everything functioned normally.
I have not run this on my production environment as I have been delayed with other projects. However, I wanted to make sure to update the forum and let everyone know what came of it.
Thanks for your advise Ralf.