Hyper-V's Server Message Block (SMB) 3.0 support can cut storage costs, complexity

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

    Requires Free Membership to View

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.

This was first published in January 2013

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.