Amazon now provides a direct migration path via the server that will allow a Hyper-V virtual machine to be converted into an AWS EC2 instance. Although the conversion process is relatively easy to work through, it takes a significant amount of prep work to get Hyper-V VMs ready for migration. This article discusses some of the more important things that you will need to do to prepare to migrate Hyper-V virtual machines to AWS. For the purposes of this discussion, I am going to be focusing solely on Windows VMs.
Licensing
One of the first things that you will need to consider before migrating your Hyper-V virtual machines to AWS is how your VM will be licensed in the cloud. When a Windows VM runs on-premises, that VM uses the same license as the Hyper-V host. You will typically need a separate license for the VM once it has been moved to the cloud. Amazon gives you the option of either using a license that you provide or replacing the VM’s original license with a license provided by AWS. It is worth noting that if a VM is running a client OS such as Windows 10, then you will have to supply the license (Amazon calls this Bring Your Own License. or BYOL).
Checking the minimum requirements
Amazon’s Server Migration Service has some inherent limitations, and not all Hyper-V virtual machines can be migrated. As such, you will need to check to make sure that the VM meets a number of requirements.
One such requirement is that you can only migrate Generation 1 VMs. Unfortunately, there is no way to downgrade a Generation 2 VM to Generation 1. If you need to move a Generation 2 VM to the AWS cloud, you will most likely have to create a new VM in the cloud and then copy your on-premises VM’s contents into the new cloud VM.
The easiest way to determine a VM’s generation is to use PowerShell’s Get-VM cmdlet, as shown in the figure below.
Another limitation is that the VM’s boot volume has to use MBR partitions and cannot be larger than 2TB. Similarly, the root partition needs to exist within the same virtual hard disk as the Master Boot Record.
Non-boot volumes can use GPT, but cannot exceed 4TB in size. Although such volumes are allowed, the VM cannot be attached to more than 22 volumes. Regardless of volume type, virtual machine volumes cannot be encrypted. It’s also a good idea to make sure that each volume has at least 6GB of free disk space.
The easiest way to check a VM’s disk configuration is to use the Disk Management Console. You can launch the Disk Management Console by entering the DiskMgmt.msc command at the Run prompt, as shown in the figure below.
Amazon also has some restrictions related to network connectivity. Specifically, the VM can only have a single network interface, and IPv6 addresses are not supported. The migration process will result in the EC2 instance receiving a private IP address, but it is possible to reconfigure the VM after the migration is complete, and assign a public IP.
Finally, you won’t be able to migrate a VM that has undergone a physical to virtual (P2V) conversion, nor will you be able to migrate a VM that uses a non-ASCII character set.
Operating system support
Nearly all modern versions of Windows are supported for use on a VM that is being migrated to AWS. Amazon supports the migration of VMs running Windows Server 2003 and above, with the caveat that Nano Server deployments are not supported. Recent client operating systems are also supported, including Windows 7, 8, 8.1, and 10.
Remote Desktop Services
Probably the single most common mistake made when migrating Hyper-V VMs to AWS is forgetting about the need for the Remote Desktop Services (RDS). Once a VM has been moved to the cloud, you will only be able to access the VM’s desktop using an RDP connection. As such, you must enable RDP, and you will need to make sure that you have granted the appropriate users to log in through an RDP connection. Similarly, and software firewalls will need to be configured to allow RDP traffic to flow across port 3389.
.NET Framework
The guest OS on the VMs that you will be migrating must have the appropriate version of the .NET Framework installed. The version that is required varies based on the operating system. For VMs running Windows Server 2008 R2 or later, or Windows 10 or later, you will need to install version 4.5 of the .NET Framework. If a VM is running an older version of Windows, then you will have to install version 3.5 instead.
A few more preparation tips
Aside from the basic requirements for migrating Hyper-V virtual machines to AWS, there are a number of little things that can conceivably cause problems with the migration process. As such, there are several things that you should check before moving forward with a migration.
I recommend, for instance, disconnecting any nonstandard or nonessential hardware from the VM. This includes CD-ROM drives and floppy drives (even if they are virtual), and SCSI pass-through disks.
Amazon also recommends that you set the Windows pagefile to be a fixed size. The exact method for doing so varies from one version to the next. In Windows Server 2012 R2, for example, you can change the pagefile configuration by right-clicking on the Start button, and choosing the System command from the resulting menu. This opens the System window. From there, click on the Advanced System Settings link. When the System Properties window opens, go to the Advanced tab, and click on the Settings button found in the Performance section. The option to change the pagefile usage is located on the resulting window’s Advanced tab in the Virtual Memory section, as shown in the figure below.
Hyper-V virtual machines to AWS: Keep it simple
Over the last few years, I have worked through a number of virtual machine migrations. Some of these were cloud migrations (including migrations to Azure), and others were migrations to or from VMware. One thing that has held consistent across all of the migrations that I have done, including migrating Hyper-V virtual machines to AWS, is that the more you can do to simplify the VM, the better your chances of a successful migration. Hence, I recommend disconnecting any unnecessary hardware (physical or virtual), uninstalling any unnecessary software, and temporarily disabling any security-related services.
Photo credit: Shutterstock
