P.S.: After writing this blog post, I found that the specific scenario of using Hyper-V VHDs files on a file share is not supported by Microsoft in Windows Server 2008. This is documented at http://technet.microsoft.com/en-us/library/dd183729.aspx. Look for a note that says “Network-attached storage (NAS) is not supported for Hyper-V”.

Overview

In a previous blog post, I described 5 different ways to implement Windows Server Failover Clustering with Windows Server 2008 Hyper-V. Those options included: Parent-based Failover Clustering with two physical servers, Child-based Failover Clustering with two physical servers, Mixed Physical/Virtual Failover Clustering, Failover Clustering with two child partitions on one physical server and Standalone demo laptop with Virtual iSCSI SAN. If you missed that one, check http://blogs.technet.com/josebda/archive/2008/06/17/windows-server-2008-hyper-v-failover-clustering-options.aspx.

However, I failed to mention in that post the option to use CIFS/SMB file server share as your option for Failover Clustering storage. This scenario is so unique (with differences in flexibility, cost and performance), that I would argue it constitutes a sixth method. Here’s how you can do it.

Before and After Diagrams

As I did with the previous blog post, let me describe the scenario using two diagrams. First, here is a diagram describing the scenario before a failure:

Now, here’s a diagram describing the scenario after a failure in SPTNODE1:

As you can see, we use a file server (called SPTSERVER1) for storing the Hyper-V files. The idea is to store the configuration files, the VHD itself and the VHD snapshots in the \\SPTSERVER1\VMSHARE\VM1 folder. As we do when using a SAN for shared storage, the surviving node will take over and start the VM in case of a failure. We can also use the very same scenario for Quick Migration, making the VM move orderly from one node to another by saving the state to the file share and instructing to other node to take over and restore the VM.

Pre-requisites

Before you move forward, you want to make sure you have at least two physical computers running Hyper-V. In our scenario, STPNODE1 and STPNODE2 are running Windows Server 2008 Enterprise (Full or Core installs work fine).

Add the Hyper-V role to STPNODE1 and STPNODE2.

Add the Failover Clustering feature to STPNODE1 and STPNODE2.

You will need to use a general purpose server to act as a file server or a NAS box compatible with CIFS/SMB. You probably want to run Windows Server 2008 for improved performance (new TCP/IP stack and SMBv2 protocol). In our scenario, STPSERVER1 is the file server running Windows Server 2008 Enterprise Edition (Full or Core installs work fine).

You might also want to have a management client which could be your desktop (running Windows Vista SP1) or another server (running a Full install of Windows Server 2008). In our scenario, SPTCLIENT1 is the management client.

Again, this is done through a wizard. This is a regular VM creation, except for the fact that we’re using UNC paths (file share paths) for the storage, instead of regular folders on a local disk. In my specific case, we’re storing this new VM at \\SPTSERVER1\VMSHARE\VM1.

Here you see the virtual machine configuration folder:

Then the location of the new VHD file for the VM:

And even the ISO file we’re mounting will also come from that file server:

Once all is confirmed, we have a new VM, which you should keep in an “off” state for now:

Making the Virtual Machine Highly Available

Now we go back to the Failover Cluster Management tool to make the newly created VM highly available.

Click on the “Services and Applications” node under the cluster name and select the option to “Configure a Service or Application”. Again, it’s a wizard:

After selecting “Virtual Machine” as the type of service, you will select from a list of existing VMs. In our case, there’s only VM1:

After confirming your settings, the VM is made highly available, with a warning:

Again, if you click on the “View Report” button, you find the issues

The path ‘\\SPTSERVER1\VMSHARE\VM1’ where the virtual machine configuration is stored is not on a failover cluster and might not be highly available. To achieve the highest availability, store the virtual machine configuration on a clustered file server (configured within a failover cluster).

The path ‘\\SPTSERVER1\VMSHARE\VM1’ where the virtual machine snapshots are stored is not on a failover cluster and might not be highly available. To achieve the highest availability, store the virtual machine snapshots on a clustered file server (configured within a failover cluster).

The path ‘\\SPTSERVER1\VMSHARE\VM1\VM1.vhd’ where the virtual hard disk is stored is not on a failover cluster and might not be highly available. To achieve the highest availability, store the virtual hard disk on a clustered file server (configured within a failover cluster).

The path ‘\\SPTSERVER1\VMSHARE\ISO\WindowsServer2008-amd64.iso’ where the virtual hard disk is stored is not on a failover cluster and might not be highly available. To achieve the highest availability, store the virtual hard disk on a clustered file server (configured within a failover cluster).

As it usually does, the Failover Cluster Management tool is being very careful, pointing out that the file server share you are using is a potential single point of failure.

In order to have true high availability, you need to make sure that file share is also highly available. To achieve that, you need to place that file share in Failover Cluster as well.

The wizard has no way to detect if the file share is also clustered, so you will always get these warnings.

Now, you can go back and check the properties of the new highly available VM and bring it online.

One interesting thing you will notice is that you will not have any storage associated with that service, as you can see below:

In the summary page, you also confirm that, since you do not have the typical clustered disk listed in the summary for the virtual machine:

Moving the VM to another node

The last step is to prove that you can fail or move the VM to another node.

To do this, I use the option to “Move this service or application to another node”, which you can find when you right-click the virtual machine. See below:

When you do this, you will see that the VM will be taken offline in the source node (the state is saved first), as you can see below:

Then the VM will be brought online on the destination node (by restoring the state). Check below:

This process takes only a moment, and will depend only on how much memory you VM has and how long it takes to save the state to the file server share (from SPTNODE1) and then to restore the state from that same file share (from SPTNODE2).

You can see the final state, after the move to SPTNODE2 is completed, below:

Conclusion

I hope these steps will give you enough to recreate this scenario in your environment and validate that you can create a Failover Cluster for Hyper-V using only a CIFS/SMB file share for storage.

Keep in mind that, if your configuration can pass the Failover Cluster Validation with only a warning due to the missing shared storage, you solution is supported.

Also remember that this solution will only be truly highly available if you file share is also highly available. I’m sure you will find plenty of documentation out there on how to make file servers highly available.

Last, there is the question of performance. As I mentioned in the previous blog post using Hyper-V with file shares, I was impressed with the increased performance of a Windows Server 2008 file server, specially for this type of workload. However, I will leave it to you to test this configuration for yourself and draw your own conclusions about performance. With faster IP networks (including 10Gb Ethernet) and the improvements in the SMB v2 protocol, you might be tempted to trade performance for the added flexibility and reduced cost this could bring to your Hyper-V storage management.