TomR_CAW
Contributor
Contributor

Storage vMotion with Physical RDMs

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:

Disk Setup.jpg

svMotion.jpg

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?

Thanks.

0 Kudos
6 Replies
TomR_CAW
Contributor
Contributor

bump

0 Kudos
kastlr
Expert
Expert

Hi Tom,

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.

  • on new array, create LUN's in needed size
  • present these LUN's as p/vRDMs to the VM
    • Hint:
      select a Datastore which resides on the new array to store the needed p/vRDM descriptor files.
      Best selection would be to store them on the same datastore you plan to place the VM on.
  • format the newly added LUN's with NTFS and assign drive letters
  • stop all SQL related services (and any other application/service which might change data on the old p/vRDMs)
  • use robocopy (or richcopy) to copy data from old to new disks
  • when done, remove drive letter from old disks and reuse them for the new LUNs
  • power off the VM and remove the old p/vRDMs
    • select remove from VM and delete from disk
    • data on p/vRDM's will be untouched (so it's still there if needed)
  • remove the newly added p/vRDMs
    • select remove from VM as this will leave newly created descriptor files at the datastore you did choose initially
  • without p/vRDMs you should be able to run the sVMotion job for the remaining disks
  • when completed, add existing p/vRDMs and select the descriptor files from the target datastore

This procedure should allow you to migrate to the new array.

HtH

Ralf

Hope this helps a bit.      Greetings from Germany. (CET)
0 Kudos
TomR_CAW
Contributor
Contributor

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:

  • remove the newly added p/vRDMs
    • select remove from VM as this will leave newly created descriptor files at the datastore you did choose initially
  • without p/vRDMs you should be able to run the sVMotion job for the remaining disks
  • when completed, add existing p/vRDMs and select the descriptor files from the target datastore

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.

0 Kudos
kastlr
Expert
Expert

Hi Tom,

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

  • MSCS
  • dynamic disks (or another LVM)
  • VSS

are used.

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.

  • power off the VM
  • open SSH connection to one of your ESX servers
  • Clone any vDisk of your VM with vmkfstools -i <input> <output> -d <format> to the new array
  • create another VM with same HW specs as the original one and assign all p/vRDMs
  • start this VM and check functionallity

HtH

Ralf

Hope this helps a bit.      Greetings from Germany. (CET)
0 Kudos
TomR_CAW
Contributor
Contributor

Thanks Ralf.  I'll give it a go and let you know.

0 Kudos
TomR_CAW
Contributor
Contributor

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.

0 Kudos