3 Tools for Getting VMs From Your Datacenter to the AWS Cloud

Here's a simple scenario: you have some Virtual Machines (VMs) in your on-premises environment, likely in VMware vSphere or Microsoft Hyper-V. You want to either fully migrate some or all of those VMs to the AWS Cloud or you want to copy a gold image to the AWS Cloud so you can launch compute instances from that image. Simple enough.

Now, how do you do it?

Can you just export an OVA of the VM, copy it up, and then boot it? Can you somehow import the VMDK files that hold the VM's virtual drive contents? Regardless the eventual method, how do you do it at scale for dozens or hundreds of VMs? And lastly, how do you orchestrate the process so that VMs belonging to an application stack are brought over together, as a unit?

This post will answer these questions and more by providing an introduction to the services available on the AWS Cloud to discover, plan, migrate, and track VMs from on-prem to AWS.

This post assumes good working knowledge of technologies such as VMware vCenter and only basic knowledge of AWS.

Let's just clarify some things first⌗

Remembering that this post is tailored for those that are new to AWS, there's some basics to know about migrating a VM to AWS. Amazon Elastic Compute Cloud (EC2) boots compute instances using Amazon Machine Images (AMIs). EC2 does not support booting OVAs or raw VMDK files or anything of the like. VMs therefore have a to through an import process to convert them from their source format to an AMI. The bulk of the rest of this article will explain the services in the AWS Cloud which can perform this import process and convert VMs to AMIs.

The AWS migration services have good support for VMware vSphere and Microsoft Hyper-V and may support other hypervisors as well depending on the service. This post will focus on vSphere.

Migration housekeeping⌗

Before you scoot a VM up to the cloud there are some housekeeping things you need to consider.

Unlike on-prem where you have console access to the VM, EC2 doesn't provide that; your only access to the VM will be via the network. Therefore:

• Enable Remote Desktop and/or SSH
• Verify that the host-based firewall (Windows Firewall, iptables, and the like) permit RDP and/or SSH
  • A consideration here is to actually disable the host-based firewall and rely on EC2 Security Groups (SGs) instead. SGs can be modified via the AWS Console or APIs allowing you to specify the precise source address(es) to allow for RDP/SSH, even while the instance is running; you can't change host-based firewall rules once they're baked into the AMI.
