RDM Error - Help!

[Grove12]

I need to convert a physical server which has a 2.5 TB lun attached to it. RDM is the logical choice. Here's what went down:

• Presented 133GB lun for a new vmfs volume for this conversion and added it in vCenter

• Converted the C: partition of the target machine

• Cleaned up after conversion, i.e., removed hidden devices in device manager

• Presented 2.5 TB lun to the esx hosts in the cluster I wanted to use

• Shut down VM

• Added RDM and powered on VM

The OS recognizes the new volume and even goes so far as to assign it's "old" drive letter to it. Disk management shows a healthy volume and the correct size. Windows explorer on the other hand doesn't show any sizes and when you try to select the drive it displays the error "G:\ is not accessible. Incorrect function." I've completed these exact same steps in our test environment with absolute success. I'm stumped on this one. My thoughts:

• Perhaps I blew something up by cleaning up device manager. I removed some (not all) of the old, hidden devices before presenting the lun... this is standard stuff though. Could I have uninstalled something that's needed?

• The VMFS volume housing the C: partition and ultimately the RDM pointer file is only 133GB and the RDM itself is 2.5 TB. Is this an issue?

I was able to add the lun back to the physical box without losing data, thankfully. But I'm at a loss because I have to convert this server... I'd go with a vmdk but iirc converter has a size limit of drives it will convert, correct. Any ideas?

[kjb007]

I believe the 2 TB limit still holds for RDM's as well. Can you shutdown the server, remote the RDM, boot the server and verify all looks ok, at least for the server without the RDM?

-KjB

VMware vExpert

[Grove12]

Yeah, everything is fine with the VM. I thought the 2 TB limit was for vmdk only, not rdm as well. I found the "ESX Maximums" whitepaper after posting the discussion this morning. This is a real bummer. This really seems like something VMware should address. Now my only real option is to break up my lun in Navisphere into multiple, sub-2TB luns and present them all to the ESX hosts... not an easy task. I went from a 15 minute task to many hours. Ugh.

[kjb007]

The 2 TB limit was for a regular NTFS type partition as well. Did you not have to use GPT to make it work? Can you use your storage to present it as NAS? Then, you can mount it and use it that way, or use that to copy to a smaller LUN?

-KjB

VMware vExpert

[Grove12]

The lun we presented to the original physical box was formatted as a gpt, yes. I just didn't realize there was a limit for the rdm. Can't use NAS. We'll have to break it up to smaller luns... I just dont see a way around it. I guess we could use extents so it still shows up as a single volume to the OS... but extents kinda scare me.

[kjb007]

I use extents all the time, but that's not the only way you can go. Remember, in windows you can also use volumes in nested folders on a drive. So you can have 2 drives, one being your g: drive, and the 2nd drive be g:\new_volume. That will give you the space you need, but you'll still have to break up the LUNs to get to that point.

-KjB

VMware vExpert

[Grove12]

Agreed... mount points, extents, etc... I have options. It was just so appealing to store the data as one large, independant lun. That way moving it in the future, if needed, is a piece of cake. Extents and mount points seem to complicate that scenario. At any rate, thanks for all your suggestions.

[AndreTheGiant · Accepted solution]

If your storage is SCSI you can connect the big LUN inside the VM through a software initiator.

If your storage is FC (and your switches support NPIV) you can use NPIV to add a virtual HBA inside the VM and connect the LUN.

Andre

**if you found this or any other answer useful please consider allocating points for helpful or correct answers

[kjb007]

No problem. Don't forget to leave points for helpful / correct posts.

-KjB

VMware vExpert

[Grove12]

Of course npiv would work... doh!! I just opened a thread a few weeks ago about the benefits between rdm and npiv... obviously decided to go with rdm since it seemed like the easier solution at the time. But now knowing the 2 TB limitation exists, I will be testing and implementing npiv. Good call.

[AndreTheGiant]

You're welcome

Andre