One of the big changes Microsoft made to Hyper-V with the release of Windows Server 2012 is that virtual machine components such as virtual hard disks, configuration files and snapshots can be stored on SMB file shares through support of Server Message Block 3.0. This is a radical departure from previous versions of Hyper-V, which supported only local storage, Fibre Channel SAN or iSCSI SAN. Storing virtual machines on SMB file shares...
can help lower storage costs and eliminates the need for administrators to have specialized storage knowledge.
In spite of these benefits, it is important to understand that SMB 3.0 file shares are only one of the types of storage that are supported by Hyper-V. Cluster Shared Volumes are still Microsoft's preferred storage type for Hyper-V clusters. The use of SMB file shares for Hyper-V is generally suitable only for small and medium-sized organizations because the amount of available bandwidth (controlled by the speed of the server's network interface card) and disk I/O constraints with SMB limit the number of virtual machines that can reside on each share.
Before you consider storing virtual machine components on Server Message Block file shares, there are a number of prerequisites and best practices that must be taken into account.
The first requirement is that the file server must support SMB Version 3.0. (During Windows Server 2012's preview release, Microsoft stated that SMB Version 2.2 would be supported for use with Hyper-V. Version 2.2 was later renamed to Version 3.0.) In most cases, this will mean running Windows Server 2012 on the file server. Non-Windows operating systems are also supported, as long as they conform to the SMB 3.0 standards. In case you are wondering, Hyper-V will not stop you from storing virtual machine components on a file server that is using an older version of the SMB protocol, but doing so is not supported, and the Best Practices Analyzer for Hyper-V will detect the legacy file share and generate an alert.
Another important consideration to take into account is that using SMB file shares with Hyper-V is supported only in Active Directory environments. However, legacy Active Directory domains are supported. The domain controllers do not have to run Windows Server 2012.
After familiarizing yourself with these relatively simple prerequisites, the next step in the process is to plan your storage architecture. At first this might seem strange since the whole point of using an SMB file share is to simplify the overall storage requirements. Even so, you simply can't overlook the need for reliability.
A virtualization host server typically runs multiple virtualized workloads. This means that if the host server fails, the virtualized workloads will also fail, thus resulting in a major outage. The only way to protect against this type of failure is by implementing redundancy. The need for redundancy does not go away just because you are taking a more economical approach to virtual machine storage.
Technically, there is nothing stopping you from running a virtual machine on a standalone Hyper-V server and having the virtual machine components reside on a standalone file server. The problem is that this type of configuration offers no redundancy. The Hyper-V server, the file server and the connectivity between them are all potential single points of failure.
Some IT administrators try to work around this problem by building a Hyper-V failover cluster using an SMB 3.0 file share in place of a Cluster Shared Volume, but this approach requires very careful planning. It allows virtualized workloads to fail over to another cluster node in the event that a Hyper-V server fails. The file server itself can provide storage redundancy by employing a fault-tolerant storage array. It is important to realize, however, that the file server itself can become a single point of failure. If the file server were to drop offline, the Hyper-V servers will lose storage connectivity.
A better approach than either of the above is to use a dual-node or even a multinode file server. Dual-node and multinode file servers typically abstract the server itself from the underlying storage. Rather than using local storage arrays, each file server is connected to a shared storage device using Fibre Channel or iSCSI.
Of course, this raises the question of why an organization would even consider connecting Hyper-V to file servers that use shared storage when they could provision Hyper-V with a dedicated shared storage device for less money (since file servers are not needed).
If an organization is building a Hyper-V deployment from scratch, it is more efficient and more cost-effective to connect Hyper-V cluster nodes directly to a shared storage pool than to link Hyper-V to file servers and connect the file servers to a shared storage pool. The only situation in which it would make sense to use file servers with Cluster Shared Volumes would be if there are budgetary issues and the aggregate workload is light enough that the file servers can comfortably handle both Hyper-V-related I/O and user-generated file storage traffic.
The use of SMB storage can help smaller organizations reduce storage costs and complexity in their Hyper-V environments. Even so, it is important to consider performance and reliability before you commit to using SMB file shares.
Brien Posey is a freelance technical writer who has received Microsoft's MVP award six times. He has served as CIO for a national chain of hospitals and health care companies and as a network administrator for the U.S. Department of Defense at Fort Knox, Ky.