How to migrate Virtual Machines to a CSV

This article describes the steps required to achieve high availability for virtual machines using Cluster Shared Volume. In addition this scenario presumes that you are already using Hyper-V stand-alone and would like to migrate virtual machines already in use. To achieve this you either use SCVMM or you have to use the export / import functionality on Hyper-V Manager and to make the imported machine highly available using Failove Cluster Manager.

Preliminary Steps

Consider the following scenario: you have already deployed a VM on a stand-alone Hyper-V under a folder on a local drive C:\VirtualMachines. Although that it is possible to make this virtual machine highly available and the High Availability Wizard will go through all the steps, a warning is displayed at the end of the process, stating: "Disk path ‘C:\VirtualMachines’ is not a path to storage in the cluster or to storage that can be added to the cluster. You must ensure this storage is available to every node in the cluster to make this virtual machine highly available". You will not be able to live migrate the machine because the files were note moved during this process.

To deploy a consistent Hyper-V environment check the following recommendations. Once a CSV is created and dedicated for VHD repository you can adjust the Hyper-V Manager settings to point to this volume. At the figure below both the VHD and XML files will default to the first CSV.

Further before migrating check that the VMs are offline, disable auto start (this will be managed through the failover cluster) and dynamic memory is disabled (you can enable it once more after the migration though). Also have a look at all the settings for anything else with local assignment, such as DVD mapped to local ISO file or network mapped to a virtual switch that is not present on the destination Hyper-V host.

Export the VM(s)

Use Hyper-V Manager to export the VM(s) to newly created CSV. If you point to C:\ClusterStorage\Volume1 as exhibited above a new folder with the machine’s name is created and three subfolders, one for snapshots, one for the virtual drives and one for the configuration will be created. Wait for completion – the status will be shown on the right corner in percentage. Make sure that all files and folders are created on the new shared volume. At the next step delete the virtual machine from the Failover Cluster Manager (if you were following our trial and error on the preliminary steps). Despite the fact that you are prompted that all resources are deleted as well, the latter apply only to the failover clustering resources – your VM-files will still be available on the local drive. At the last step delete the VM from the Hyper-V manager. This will effectively delete only the configuration files and folders but keep VHD intact. Don’t delete these for now!

Import the VM(s)

Proceed with importing the machine from the most appropriate server, for instance the one that is going to host the VM primarily. Using Hyper-V Manager right click on the chosen host and select Import Virtual Machine. Select the folder with the machine name. Leave the settings as move or restore the virtual machine and click import. This is the place to revert the dynamic memory settings if needed. Also check any other settings, for example the mapping of the virtual networks, etc.

Configure for High Availability

In this last step, using the Failover Cluster Manager, right click Services & Applications and Configure a Service or Application. Choose Virtual Machine and then select the newly imported VM. Wait for the High Availability Wizard to finish and check that there are no warnings. You can view the properties of the high available machine and adjust the preferred owners, persistent mode, auto start, failover and failback settings. As soon as you are done start the virtual machine and check its consistency, i.e. that all services on it a up and running.

Only after you make sure that everything is OK, proceed with the deletion – or preferably archiving – of the original VHD file(s) on the local drive (the ones that were used before the migration).

Remarks

There are certainly deviations from that scheme not mentioned explicitly. One possible scenario is to move the VHD files manually and then adjust the VM configuration, bit this would hardly speed up the process. Another way around is using the GetAssociatedVHDLocations.vbs and ImportVM.vbs scripts as described in “Migrating Clustered Virtual Machines to Windows Server 2008 R2”, still this is genuinely thought for migration from one cluster to another. Any comment with experience on the latter will be highly appreciated here.

Links