显然，有很多方法可以分割您的原始SAN LUN来提供虚拟机引导和数据虚拟磁盘 – 但是您使用的是什么方法，它们有哪些优点/缺点，以及是否有任何好的“最佳实践”文档遇到（其他然后非常通用的VMWare的我的意思）。 提前致谢。
在我工作的地方，我们一直在展示500GB大小的ESX服务器光纤连接LUN。 由于SCSI预留问题，似乎500GB是FC连接存储到ESX的最佳大小。
一个很大的趋势是使用NFS挂载的存储为您的ESX数据存储，尤其是现在10Gbps以太网正在成为主stream。 NFS在传统光纤附加存储以及ESX环境中具有许多优点。
这将有助于了解您正在使用的存储types，因为不同的存储具有可用于VMware环境的不同function和选项。
正如你已经推测这不是VMware的问题，但是是一个SAN问题。 TR-3428，它的VDI表弟TR-3705在NetApp SAN上做了一个很好的概述了VMware的实施。 这些文档在非netapp SAN上有争议的用处。 因为他们没有考虑到你的SAN的优势/缺点。 说了我对这件事的看法。
有很多原因打破你的数据存储。 ESX3.5上最普遍的原因无疑是locking的。 一些select有OS / Boot数据存储和应用程序数据存储，但是我发现任何性能提升都可能忽略不计。 通过将临时数据从操作系统分离到单独的数据存储中，我已经看到了真正的性能提升，但是为了使此技术可行，您必须将其redirect到高性能数据存储。
最后，我回到每个vmdk一个vmdk，并处理exception。 我这样做有两个原因，一个是我发现最好的实践太复杂了。 这不仅是一个设置的熊，但往往系统SA会搞砸否定任何可能的收益。 经常引起对vm性能的拖累。 二，今天的sVMotion，这真的不像以前那么重要。 以前，你需要知道所有的答案。 现在，如果你喜欢结果继续往那个方向发展的话，那就摇摆一下吧。 虚拟现实是动物，没有两个虚拟基础设施看起来相像。 因此， 最佳做法是有限的使用。 反复试验将最终为您提供适合您环境的最佳解决scheme。
所有这些，我通过NFS使用NetApp（与重复数据删除（IN PRODUCTION）），并运行一个600GB的数据存储，我平均60 vm的….对我来说，NFS提供的整合比超过了性能的打击。 less数（less于10个）虚拟机pipe理的需求比NFS可以提供的要求更高，位于iSCSI数据存储（250GB）上。
TR-3428是一个非常有用的指南，在过去我曾经使用过很多，如果您使用的是NetApp存储， 它还包含一些常规的ESX / SAN信息，如果您使用其他存储供应商，这些信息可能会有用。