Copy VHD / data files into a CSV Disk -w2k8 r2

Copy VHD / data files into a CSV Disk

We need to use the Coordinator Node

Remember that CSV is optimized for running VM's, so using other tools and mechanisms... such as doing local copies to and from CSV disks from the partent partition is a very poor way to evaluate the performance.

This is expected behavior. Understanding read-writes and what happens when you copy between non-owner nodes will help you out.

What I do is if I need to copy data between CSV's is move the CSV resources to the same node and then copy,

With Cluster Shared Volumes (CSV) one of the nodes in the cluster is responsible for synchronization of access to files on a shared volume. This is the node which currently owns the cluster ‘Physical Disk’ resource associated with that LUN, which is referred to as the Coordinator node. Each LUN can have its own coordinator and all nodes are equal and could be a coordinator, so it could be any node. When a VM is deployed and running on a CSV volume almost all of Hyper-V’s access to VHD files associated with a VM go directly to the disk and the coordinator node is not involved. This enables VMs to have fast direct access and give great performance for the VM and the applications running within the VM. So it really doesn’t matter which node is the coordinator or where VM’s are running.

With Windows Server 2008 R2 one exception to that happens when you are copying VHD files to CSV volumes as you create and deploy your VMs. As you copy/create the VHD files to a CSV volume, those writes to the disk are extending write operations, and, as a result, they are redirected over the network to the coordinator node. This can result in it taking longer to copy the file. The moral of the story is that when you are going to do a file copy to a CSV volume, to get the greatest performance it is best to do the copy on the coordinator node if you are doing a local copy. If you are doing a remote copy over the network, it’s best to have the coordinator node be the target of the copy. You can view the current owner or even move ownership of Physical Disk resources from one node to another with the Failover Cluster manager snap-in (CluAdmin.msc) or PowerShell. So you can make whatever node you are on the coordinator.

Note:  With Windows Server 2012 an extending write operation will be done with direct I/O, and these considerations do not apply.

On that node, the writes are all local writes because it is the coordinator itself.

From the other node, the writes are actually redirected over the network to Node1 (because they are extending writes to the file).

So, what does that really mean?

The bottom line here is that if you’re trying to make copies of files to CSV and you want to get this copy to complete in the fastest possible time, make sure you do the copy on the coordinator node.