With the release of Windows Server 2008 R2, Microsoft's Hyper-V virtualisation platform gains a host of much-needed features. Microsoft has added capabilities to Hyper-V, making it a viable choice for production virtualisation. Nowhere is this more evident than with Hyper-V R2's new capabilities for host disk resources, specifically those used by highly available virtual machines (VMs) on top of a Windows failover cluster.
In this article, we cover Hyper-V's R2's new functionality in its Cluster Shared Volumes(CSV), which allow multiple virtual machines to be stored on a single logical unit number (LUN).
Hyper-V's disk limitations
You've likely heard the grumbling associated with Hyper-V R1's disk limitations. In the original version of Hyper-V, clustered configurations were forced into installing only a single virtual machine per connected LUN. Each new virtual machine in an environment required the creation of a separate LUN.
What is not well known is that this was not truly a Hyper-V problem. These initial disk issues were actually based on a limitation associated with the Windowsfailover clustering services in Windows Server 2008 release to manufacturing (RTM).
Think about the traditional NT file system (NTFS) and how failover clustering makes use of [its] disk resources. In the last version of Failover Clustering, each node in a cluster was aware that it did or did not own a virtual disk resource. The entire disk resource, regardless of the files and folders in it, was the boundary of cluster resource management.
This is problematic because an individual VM is also a cluster resource that depends on a particular node. So failover with a cluster resource requires the simultaneous failover of its dependant disk resource as well. With multiple VMs on the same LUN, failover of one VM took all the VMs with it.
To combat this problem, Microsoft adds Cluster Shared Volumes to Hyper-V R2. This new feature brings cluster awareness to Hyper-V disk resources, enabling the storage of multiple VMs on a single LUN.
But some confusion remains about the setup of this new feature. Even after upgrading to Windows Server 2008 R2, you'll find that the process to set it up involves a number of not-entirely-obvious steps. Here is the process to configure to enable this useful new feature:
- Step 1: Create a cluster. CSV is designed for use only in a Windows failover cluster. If your environment doesn't use high availability for Hyper-V VMs, none of these steps will be useful. Even with Hyper-V R1, virtual machines that aren't highly available don't have the same disk limitations. Thus, in a single-server situation, you can install as many virtual machines to a disk as you wish.
- Step 2: Enable CSV. Once a cluster is ready enabling the CSV feature is done within the Cluster Failover Manager console. This is the case even if your environment uses System Center Virtual Machine Manager. Click your cluster name in the left pane to bring forward the cluster properties screen in the middle pane. Once there, click the link to Enable Cluster Shared Volumes. Be aware that this decision cannot be reversed.
- Step 3: Enable disks for CSV. This is where much of the confusion lies in enabling CSV. Once the CSV feature has been enabled, a new node will appear in the Failover Cluster Management console. That node, titled Cluster Shared Volumes, provides a place to identify which disks should be enabled with the CSV feature. Be aware that any disks to be CSV-enabled must be empty. The console will not permit you to enable a disk resource that contains virtual machines.
- Step 4: Migrate VMs to CSV disks. Once its volumes are created, virtual machines can be migrated to CSV-enabled disks. This can be done through the manual export/import process in Hyper-V, or, if an environment uses Virtual Machine Manager 2008 R2, it might be easier to automate relocation or storage migration. When migrating VMs, enable each for high availability.
The location for disk storage changes once CSV is enabled and in use. The new default storage location for VMs changes to various subfolders of c:\ClusterStorage. This location is on the system drive of Hyper-V hosts, but that it is not the actual location of a VM's disk files.
CSV uses information stored on the root drive of every server in a cluster to determine ownership of files on the disk resource, and it operates as a set of pointers to the actual data stored within your cluster's shared storage. Because CSV will install this folder to the root drive on every server in the cluster, Microsoft requires that the root drive be the same on every server. This shouldn't be a problem for most environments because most still use the c:\ drive as the root drive.
Even with these new capabilities, you should still consider Cluster Shared Volumes to be a 1.0 release. In comparison with other file systems from third parties, CSV's cluster awareness is limited. As a result, you'll find that support has been added in Hyper-V R2 for third-party clustered file systems such as Sanbolic Inc.'s Melio FS or Veritas Volume Manager. These third-party systems provide greater support for cluster awareness than Microsoft offers out of the box.