Build cloud compatibility checks into the VM migration process to ensure the movement of VMs to the public cloud is as free from interruption as possible.
In ideal conditions, any public cloud instance should support any working VM. Although public cloud providers like Amazon Web Services (AWS) and Google Cloud Platform (GCP) seek to support a wide base of VM clients, compatibility isn't universal or guaranteed. Common compatibility issues can include OS versions, image formats and instance support. It's worthwhile to check cloud compatibility before you attempt any VM migration to the public cloud.
For example, Amazon Elastic Compute Cloud (EC2) instances support a wide range of OSes, but not all of them. Generally, EC2 supports Windows 7 and later desktop OS versions, as well as Windows Server 2003 with Service Pack 1 and later -- both 32- and 64-bit. Windows support shifts to 64-bit only with Windows 8.1 and Windows Server 2008 R2.
Partitions and file system affect cloud compatibility
Windows OSes should use the traditional master boot record (MBR) partitions using the NT file system. Later volume technologies, such as globally unique identifier partition table volumes might not be supported.
Similarly, EC2 supports a range of 64-bit Linux versions, including Ubuntu 12.04, CentOS 5.1, Red Hat Enterprise Linux (RHEL) 5.1, SUSE Linux Enterprise Server 11 SP1 and kernel 184.108.40.206-0.7, Debian 6.0.0, Oracle Linux 6.1, Fedora Server 19 -- and pretty much every later version of these OSes.
Other public cloud providers might impose similar limitations. For example, GCP instances support Windows Server 2008 R2; 2012 R2 or 2016, as well as RHEL, CentOS or Oracle Linux 6 or 7, Debian 8 or 9, and Ubuntu 14.04 or 16.04.
Are you ready to migrate your VMs to the cloud?
Before you migrate any VMs, check that your VMs are properly configured. The premigration process can be lengthy because different public cloud providers have a variety of requirements, but checking for the correct configuration early on makes for a more efficient process overall.
Assess suitability and cost to determine whether the migration process is right for you and what you might need to do to prepare further. Depending on the workload of each VM, the migration processes can be drastically different. Migration requires case-by-case examination, with particular attention paid to complexity, resource demands, performance and dependencies.
After preparing, learn how to perform a lift-and-shift migration that can take your VMs and all of their dependencies to the public cloud. This process normally involves a lot of manual steps, but with tools from AWS, GCP and Microsoft Azure, you can automate much of the process.
In terms of partitions and file systems under Linux, AWS requires MBR partitions formatted with ext2, ext3, ext4, btrfs, jfs or xfs file systems. GCP recommends an MBR partition with Grand Unified Bootloader installed.
The issue here is that public cloud providers might not support VMs hosting earlier or alternative OSes, which would make it impossible to migrate that VM to a public cloud instance. For example, there might be problems running a highly modified or customized Linux version in the public cloud. Testing cloud compatibility is essential.
Examine VM image formats
To migrate a VM, you usually create an image file, upload that image file to a storage resource, perform a series of conversions to run that image in the public cloud and deploy that converted image into a compute instance. However, the public cloud provider might impose limits on compatible VM image formats.
For example, AWS enables VM imports and exports in the Open Virtualization Format; the virtual machine disk image format, which is compatible with VMware ESX and vSphere; fixed and dynamic virtual hard disk image formats, which are compatible with Microsoft Hyper-V and Citrix Xen; and a raw format.
In practice, this compatibility covers the vast majority of enterprise VMs, but it's important to verify image format compatibility. It might be necessary to convert the image format, export a VM on the user's end with a compatible format or consider forgoing the VM migration entirely.
Evaluate the public cloud provider's target instance type. Although most types of public cloud instances should support VM migration, the available instance types might be limited for some OSes. For example, AWS limits Linux VMs to t2.micro, t2.small, t2.medium, m3.medium, m3.large, m3.xlarge and m3.2xlarge for general purpose instances. Similar cloud compatibility limitations exist for compute-optimized, memory-optimized, storage-optimized and accelerated AWS instances.
With Windows VMs, for example, GCP can't import images configured as multiple disks. Each disk requires separate steps for importing and attaching the images. Similarly, Windows VMs can't use PowerShell versions older than 3.0 because they can cause startup and shutdown problems with Google instances.
Other potential cloud compatibility problems with Linux VMs might occur when Secure Shell (SSH) isn't running on port 22. GCP uses port 22 for SSH, and clients such as Cloud Console and the gcloud command-line interface might not work if SSH uses a different port.
Ultimately, it's important to evaluate any potential VM for compatibility limitations against each public cloud provider and to take steps to address and remediate any cloud compatibility issues that arise. Tools might also be available to help the evaluation process.
For example, GCP provides a precheck tool designed to find issues that will interfere with the VM import or cause problems once the VM is imported. Even with careful evaluation and the correct processes, not all VMs will import or run properly in the public cloud.