Virtual Machine Migration to Cloud: Hypervisor and Image Conversion

Virtual machine (VM) migration to cloud infrastructure requires converting on-premises disk images and hypervisor-specific formats into formats compatible with target cloud platforms. This page covers the technical mechanics of hypervisor translation, image conversion pipelines, format compatibility matrices, and the decision criteria that determine which migration path is appropriate for a given workload. Understanding these processes is foundational to any successful lift-and-shift migration or broader cloud migration strategy.

Definition and scope

A virtual machine is a software-defined compute environment that runs atop a hypervisor — a layer that abstracts physical hardware into virtualized resources. When migrating VMs to cloud platforms, the hypervisor formats used on-premises (such as VMware's VMDK, Microsoft Hyper-V's VHD/VHDX, or KVM's QCOW2) rarely align natively with the disk image formats that cloud providers require for import. The process of resolving that mismatch is called hypervisor and image conversion.

The scope of this discipline includes:

• Image format translation: converting raw disk images between container formats
• Boot configuration adjustment: modifying bootloaders, partition tables, and device drivers to function without the original hypervisor
• Driver replacement: swapping hypervisor-specific paravirtual drivers (e.g., VMware Tools, Hyper-V Integration Services) for cloud-native drivers (e.g., virtio, AWS PV drivers, Azure Linux Agent)
• Metadata packaging: embedding configuration metadata required by the cloud platform's import APIs

The National Institute of Standards and Technology (NIST) defines cloud migration broadly in NIST SP 800-146, which classifies IaaS workload portability as dependent on the abstraction layer — making hypervisor compatibility a first-order concern in any migration assessment.

How it works

Image conversion follows a structured pipeline regardless of source or target platform. The steps below represent the general industry-standard sequence:

1. Pre-conversion audit: Inventory the source VM's OS version, installed drivers, disk layout, and firmware type (BIOS vs. UEFI). VMs using UEFI may require additional bootloader translation steps absent from BIOS-based workflows.
2. Driver preparation: Uninstall hypervisor-specific drivers and install generic or target-platform drivers before conversion begins. AWS, for example, publishes explicit requirements through its VM Import/Export documentation specifying that Windows images must have RDP enabled and EC2Config or EC2Launch installed prior to import.
3. Format conversion: Use a conversion utility to translate the disk image. Open Virtualization Format (OVF), standardized by the Distributed Management Task Force (DMTF OVF Standard), serves as an intermediate format that most enterprise hypervisors and cloud import tools can consume.
4. Image upload: Transfer the converted image to the target cloud's object storage (e.g., Amazon S3, Azure Blob Storage, Google Cloud Storage) as a staging area for the import process.
5. Import and registration: Trigger the cloud platform's import API to create a cloud-native machine image — an Amazon Machine Image (AMI) on AWS, a Managed Image on Azure, or a Custom Image on Google Cloud.
6. Validation and boot test: Launch the resulting instance in a non-production environment, verify boot success, confirm network interface availability, and validate agent functionality before decommissioning the source VM.

The critical technical distinction between Type 1 hypervisors (bare-metal: VMware ESXi, Microsoft Hyper-V, Xen) and Type 2 hypervisors (hosted: VMware Workstation, VirtualBox) matters during this phase. Type 1 VMs typically contain production-grade drivers and storage configurations; Type 2 VMs often carry additional abstraction layers that must be stripped before cloud import succeeds. Cloud platforms universally target Type 1 source environments in their supported import matrices.

Common scenarios

VMware to AWS: The most common enterprise scenario. VMware VMDK images are exported as OVF packages and imported via AWS VM Import/Export. AWS publishes a supported OS matrix — as of its published documentation, Windows Server 2008 R2 through 2022 and major Linux distributions (RHEL, CentOS, Ubuntu, Debian, SUSE) are supported. Organizations conducting cloud readiness assessments frequently encounter Windows Server 2003 and 2008 (pre-R2) images that fall outside the supported matrix and require OS upgrade before migration.

Hyper-V to Azure: Microsoft's Azure Migrate service natively understands VHD and VHDX formats, reducing manual conversion steps. Azure Migrate uses an agentless replication model based on VMware vSphere APIs or Hyper-V Replication, documented by Microsoft under its Azure Migrate architecture guidance. This path is commonly selected in enterprise environments already operating on Microsoft licensing agreements.

KVM/QCOW2 to Google Cloud: Google Cloud requires raw disk images (IMG format) for import. QCOW2 images must first be converted to raw format using qemu-img, an open-source utility maintained under the QEMU project. The resulting raw image is compressed and uploaded to Google Cloud Storage before import via the gcloud compute images import command.

Physical-to-virtual-to-cloud (P2V2C): Bare-metal servers without an existing hypervisor layer require a two-stage process — first creating a VM using P2V tooling, then proceeding through standard image conversion. This scenario is discussed further in the context of legacy system cloud migration.

Decision boundaries

Selecting the appropriate conversion path depends on four measurable variables:

• Source hypervisor format: determines which conversion utilities and intermediate formats apply
• Target cloud platform: determines accepted image formats, supported OS versions, and required agents
• OS generation: unsupported OS versions require upgrade prior to migration or replatforming rather than lift-and-shift; see replatforming vs. refactoring in cloud
• Downtime tolerance: live migration (using replication-based tools) versus offline conversion produces different RTO profiles; organizations with sub-4-hour RTO requirements typically require agent-based continuous replication rather than one-shot image export

Security posture also intersects with image conversion decisions. Imported images carry the security configuration of the source OS. Hardening standards such as the Center for Internet Security (CIS) Benchmarks — published at CIS Benchmarks — should be applied either before export or immediately after first boot in the cloud. Cloud migration security considerations including encryption of images at rest during transit through cloud object storage represent a non-optional compliance step for regulated workloads.

Workload complexity is the decisive factor between automated conversion (suitable for standard OS builds with unmodified partition layouts) and manual conversion (required for VMs with raw device mappings, custom bootloaders, or third-party disk encryption active at the hypervisor layer). Organizations processing 50 or more VMs typically implement cloud migration automation tools to manage conversion pipelines at scale rather than executing individual conversions manually.

References

• NIST SP 800-146: Cloud Computing Synopsis and Recommendations — National Institute of Standards and Technology
• DMTF Open Virtualization Format (OVF) Standard — Distributed Management Task Force
• AWS VM Import/Export User Guide — Amazon Web Services
• CIS Benchmarks — Center for Internet Security
• QEMU Documentation — QEMU Project (open-source hypervisor and image conversion tooling)
• NIST SP 500-292: NIST Cloud Computing Reference Architecture — National Institute of Standards and Technology