!! Best Practise VM server and backend storage !!

Cheapest and fastest is to have the data drives inside the server, a SAN doesn't speed things up since it is an extra step in the path between the users and their data. A SAN does offer high availability though if you want to cluster two servers together so one can fail while the other keeps going. You can also provide high availability with DFS so really no great advantage in having a SAN at all in this case.

Have you considered using a Windows Storage Server based NAS? Most computer manufacturers do these, http://www8.hp.com/uk/en/products/file-object-storage/product-detail.html?oid=5335825#!tab=features , http://www.dell.com/us/business/p/powervault-nx-series etc.

I would recommend create a VM and add a large iSCSI disk using iSCSI initiator.

If OS crash, you can attach iSCSI drive to new server. This reduce your Fileserver down time.

This method will have slow IO compared to directly attached hard disk.

Trouble is a highly available iSCSI SAN storage box can cost more than two servers. Sure you can make iSCSI storage from something like freenas running on another server but then you've just transferred the risk of a fault stopping it all from working from the clustered front-end NAS heads to the single point of failure on the back end. Redundant iSCSI solutions don't come free.

let me clarify a few things.  we already own the hardware, so we would not be purchasing anything additional.  We already have a cluster of vmware hosts and we already have SAN storage on the network.  Essentially, I just want to know the consensus from the experts whether the Virtual Server should have two virtual hard disks - 1 for the OS and 1 for this large file share.  Both of these virtual hard disks would actually reside on the iscsi SAN which hosts the datastore for the VMware cluster.  OR - option 2, we create only 1 virtual hard disk (for the OS) then we make an iscsi initiator connection to a SAN (different SAN than the one used for the vmware datastores) on our network.  So essentially in this scenario we have a VM that has an iscsi volume that hosts the file share, rather than having the fileshare being another virtual hard disk in the vm.

Does that help to clarify and to get back a consensus?

I know there have to be many vmware experts out there that can chime in on this.  looking for best practice for the question posted please.  thanks in advance.

Neither have you considered purchasing a NAS?

a non-server or computer based device for this storage.

I have gone the iSCSI mount inside the VM for about 6 years under Microsoft virtualization. I did this because I could expand the data volume on the fly, reattach the data volume to any physical or virtual machine, and I got snapshot level integration with my backup software. With the current ecosystem, you can pretty much do all of that with VMware and now Hyper-V,  with the possible exception of easily mounting a VMDK to any sever. When you iSCSI mount a volume inside a guest, you now have to treat the machine as physical for backup purposes. It's generally easier to do a virtual backup of a server than a physical backup, so I recommend the multiple VMDK route unless you find that it has a limitation (like volume size, clustering with physical server, etc.)

Now what I personally do wasn't one of your options, but I'll mention it incase it could work for you: I don't use iscsi or vmdk because I don't have a file server vm. My San backend is bsd and Its domain joined so I use samba to share right off that. My FTP and svn and other vms that need those files use mapped drives. It keeps my vms slim so I can run them on a small ssd array. Last time I had to install a new FTP server I just made a new vm, pointed it at the file share, and changed DNS. Once it was tested I turned off the old vm.

Let me throw one other option into the mix- rdm....would it make more sense to just map an rdm to the San where the file storage data volume resides?

You could use a RDM, but vSphere 5.5 now supports 62TB virtual disks (VMDK).

But RDM can give you SAN snapshotting functions.

Basically you need to lay out the 4+ different ways of doing this, then look at each of them, mostly from a backup/restore perspective. Like how you can restore a single file or folder of a user deletes something. Talk to your San guys and see what they think and what kind of snapshot capabilities your San has. Can you pull from a snapshot or do you have to ask them, etc...

People delete or overwrite stuff accidentally on file servers all the time.

I agree that you really need to look at it from a backup and restore perspective, as well as how easy it is to grow volumes. I find that doing normal file restores is often best handled through the native shadow copy/previous versions functionality of Windows.

our file level restores seem to work just fine with AppAssure the way things are now...I haven't ran into any issues restoring single or multiple files or directories...sounds like there are several ways to do this and all of them work.  maybe I'll just keep them like they are as virtual disks