Dear folks,
I have a question about how to best accomplish the following in ESXi 5.1:
We have an ESXi5.1 server that has a DAS Storage attached to it with 32Tb as a RAID60.
On the server, there is a virtual machine that needs that storage attached.
However, we cannot use a large VMFS datastore with a large VMDK file on it, since the storage must be formatted with NTFS, and able to be detached from the machine, and then be read by an NT computer if need be (It's a backup solution, and for DR we'd want to be able to just detach the storage and read it as NTFS without the hassle of an VMFS/VMDK layer).
I've read this article here (http://www.virtuallifestyle.nl/2010/01/recommended-detailed-material-on-rdms/), and it seems as though RDM is the way to go, but it seems like it is more of a hack to get this to work with a locally attached disk.
http://www.vmware.com/support/developer/vcli/vcli41/doc/reference/vmkfstools.html states that createrdm or createrdmpassthru can be used, but which one would I use for this purpose?
We would really prefer not to have to use Hyper-V for this because of it's physical disk pass through feature.
Could someone maybe chime on how to best accomplish this with ESXi5.1?
I'm curious. In a DR situation, how would you detached the DAS and put it on another server? Wouldn't DR mean the disk as well as the server is gone?
I don't believe this is going to work with DAS. Check http://kb.vmware.com/kb/1017704 and http://kb.vmware.com/kb/1017530 for more information.
What I meant was that the server only serves as a storage for backups at a remote location.
So in case something happens at the main site, we can just yank the storage from the DR site (after shutdown of course) and then bring it over to the main site (or whereever in case the site is gone) and start recovering from the plain NTFS volume that DPM uses.
I'm aware VMWare says this can't be done with ESXi, but people have gotten it to work from the command line with mapped vmdk files or disabled the RDMFilter in the advanced options.
I'm just wondering if there is any other way, because we'd like to be able to use the VinV that Hyper-V doesn't support, but Hyper-V lets you use passthrough disks without a hitch (locally or not).
In this case, yes. a Physical Mode RDM will do what you are looking for.
It will if its an external array that supports SCSI semantics (which it sounds like it is).
Great info as usual Matt!
Thank you, mcowger.
I have read that it is possible with these steps:
1. Get name of device from here: /dev/disks
2. Execute vmkfstools -z /vmfs/devices/disks/<name of RAW device from Step 1> <VMLocation>/<RDM name>.vmdk
3. Attach VMDK file to host
Also, I've read this is only possible on certain controllers. Those that support SCSI command 0x83 for globally unique ID's.
Is there an extra HCL for this kind of stuff?
We have two controllers in that server.
1. Adaptec 51245 with 3 RAID devices: 300Gb, 1Tb, and 5.4 TB
300Gb will have ESXi on it and a VMFS datastore for the systme drive of the backup server
1Tb disk will be a passthrough to another hypervisor
5.4 TB will be a passthrough to the backup server
2. LSI Logic HBA for DAS (I don't know the model off the top of my head, but it's the mptsas driver)
22.4 TB disk that will be a passthrough to the backup server
So I wish to create three passthrough disks, two of which are on the same controller as the ESXi.
Would it really be as easy as the three steps above, and if so, why doesn't VMWare recommend this?
Are you not able to use vSphere's DirectPath IO to present the storage adapter directly to the VM? I'm assuming you don't care about tying the VM to the hardware of that host, as it has a DAS connection anyway.
For the LSI yes, but how about the Adaptec?
It also hosts two other RAIDs for different purposes than passthrough, including the ESXi volume.
I am currently trying thise method here: http://blog.davidwarburton.net/2010/10/25/rdm-mapping-of-local-sata-storage-for-esxi/
I will report back with the results, but am curious why VMWare doesn't think this is a good idea.
It seems like this will work, as the controller presents the disk as a separate LUN:
/dev/disks/mpx.vmhba3:C0:T2:L0
The procedure described in the link I posted works flawlessly for us. That is what we'll be using.