微软在新发布的Windows Server 2012版本中的较大改动之一便是Hyper-V的虚拟机组件，虚拟硬盘、配置文件以及快照信息都可通过SMB 3.0协议存放在SMB文件共享上。而上一个版本的Hyper-V仅支持存放在本地存储、FC SAN或者iSCSI SAN环境中。将虚拟机存放在SMB文件共享上可以降低存储成本，也消除了管理员对专业存储知识的要求。

除此以外，SMB 3.0文件共享协议也是目前Hyper-V唯一支持的存储协议。集群共享卷（Cluster Shared Volumes）也仍然是微软偏好的Hyper-V集群存储类型。Hyper-V环境对SMB文件共享的使用仅适合中小型企业，最主要的原因是服务器本身可以提供的网络带宽和磁盘I/O非常有限，这会限制每个共享上虚拟机存放的数量。

在考虑将虚拟机组件存放在SMB文件共享之前，可以先参考以下建议和最佳实践。

第一个要求就是文件服务器需要支持SMB 3.0版本（在微软Windows Server 2012的预览版中SMB版本号为2.2，后来更新成了3.0版本）。在大多数情况下，这都意味着要在文件服务器上运行Windows Server 2012。其实，Windows以外的操作系统也支持，只要能满足SMB 3.0即可。也许你会有些疑虑，使用旧版本的SMB协议也能将虚拟机组件放置在文件服务器上，但并不支持这样做。最佳实践分析工具（Best Practice Analyzer）会检测Hyper-V上的旧版本文件共享，然后发出警告。

另一个重要的考虑因素是Hyper-V上的SMB文件共享仅支持活动目录（Active Directory）环境。其实，传统的AD域也是支持的，而且域控制器不用运行在Windows Server 2012上。

在了解完这些简单的前提条件后，下一步就是规划存储架构。也许这样说会有些奇怪，因为SMB文件共享的意义就是简化整体存储需求。但即便如此，我们也不能忽视整体存储的可靠性。

虚拟主机服务器通常会同时运行多个虚拟工作负载。这便意味着如果主机服务器发生故障，虚拟工作负载也会停止，由此带来的后果是不堪设想的。唯一的解决方式就是实施冗余。在虚拟化场景中高可用性或者冗余度的考虑丝毫不能降低，但我们使用了一种更为经济的做法。

从技术上说，在单独的Hyper-V服务器上运行虚拟机，然后将虚拟机文件存放在单独的文件服务器上是没有问题的。问题是在这样做无法满足高可用性方面的要求。Hyper-V服务器和文件服务器之间的单路链接会成为单点故障的发生点。

一些IT管理员试图通过SMB 3.0文件共享搭建Hyper-V灾备集群以替代集群共享卷，但是需要非常谨慎。这样做的好处在于一旦发现Hyper-V服务器发生故障，虚拟工作负载会迁移到其它集群节点上。而对文件服务器来说，它自身也可通过后端容错存储阵列提高其存储冗余度。但同时需要意识到的问题是文件服务器是单点故障；一旦它本身出现故障，Hyper-V服务器将会丢失所有存储连接。

有个更好的做法便是在上述两种方法中使用双节点甚至多节点的文件服务器。这样的部署方式通常会将其自身从底层存储中抽象出来。无需运行在本地存储阵列上，每个文件服务器都通过FC或者iSCSI协议连接到一个共享存储设备上。

当然，这样做又会带来另外的考虑，既然Hyper-V本身可以使用专有的共享存储设备以降低成本，为什么还要额外投资文件服务器呢？

如果企业是从零开始部署Hyper-V环境，那么相比于使用文件服务器连到共享存储池，的确 Hyper-V集群节点与共享存储池连接更有效率也更加节省成本。唯一需要在使用文件服务器作为集群共享卷的场景，是当对聚合负载要求足够小，文件服务器本身足以处理来自Hyper-V相关I/O负载以及用户相关的存储流量的时候。

使用SMB协议存储可以帮助小型企业降低Hyper-V环境下整体存储成本及复杂度的需求。 即便如此，在使用SMB文件共享的同时，也需要充分考虑性能及架构可靠性方面的因素。