What cloud compatibility issues can arise with VM migration?

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 2.6.32.12-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.

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.

Although most types of public cloud instances should support VM migration, the available instance types might be limited for some OSes.

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.