Migrating Hyper-V Virtual Machines from Server 2008R2 to Server 2012
As part of our Migration and Deployment Series today we shift the focus to Hyper-V migrations. First let’s start with a chart on what is possible for upgrading in place:
Standard, Enterprise, and Datacenter editions of Windows Server running Hyper-V are supported as either source or destination servers.
Upgrading to the stand-alone product “Microsoft Hyper-V Server” is not supported, however importing VMs via the migration techniques outlined in this article is supported.
Since in-place upgrades of server operating systems is not something many administrators like to do for various good reasons, a simpler way to upgrade the Hyper-V infrastructure is to simply blow away the current operating system, then install Server 2012 fresh on the hardware. The following steps will describe the process of upgrading the infrastructure without upgrading the OS in place. Before getting started there are some really important file locations we need to take note of:
• VM Config (XML) files
• VM Data (VHD) files
• VM Snapshot (XML) pointer files
It is wise to remove, revert, or apply(depending the individual scenarios) all snapshots prior to proceeding. however it is not required.
Notice first that by default in 2008R2, the VM Config and Snapshot files are located in a separate place from the Disk files. (ProgramData\Microsoft\Windows\Hyper-V)
The Virtual Disk files are located in by default in another folder (%Profile%\Documents\Hyper-V\Virtual hard disks), hopefully in production these files are located on centralized or some physical disks other than the profile directory:
We are now assuming that a Windows Server 2012 instance is available for us with Hyper-V enabled. If you have not prepared the server yet you can follow along the lab guides found here to get started, skipping the steps for booting to a VHD of course. So what we want to do is consolidate the folders shown above to a LUN or separate disk than the operating system, then copy them to the target server or mount the LUN that includes the contents, so that effectively we end up with this collection of subfolders together available on our target Hyper-V system:
Next we will want to launch the Hyper-V Manager and click on “Import Virtual Machine”
Browse to the location and select the “Virtual Machines” folder:
You should be presented with a list of VMs ready to be imported:
At the next screen we are asked to choose one of three options.
Register – Assumes that all files exist in this consolidated folder and that the files will continue forward residing in this folder
Restore – Registers the VM configuration files in their current location and copies the other necessary files to new location
Copy – Copies all VM files to a new location for the VM to continue forward running in the new location
For simplicity sake I will leave these VMs in the same folder, however best practices would tell us to make sure the disk files are stored on the fastest disk possible, and normally set away from the hypervisor and applications directories.
Now because we are adding virtual machines to a new server it is important to point out that prior to booting any of these virtual machines we will want them pointed to the right virtual switch. Fortunately the Import Wizard will ask for this. If you have not setup the Virtual Switches to match the source Hyper-V servers, now would be a good time to do so, then proceed with importing the VMs. Notice that all of the Virtual Switches appear in the drop down menu. This will happen for each network card found in the VM. Once you have selected a switch for each network card the Wizard will proceed to the next step.
Finally you will see a summary page for the Import process about to take place.
You should now see the VMs in Hyper-V Manager ready to start up. Take a look at the properties for each if you want to be sure that everything imported properly.
We will dig into the Powershell method of importing VMs in the near future as well so stay tuned!
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)