Wow, it’s been a long time since I posted here. I’m going to try to get back into the habit, especially with issues that I can’t seem to find answers to anywhere else. Here’s one now:
My company recently bought a new SAN, and we are in the process of migrating the storage for our Windows Server 2008 R2 Hyper-V guest machines from using the Cluster Shared Volumes that are located on the old SAN to CSVs that are location on the new SAN.
We have connected the hosts to both SANs, and have set up new CSVs in the new SAN. We are using the Quick Storage Migration feature in SCVMM to migrate the storage. This should result in little downtime while the machines are being migrated from the old SAN to the new SAN.
Theoretically, this is a simple process. I say theoretically because, while this does actually work, it takes a little attention to detail to make sure this process happens smoothly.
The process as documented is fairly straightforward. The goal is to move both the VM definition files and the .vhd files from the old SAN to the new SAN. In SCVMM, this should be as simple as right-clicking the virtual machine, and choosing “Migrate Storage” from the context menu. After that, simply selecting the new CSV in the Virtual machine path drop-down menu and clicking Next should take care of the rest.
Unfortunately, that is not always the case.
In our environment, we store the .vhd files and the VM definition files (.xml, .bin, .vsv, etc.) in the same folder, named after the machine (i.e. SERVER01). When you select a new CSV from the Virtual machine path drop-down menu, the Virtual Disk Location should update to reflect the new path. For example, if you were migrating SERVER01 from C:\ClusterStorage\VMOldSAN to C:\ClusterStorage\VMNewSAN, your Virtual Disk path should update from C:\ClusterStorage\VMOldSAN\SERVER01 to C:\ClusterStorage\VMNewSAN\SERVER01.
But beware…that isn’t always the case.
I haven’t found a rhyme or reason as to why, but for some machines, the path simply doesn’t update. If you barrel forward in the process (by clicking the extremely tempting Next button), you’ll find that your VHD stayed where it was, but your VM definition files moved. And it’s the moving of the VHD files that takes so long, mainly because that operation is always completed using BITS.
So, how should a good (i.e. lazy, I mean, efficient) admin get around this issue?
The first instinct, of course, is to click the Browse button next to the Virtual Disk Location field. But beware! Doing so will either force you to create the directory first (which will mean that your VM definition files will end up in another directory called C:\ClusterStorage\VMNewSAN\SERVER01-1, autogenerated by SCVMM) – or if you choose the root folder (C:\ClusterStorage\VMNewSAN\), your VHD will end up in the root folder.
The most consistent way I’ve found to make this work properly is using Powershell. Fear not, those who are still holding out on Powershell…I have good news for you. SCVMM does its work under the covers with Powershell. So, the SCVMM Migrate Virtual Machine Wizard can generate the Powershell script for you. All you have to do is copy and paste it into Powershell.
Run the wizard as you normally do by right-clicking on the Virtual Machine, and selecting Migrate Storage. Select your new destination for the machine by selecting the new CSV from the Virtual machine path drop-down menu. If the path updates correctly, click Next and then Move. But if not, you still click Next, but then click the View Script button.
In the script, you should find a line that starts with Move-VirtualHardDisk for each .vhd file associated with the machine. You can ignore these lines.
You’ll then find a line starting with $VM =, a line starting with $VMHost = , and a line starting with Move-VM. Those three lines are the key. You can move the entire machine (including the .vhd files) with those three lines. So, copy them (in order) and paste them (also in order) into a Powershell window (important note: make sure import the System Modules when you start Powershell, and are running Powershell as an admin!) and your machine and its associated VHDs will be moved to the new path, creating the new directory along the way.
Hope this helps someone avoid the pain that I had during migration!