• Verify that the DHCP client service is installed and not administratively disabled; EC2 will assign an IP address to the VM via DHCP (even if an administrator manually specifies the IP address for a VM, it's handed out via DHCP).

For Linux VMs, the recommendation is to have a non-root user account created that you can log into. If you intend to use public key authentication, verify that you have placed the correct SSH public key(s) into ~/.ssh/authorized_keys. Unlike when you boot a Linux AMI from the AWS Marketplace, EC2 will not install an SSH key for you nor create the ec2-user account.

For Windows VMs, the local Administrator account password will persist through the migration process and if the VM is joined to a Microsoft Active Directory Domain and the domain is reachable from your AWS environment, you should be able to log in using domain credentials as well.

Lastly, uninstall the VMware Server Tools (if installed) and disconnect any virtual CD-ROM drives as neither of these are supported nor needed on AWS.

VM Import/Export⌗

The VM Import/Export (VMIE) service simply runs the VM migration process to build an AMI from an on-prem VM.

VMIE can be called using the AWS Command Line Interface (CLI), AWS Tools for PowerShell, or the various Software Development Kits (SDKs) that AWS provides. While VMIE can be automated using these methods, the service doesn't natively support automation; it's designed to either be run manually or fit into a larger orchestration/automation system that can call VMIE as part of its playbook.

From a VM perspective, VMIE supports Windows Server OSes from 2003 SP1 and newer, Windows Desktop OSes starting with 7 and newer, and various flavors of 64-bit Linux (sorry, 32-bit Linoooks). There is mixed support for GUID Partition Table (GPT) volumes. A full, detailed list of supported OS and boot volume types can be found in the VMIE User Guide.

• Windows VMs support GPT volumes but only when exported in VHDX format. VMIE will automatically convert GPT boot volumes with a UEFI boot partition to an MBR volume with a BIOS boot partition.
• Linux VMs support only MBR partitioned volumes.

Sadly, I do have to mention licensing because, you know, what fun would any software discussion be without the L-word?

• Linux VMs: Bring Your Own License (BYOL) only. This means if you're migrating RedHat Enterprise Linux, SUSE Linux Enterprise Server, or other commercial Linux distributions, you must own the appropriate licenses to bring those VMs to the AWS Cloud. Non-commercial distributions generally don't restrict where you can run the software, but it's up to you to verify your particular license terms.
• Windows Server VMs: BYOL or license-included (LI). BYOL allows you to use a license you've already purchased from Microsoft to run the VM in the cloud (subject to your particular license terms with Microsoft). LI allows you to purchase a license from AWS and pay for it as part of your hourly EC2 rate.
• Windows Desktop VMs: BYOL only (as always, subject to the terms of your licensing agreement with Microsoft).

To execute a migration with VMIE, follow these general steps:

1. Shutdown the VM
2. Export the VM as an OVA
3. Upload the OVA to S3
4. Call VMIE to run an import on the OVA and convert it to an AMI

Here is an example of running VMIE by using the AWS CLI tool to call the ImportImage API:

% cat containers.json
[
        {
                "Description": "tstlinux1 OVA",
                "Format": "ova",
                "UserBucket": {
                        "S3Bucket": "mybucket",
                        "S3Key": "tstlinux1.ova"
                }
        }
]


% aws ec2 import-image --description "tstlinux1 import" --disk-containers "file://containers.json"
{
    "Status": "active",
    "Description": "tstlinux1 import",
    "SnapshotDetails": [
        {
            "UserBucket": {
                "S3Bucket": "mybucket",
                "S3Key": "tstlinux1.ova"
            },
            "DiskImageSize": 0.0,
            "Format": "OVA"
        }
    ],
    "Progress": "2",
    "StatusMessage": "pending",
    "ImportTaskId": "import-ami-03c11f20d70348d96"
}

To check the status of the job, call the DescribeImportImageTasks API:

% aws ec2 describe-import-image-tasks --import-task-ids "import-ami-03c11f20d70348d96"
{
    "ImportImageTasks": [
        {
            "Status": "active",
            "Description": "tstlinux1 import",
            "SnapshotDetails": [],
            "Progress": "6",
            "StatusMessage": "validated",
            "ImportTaskId": "import-ami-03c11f20d70348d96"
        }
    ]
}

The job will move through various statuses and if successful, will reach a status of completed at which point an AMI will exist in your account.

AWS Server Migration Service⌗

The AWS Server Migration Service (SMS) is a managed service for automating the discovery, scheduling, and migration of VMs from VMware, Hyper-V, and Azure to AWS.

SMS performs automated discovery of VMs by way of the Server Migration Connector which is a VM appliance provided by AWS that you install in your virtualization environment and grant it permission to call the on-prem Virtual Machine Manager (VMM) API. The Connector acts as a bridge between the on-prem VMM and the AWS Cloud. It shares the VM inventory and processes instructions from SMS to begin the migration of one or more VMs into AWS. In the case of VMware, the Connector will call vCenter's API to create a snapshot of the VM, export that snapshot from the host, and import the VM into AWS as an AMI. This process can be scheduled and can even be done repeatedly on the same source VM(s) to keep the cloud AMI up-to-date with whatever changes are happening on the source VM.

Supported source operating systems include Window Server OSes from 2003 SP1 and newer, Windows Desktop OSes starting with 7 and newer, and various flavors of 64-bit Linux.

And like VMIE, I do have to cover the L-word: licensing on imported VMs is the same as with VMIE:

• Linux VMs: BYOL only
• Windows Server VMs: License-included or BYOL
• Windows Desktop VMs: BYOL only

SMS tracks the status of each job as well as the history of the job if it is a recurring scheduled job.

When the job is complete, a new AMI will be available in your account with which to launch instances.

AWS Migration Hub⌗

AWS Migration Hub is a central place to discover, plan, and monitor migration activity. Migration Hub integrates with migration and discovery services such as AWS Database Migration Service, AWS Server Migration Service, CloudEndure Migration, and others, and aggregates information from those services into a central place.

There are two ways to get started with Migration Hub:

1. Perform a detailed discovery of applications and VMs that you would like to migrate. The discovered resources can be grouped and organized prior to migration in order to facilitate an orderly migration. The information that can be gathered as part of the discovery includes average and peak CPU, RAM, and disk I/O as well as time-series data on processes running on the VM and network communications.
2. The discovery phase can be skipped and you can jump right to doing migrations.

There are three options for getting discovery data into Migration Hub:

1. Import a CSV file (using the supplied template). This option requires zero footprint in your on-prem environment, but is the most tedious and labor intensive. It's also likely to provide the overall lowest quality of data due to the need for manual data collection and recording.
2. Discovery Connector. This is a software appliance supplied by AWS that you install in your virtualized environment and connect it to your VMM. It automatically queries the inventory of VMs, retrieves their stats on an ongoing basis, and feeds that into Migration Hub. This option provides a nice amount of automation but is limited to only those metrics that the VMM/hypervisor knows about (CPU, RAM, disk, etc) and cannot peek inside the VM to see processes or network connections.
3. Discovery Agent. This is a piece of software provided by AWS that you install and run on the VM. It gathers information about the VM from inside the VM and provides the most detailed amount of data, including time-series information on processes and network traffic.

The actual migration work is done outside of Migration Hub, using one of the integrated services mentioned above. Those services report their status back to Migration Hub which is then displayed in the Migration Hub console, providing a single place to track the progress of migration activity.

A supporting feature of Migration Hub is its ability to provide EC2 instance size recommendations based on the data it discovered about your VMs. You can instruct Migration Hub to use the average, peak, or percentile CPU/RAM data to inform its decisions and even choose between shared/dedicated instances and on-demand/reserved EC2 pricing models.

The feature will output a CSV file containing all the servers in the Migration Hub inventory along with the detailed data used to create the recommendation and the EC2 instance recommendation itself.

Summary⌗

AWS provides multiple tools for planning, discovering, migrating, and tracking the movement of VMs into the AWS Cloud. By using these tools, you can automate the migration of VMs into AWS in order to conduct dry-run migrations or perform migration of production workloads. VMs can also be grouped into applications in order to facilitate an orderly migration. These same tools can be used to bring "gold images" of servers to AWS to enable running a common image in a hybrid environment.

These tools make it easy to get your servers running on AWS.

You should also now understand that you cannot just nab an OVA or VMDK and whip it up to the cloud. Your VMs have to go through an import process to convert them to an AMI before they're usable on AWS.

References⌗

• VM Import/Export User Guide and FAQ
• AWS Application Migration Service User Guide and FAQ
• AWS Migration Hub User Guide and FAQ
• AWS Migration Whitepaper

Disclaimer: The opinions and information expressed in this blog article are my own and not necessarily those of Amazon Web Services or Amazon, Inc.