If you have been reading up about the features of Hyper-V 2.0, you probably read about Clustered Shared Volumes or CSVs. Basically, CSVs are the main ingredient to the (not so) secret sauce that makes Live Migration work.
A clustered shared volume can be created from any existing volume in a failover cluster. If you have an existing volume formatted with NTFS, you can mark it as a CSV and it will show up in the Failover Cluster Manager as a CSV. Note that existing data on the NTFS volume is not touched in any way.
On the compatibility side you should know the following:
- CSVs in Windows Server 2008 R2 only support Hyper-V
- There are no special hardware requirements and you can use the same technologies as a standard cluster disk: iSCSI, FC, SAS
- There is no limit on directory structure
- No agents or other software needs to be installed
- Not another file system – it is standard NTFS
Note that this is not a clustered file system like VMware VMFS of Sanbolic’s Melio FS. There is no distributed lock manager or anything like that. What CSVs deliver is a distributed access file system.
CSVs provide a single consistent file name space. This means that every node in the cluster has the same path to the volumes. You will see the CSVs under the %windir%\ClusterStorage directory. For example:
- c:\ClusterStorage\Volume1\<root>
- c:\ClusterStorage\Volume2\<root>
The only thing you need to do after adding the CSVs is to put VHDs on the clustered shared volume (using the paths shown above) and create the virtual machine using Hyper-V Manager making sure that you put the configuration files on the CSV as well. You can then use the Failover Cluster Manager console to make the virtual machine highly available just like how you do it now. Basically, the only thing that changes here is the creation of the CSV and making sure that you place your virtual machine on the CSV. All the other steps are exactly the same as how it currently works.
With the current implementation of Hyper-V, you need to put each virtual machine in its own LUN if you want the virtual machines to failover to different hosts or if you want to quick migrate the virtual machines independently from the others. CSVs in Windows Server 2008 R2 remove this limitation. This also results in less wasted storage space and basically a better storage management story.
From an architectural perspective you should know that only one node in the failover cluster still owns the CSV LUN. That node is called the coordinator and it basically manages how the disk access should work. There is one such coordinator for each shared volume. You do not have to worry about selecting a coordinator as that is taken care of automatically. When the coordinator fails, there is no impact on virtual machines that are not running on the coordinator itself.
Microsoft did not provide any clear information about how the access to disk is actually performed. Basically the answer to our questions was that the coordinator decides what the best path to the storage is: direct access or over the network. Yes, you read that right: access to the LUN from one node might be redirected over the network via SMB to another node that writes to the LUN. Again, I have no information about when that exactly happens.
We also learned that the implementation of CSVs is done with a mini file system driver called CSVfilter.sys. Being a new filter driver, there might be some impact on other components such as backup software. Microsoft is working with backup and storage vendors and its own DPM team to clear up these issues. What I can say is that there is a new VSS API call called PrepareVolumeForSnapshotSet and that this needs to be used by VSS Requesters. The node that initiates the VSS backup also needs to become the coordinator node (happens automatically) because it needs to manage exactly what happens with the CSV volumes. The CSV volumes stay online during the backup but there will be no direct I/O until the backup ends. I guess that means that access to the LUN from other nodes will go over the network to the coordinator and from there to the LUN.
What is my take on this? Well, it seems like an overly complex solution to make something like Live Migration and HA work for individual virtual machines on a single bigger LUN. I guess that results from the fact that Microsoft decided to work with the existing NTFS file system instead of creating a dedicated file system optimized for virtual machine storage. On the other hand it does deliver extra features such as SAN I/O redirection over the network when the storage path to the SAN array completely fails.
More information about CSVs can be found in the R2 reviewers guide.
