I agree that breaking the storage encapsulation in Virtual Machines is generally a bad thing. What do I mean? That the entirety of the Virtual Machine is not contained in VMDKs stored on some datastore. Examples of this are RDMs, iSCSI in guest and NFS mounts in guest. In general, breaking the encapsulation model is something to do rarely, not frequently. Why? It makes management more complex, makes certain operations impossible (ergo you can’t do a storage vmotion for a device that is mounted via iSCSI in a guest). But – just like all things – there’s a couple reasons why the purists who say “Never!” should be walked away from… slowly… Real world example from yesterday. A customer is using Oracle 11g on an NFS datastore and has 1GbE connectivity. For those of you who read the blog post that Vaughn and I wrote here , you immediately see that you will be bound by the bandwidth (MBps) of a single vmnic on the NFS datastore, as the TCP/IP hashing used for link aggregation only applies if you have multiple TCP sessions, and NFSv3 uses only 2 TCP sessions (control and data) per datastore. So, in the spirit of being a purist, the answer is: Switch to a block datastore (which can parallelize across multiple links via RR or PowerPath/VE) Switch to 10GbE (drive more bandwidth down a single link – a lot more) And if you’re SUCH a purist that you would rather throw out the baby with the bath water rather than compromise dramatic principles: dont’ visualize that workload until a future vSphere release that supports NFSv4 or pNFS.