Hyper-V Failover Clustering Using Normal Shares
Hyper-V have an option to use CIFS/SMB file server share as your option for Failover Clustering storage.
This solution can enable you to use Quick Migration and but only be truly highly available if you file share is also highly available.
Important performance issue - Windows Server 2008 file server does increased performance for this type of workload. However, this is no way near FC\iSCSI configurations and should be used only after throughout utilization tests.
Before and After Diagrams
Lets 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.
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).
Grant the required permissions for \\SPTSERVER1\VMSHARE\ to the computer accounts for STPNODE1 and STPNODE2, as described at http://blogs.technet.com/josebda/archive/2008/06/24/storing-windows-server-2008-hyper-v-files-on-an-cifs-smb-file-share.aspx.
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.
Install the Windows Server Hyper-V RTM patch.
You will need to have a domain infrastructure (Windows Server Failover Clustering requires a domain). The domain controller is not shown in the diagrams.
You start the process by creating a cluster with the two Hyper-V nodes. To do this, you will use the Failover Cluster Management MMC from either node. In that tool, you will:
- Validate the configuration
- Create the cluster
- Adjust the quorum configuration
- Create the virtual machine in one of the nodes
- Make the VM highly available
Here’s the initial screen of the Failover Cluster Management MMC, when first loaded.
Before you create the cluster, you must Validate your Configuration. Be sure to run *all* Validation tests, since solutions are only supported if you do so.
Since we are not using shared storage, the storage tests will generate a warning. Completing validation with a warning is acceptable.
If you run into any errors during Validation, you must fix those before you proceed.
Creating the Cluster
After you run validation, click the option to “Create a Cluster”. First, you must specify the nodes. In this case we’re using SPTNODE1 and SPTNODE2.
Second, you specify the name of the cluster.
After confirming the data entered, the cluster is created, as shown below:
Note that we end up with a warning (yellow triangle). If you click the “View Report” button, you find what the issue is:
No appropriate disk could be found for the quorum disk.
This is expected. With only two nodes with no shared storage, you don’t have a valid quorum configuration and a single node failure will cause the cluster to fail.
You can see that in the cluster information below:
Typically, in a shared storage configuration, you would get that third vote from a shared witness disk (also know as a quorum disk).
We will overcome that in the next step.
Configuring the Cluster Quorum Settings
To get our third vote for the cluster without using shared storage, we will use the new option in Windows Server 2008 Failover Clustering to use a file server witness.
First, you need to add permission for the cluster computer account to the file share. The cluster computer account was created when we created the cluster.
As you did when granting permissions to SPTNODE1 and SPTNODE2, add full control permissions for the SPTDEMO\SPTCLUSTER$ account in the share and in the file system at SPTSERVER1.
Next, use the Failover Cluster Management tool to change the Quorum Configuration.
You will find this option by right-clicking the cluster name, then selecting “More Actions”, as shown below:
The wizard will guide you through the process. You will select the option for “Node and File Share Majority”, as shown below:
In the next screen, you will specify the actual shared folder path for the file share witness resource. We will use \\SPTSERVER1\VMSHARE\WITNESS. See below:
After you confirm the operation, you will see the update in the quorum configuration, now showing no warning signs.
I would recommend that you also check the status of the storage in the cluster.
You do this by clicking on the “Storage” node under the cluster name in the Failover Cluster Management tool. Here’s what you should see at this point:
As you can see, this is one of the cases where you have a healthy cluster with no shared storage. Exchange Server 2007 CCR clusters also do that.
Creating a regular Virtual Machine on a cluster node
At this point, if you check the Hyper-V Manager tool, you will see no virtual machines:
Now we will use the Hyper-V Manager to create a new VM in SPTNODE1 using only a file share for storage. If you’re doing this from SPTNODE1, you should have no issues. If you’re doing this from any other computer (like the management client SPTCLIENT1), be sure to check this post on how to configure Constrained Delegation to allow remote management of Hyper-V when using file shares: http://blogs.technet.com/josebda/archive/2008/06/27/using-constrained-delegation-to-remotely-manage-a-server-running-hyper-v-that-uses-cifs-smb-file-shares.aspx
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:
More information can be found at source.