Now that you’ve built this nice, shiny brand-new Hyper-V environment, how do you use it to its full potential? Like most administrators, you’re most likely not planning on only provisioning new workloads on this environment. You have existing workloads on physical servers that are providing services on your network, and for most of those, it doesn’t make sense to rebuild them from the ground up. You have to migrate them into your virtualized environment. This is known as a physical-to-virtual (P2V) conversion.
Alternatively, you may have an existing virtualization platform from which you want to move VMs onto your Hyper-V platform. If the existing platform is Hyper-V, you can use the techniques you learned in Chapter 14. Techniques for migrating workloads from other platforms will be covered in this chapter.
How do you go about moving those workloads (operating system [OS] included) into VMs on your new Hyper-V solution? This is the question that this chapter will answer. While the migration story centered on Hyper-V has always been something of a moving target, there are native Microsoft tools that will get the job done, even if they all have their own problems, issues, and caveats.
In This Chapter and Beyond
At this stage in the game, you’re able to create new Hyper-V hosts, clustered or stand-alone, and manage new and existing hosts. You know how to provision and manage virtual machines (VMs).
Now we’re filling out your knowledge with some final topics and information to make your transition into Hyper-V administration easier. This chapter will focus on migrating existing workloads into your Hyper-V environment. Topics to come in later chapters include Hyper-V Replica, Containers, and System Center Virtual Machine Manager. Let’s get started.
What Workloads Are Candidates for Migration into Hyper-V
Before we get too far into the “how to perform a migration” question, let’s first talk about what workloads are a good fit for migration. While most existing physical servers can be virtualized, there are those that just don’t make sense, from an operational perspective.
A common source of concern, for many administrators, is Active Directory (AD). We find that many administrators are often very timid when it comes to making any changes regarding the domain controllers (DCs) in their environments. AD is a critical part of a modern Windows environment and is not fully understood by many administrators. When people start migrating their DCs into a virtualized environment, their knee-jerk reaction is to use a conversion utility to turn the DC into a VM.
Converting a workload into a Hyper-V VM isn’t a destructive process by any means, but it can be time-consuming, and you may have to take the workload offline, depending on the utility you’re using to do the conversion. This is the primary reason we always steer administrators away from using conversion utilities with DCs. Remember: AD is designed to be a replicated highly available service.
If you have more than one DC in a domain (and if you don’t, we recommend you stop reading and create a second one immediately), all DCs will talk to each other and replicate AD data among themselves—automatically. Not only is this useful as a high-availability mechanism, it can also be used for migrations.
When it comes to DCs, we always recommend that administrators simply create a new DC on the virtualized solution, let the information replicate from the old DCs to the new virtualized one, and then decommission the old DCs once you’re happy that the new DC is working correctly and your users can log on. The specifics are a bit more complicated but are outside the scope of this book.
As a rule of thumb, if the workload you’re attempting to convert has its own built-in replication and migration technology, the best approach is to build a new server on the Hyper-V infrastructure and allow the workload’s replication system to transfer the needed data. Not only is this method cleaner, it’s also less prone to issues and errors. AD was simply used as an example in this case; other similar situations would include Microsoft SQL Server, Microsoft Exchange, and DNS.
Another factor to consider when performing a physical-to-virtual conversion is the hardware in the original server. If the hardware isn’t available as a virtual component in Hyper-V, for example, fax boards or licensing dongles, you won’t be able to perform a straight conversion.
What Tools Are Available?
We mentioned earlier that Microsoft’s story around migrating workloads into Hyper-V has always been a moving target. The tool set has changed many times, and the information coming from Microsoft hasn’t always been consistent. There are a number of different tools that support different situations and budgets. Microsoft’s support for these tools has changed, as they’ve been removed and then added back into the tool set a number of times over the last several years. It can be difficult to know the currently supported tool set and what works best in your situation. There are a number of tools readily available to move your workloads onto Hyper-V.
Note
If the disks you want to convert are encrypted, or the data is encrypted, we recommend that you perform an un-encryption before undertaking the migration to Hyper-V. You can re-encrypt the data once your new VM is up and running on Hyper-V.
It’s not possible for us to supply you with a complete listing of the available tools for migrating workloads onto Hyper-V. The tools in the rest of the section provide a good selection of possibilities, and one of them should meet your needs. An Internet search will enable you to discover other tools, if these don’t meet your needs.
Microsoft Virtual Machine Converter
Microsoft Virtual Machine Converter (MVMC) is a free utility that can be downloaded and used to migrate live workloads into your Hyper-V environment. It’s a decent tool; has PowerShell support, which lends itself well for automating the process; and has a high degree of success. MVMC will convert an existing VM, for example, a VM running on VMware, to a Hyper-V VM.
However, there are some things to be aware of. Officially, this tool was deprecated as of June 2017. MVMC is often the best method for moving workloads into Hyper-V. This is one of the main tools we’ll be covering in this chapter, so you’ll hear more about it shortly.
Disk2VHD
Disk2VHD is a free Sysinternals command-line tool that has been around for some time. This tool is designed to create a virtual disk from an existing workload. Disk2VHD takes a copy of a running machine and copies it into one or more VHD files—one per existing disk. You can control which disks are converted. The VHD file is attached to a new VM on your Hyper-V host.
As with MVMC, this tool also has a history of a high degree of success. Unlike MVMC, this tool has to be run on the machine that it is actually converting. This tool can be downloaded from https://technet.microsoft.com/en-us/sysinternals/ee656415.aspx .
System Center Virtual Machine Manager or Virtual Machine Manager
There’s a chapter later in the book covering the basics of Virtual Machine Manager (VMM) . With VMM, you have the ability to convert physical workloads to Hyper-V VMs, and it works pretty well. However, VMM is not a free tool. In order to gain access to VMM, you have to purchase the entire System Center suite, which could be costly and, often, not within the reach of small and medium-size businesses.
If you do happen to have VMM available to you, you can access a how-to on converting workloads to Hyper-V at https://technet.microsoft.com/en-us/library/hh427286(v=sc.12).aspx .
Azure Site Recovery
As far as age is concerned, this tool is the youngest of the bunch. Azure Site Recovery (ASR) is a service providing disaster recovery to the cloud. ASR takes a running copy of your targeted machines and places a copy in Microsoft’s Azure public cloud. Then, if something happens to your on-premises location, you can start those workloads inside Azure, for business continuity.
ASR can also be used for workload conversions to Hyper-V, with a few caveats. When Microsoft said that MVMC was being deprecated, they targeted ASR as its successor. However, ASR requires a pretty significant footprint in your datacenter, so it’s not without significant hardware and monetary costs. It’s not easy to set up, and all conversions go straight to Azure (as of the time of this writing).
If you want to have that workload in your on-premises infrastructure, you must download the virtual disk and attach it to a new VM in Hyper-V. So now you have to wait for that workload to traverse your external network—twice—before you can fire it up in Hyper-V. It is hoped that Microsoft will continue to make improvements to this product.
Issues with Physical-to-Virtual Conversions
A physical-to-virtual migration is probably a rare occurrence these days, but there will be organizations that haven’t embraced virtualization, for whatever reason. If you do get involved in a P2V migration, you must be aware of a number of issues.
Hard drives: If the source machine is using RAID drives, you may have disk errors when trying to boot the VM. You’ll have to try and repair Windows to surmount the errors.
Drivers: Windows will hide drivers for which it can’t find matching hardware. You’ll have to be sure you move the drivers and ensure that any corresponding devices are removed.
You’ll almost certainly have to reactivate Windows, as the machine’s hardware signature will have changed. Moving an OEM copy of Windows breaks the licensing agreement.
You may also have issues with support from software vendors. Some vendors still won’t support their application in virtual environments, and some won’t support software that’s been through a physical-to-virtual migration.
Note
Back up. Before you even think of performing a migration—P2V or virtual-to-virtual—make sure that you have a backup of the source machine. You should have at least one backup and also verify that the backup can be read and that data can be recovered from it. Having to explain to senior management why its critical application isn’t available, because the server broke during a conversion, and you don’t have a usable backup, will not be a comfortable experience. Always make sure you have a usable backup!
Performing a P2V migration is a difficult lab to create, so we’re concentrating on walking you through using MVMC, for the practical work in this chapter. It’s important to know how to do this, as you’ll want as many of your existing workloads virtualized as possible. When all your workloads are running within Hyper-V, it allows you to lower your administrative overhead and take advantage of the full range of all the various Hyper-V features we’ve been talking about throughout the book. Let’s take a little time and take a closer look at MVMC.
Using the Microsoft Virtual Machine Converter
As mentioned, MVMC was deprecated as of June 2017. So, one of the first questions you’re going to ask is why you should waste time learning a tool that was going to be deprecated, and following is our answer.
Even though Azure Site Recovery (ASR) has been named the official successor for this functionality, it is nowhere near ready as of this writing. It has a hefty footprint, and moving things to Azure and then back is just not viable, especially if you have a lot of machines to convert.
Additionally, learning how MVMC works will help you to understand how the workload conversion/migration procedure works. You’ll have a strong understanding of how the process should work, which can be transferred to other tools, if required.
Microsoft Virtual Machine Converter–Supported Operating System Types for Host and Guest
Supported Destination Hyper-V Host Operating Systems | Windows Server 2008 R2 Windows Server 2012 Windows Server 2012 R2 |
Supported Source Host Operating Systems | Windows Server 2008 R2 Windows Server 2012 Windows Server 2012 R2 VMware vCenter/ESXi 4.1, 5.1, 5.5 |
Supported VMware Hardware Versions | 4, 7, 8, 9, and 10 |
Supported Guest Operating Systems | Windows Server 2008, 2008 R2, 2012, 2012 R2 Microsoft Windows Vista and newer versions Red Hat Enterprise Linux 5/6 CentOS 5/6 Ubuntu 10.04/12.04 SLES 11 Debian 7 Oracle Linux 5/6 |
As you can see, there is no mention in the list of Windows Server 2016 (or later versions) being supported. That doesn’t mean it doesn’t work, it’s just not supported. It goes without saying that when attempting to convert to an unsupported host, or attempting to convert an unsupported guest OS, you’ll want to test, test, test, before allowing the machine to be placed into production using this tool. And don’t forget your backups!
ABOVE AND BEYOND
If you want more information on MVMC, the best source is the article available at https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn873998(v=ws.11) .
The article and download are labeled as MVMC 3.0 but are really MVMC 3.1.
MVMC is a fairly simple tool to use, but there are a few things you must be aware of. It’s best to install and run this tool from an independent “worker machine” that is separate from the target and the destination workloads. This machine has to have enough free space to accommodate the size of the workload you’re converting. For example, if you have a file server that has a 40GB C: volume and a 600GB E: volume, your worker machine must have roughly 650GB of free space, so plan accordingly.
Another thing to note is that MVMC will make a new virtual disk for each volume, not disk. So, if you have a single disk that has three volumes on it, MVMC will create three virtual disks during the conversion process, all of which will have to be attached to the new VM prior to booting it. Let’s do this now on a test machine.
Note
For this exercise, you’ll need an operating system (OS) installed somewhere outside of your Hyper-V lab that can be used for the conversion process. This could be your management workstation or another server you have running in the lab. Keep in mind that after the conversion, the target workload will still be there and functional. This is a nondestructive process, and the newly virtualized instance will be removed afterward.
- 1.
Download MVMC from the following link: https://www.microsoft.com/en-us/download/details.aspx?id=42497 .
- 2.
Install MVMC on an independent workstation, separate from the target or the destination.
- 3.
Launch the utility after installation. You’ll be greeted with a screen very similar to that shown in Figure 15-1.
MVMC beginning window
- 4.
Click Next to Continue.
- 5.
Select whether this is a Virtual Machine Conversion (in the case of VMware VMs or some other hypervisor) or a physical machine conversion.
- 6.
Click Next.
- 7.
Select Migrate to Hyper-V and click Next.
- 8.
Enter in the fully qualified domain name (FQDN) of the destination Hyper-V host, followed by the credentials for your Hyper-V host, or use your Windows User Account, by clicking the check box.
- 9.
Click Next.
- 10.
Select the path on the Hyper-V host on which you would like to store the converted virtual disk.
- 11.
Select Dynamically Expanding (which consumes disk space as it grows, remember?) for the virtual hard disk type.
- 12.
Select VHDX as the virtual hard disk format, as it is the preferred format and contains all the latest enhancements.
- 13.
Click Next.
- 14.
Fill in the source machine information. For example, in Figure 15-2, for a VMware VM as the source, you must fill in the vCenter/ESXi FQDN and credentials.
MVMC Source window information screen
- 15.
If connected to an ESXi or vCenter server, select the source VM and click Next. If you selected a physical machine, you will not have this step.
- 16.
Click Next.
- 17.
On the Virtual Machine Connection window, enter the credentials for the source OS, then determine the final state of both the source and destination machines, so that they can be powered on or off after the operation.
- 18.
Click Next.
- 19.
Define a location on the machine running MVMC where you would like to have the disk conversion take place. Remember: This has to be a location that is large enough to accommodate the size of the workload that is being converted.
- 20.
Click Next.
- 21.
Review the Summary Screen and then click Finish.
- 22.
Monitor the Job to Completion and take note of the files being created in the workspace you defined on the machine running MVMC.
- 23.
Review the results and click Close.
- 24.
Log in to Hyper-V Manager, connect to the target host, and verify that the newly converted machine is shown in the list.
- 25.
Using the Virtual Machine Properties UI, make sure the NIC is disconnected for the new VM, and power it on.
- 26.
Verify the OS boots and note that it’s the same machine now running within a Hyper-V VM.
- 27.
If the machine was a VM, remove any hypervisor guest software, such as VMware Tools.
- 28.
If you’re doing an official cutover, you’ll want to shut down the source machine and then attach the newly converted VM to a vSwitch that can talk with the production network.
TRY IT YOURSELF—CONVERTING A PHYSICAL MACHINE USING MVMC
Convert a physical machine in your environment. This could be a workstation or a server. Additionally, you could set up a small VM on top of Hyper-V and use MVMC to target it as if it were a physical server.
The process was fairly straightforward. You configured MVMC to connect to the source machine, made a copy of it in a new VHDX on the worker machine, and then pushed those files to the defined Hyper-V and used them to make a new VM.
It’s pretty simple and works most of the time; however, there are a few things that can create failures. Applications that create high amounts of disk IO are often the main culprits. Heavy SQL Server or Exchange workloads are common issues, and antivirus software has been known to create issues for MVMC from time to time. In those situations, if you get a failure on the first attempt, it’s best to disable any services that are likely to create high amounts of disk activity and then re-enable them, once the conversion is completed.
Once you have successfully converted a workload, it’s highly recommended that you test it extensively prior to using it for production. You want to make sure that all software packages on the newly converted machine continue to work correctly.
If you need to convert several machines, you should consider using PowerShell. If you’re looking for more information on using MVMC in this way, the PowerShell documentation can be found alongside the download for MVMC.
Lab Work
- 1.
Complete the Try It Yourself sections in the chapter.
- 2.
Create a VM on your Hyper-V host with a different OS. This could be a different version of Windows, or it could be a version of Linux (Ubuntu, for example).
- 3.
Once that VM is running, use MVMC and target it as if it were a physical machine.
- 4.
Once converted, test the new VM and simulate performing an official cutover to it.