Migrating Cloud Workloads from VMware to OpenStack/KVM: Two Proven Strategies

09.03.25 10:08 AM - Comment(s) - By Amina Mseddi

Introduction: The Shift Away from VMware

With Broadcom's recent acquisition of VMware, many organizations are reconsidering their cloud infrastructure due to rising costs and licensing changes. As VMware’s platform becomes increasingly expensive, enterprises are looking for open-source alternatives like OpenStack or KVM-based infrastructure. Migrating workloads from VMware to these platforms can be challenging, but with the right strategy, the transition can be seamless and efficient.

In this blog post, we’ll explore two practical migration strategies:

  1. Image-based migration using tools like virt-v2v or qemu-img
  2. Network-based disk copying using dd and netcat(nc)

Each approach has its pros and cons, which we will discuss to help you choose the best method for your migration needs.

Strategy 1: Image-Based Migration

This approach involves exporting the VMware virtual machine disk (VMDK), converting it to a compatible format (QCOW2 or RAW), and then uploading it to OpenStack. This is a structured and well-documented method that leverages existing tools for format conversion and image management.

Prerequisites

  • Access to the VMware environment with administrative privileges.
  • A workstation with virt-v2v orqemu-img installed.
  • Access to the OpenStack glance service to upload the converted image.

Step 1: Export the VMware Disk (VMDK)

Using vmkfstools or the VMware web interface, export the VM’s disk:

  $ vmkfstools -i /vmfs/volumes/datastore1/source-vm/source.vmdk /tmp/source-flat.vmdk -d thin

Alternatively, you can download the VMDK file from VMware vSphere.


Step 2: Convert VMDK to QCOW2

Using qemu-img, convert the VMDK to QCOW2 format:

  $ qemu-img convert -f vmdk -O qcow2 /tmp/source-flat.vmdk /tmp/source.qcow2

For RAW format (optional):

  $ qemu-img convert -f vmdk -O raw /tmp/source-flat.vmdk /tmp/source.raw


Step 3: Upload to OpenStack Glance

Once the image is converted, upload it to OpenStack:

  $ openstack image create "source-vm" --disk-format qcow2 --container-format bare --file /tmp/source.qcow2 --public

Step 4: Deploy the VM in OpenStack

Now that the image is in OpenStack’s glance, you can launch an instance from it:

  $ openstack server create --flavor m1.large --image source-vm --network private-net --key-name my-key migrated-vm 

Pros & Cons of Strategy 1

    ✅Pros❌ Cons
     Reliable and structured process.Requires additional storage for intermediate conversions.
     Well supported toolsTime-consuming due to download/upload steps.
     Minimal downtime since the VM can remain active during export Not ideal for very large VM images due to network/storage constraints.

    Strategy 2: Network-Based Disk Copy

    Instead of downloading and converting disk images, this method copies data directly from the source VM (running on VMware) to a destination VM in OpenStack using dd and netcat.

    Prerequisites

    • A running source VM in VMware.
    • A newly created destination VM in OpenStack with empty attached disks.
    • Network connectivity between both VMs.
    • Root or sudo access on both VMs.

    Step1: Prepare the source and destination VMs

    • Identify the source disk inside the VMware guest:
      $ lsblk
    • Create an empty volume in OpenStack and attach it to the destination VM.
      $ openstack volume create --size 50 new_disk 
      $ openstack server add volume destination-vm new_disk

    Step 2: Start a listener on the destination VM

    • The destination VM will receive the disk image via netcat:
      $ nc -l -p 9000 | gzip -d | dd of="/dev/vdb" bs="4M"

    Step 3: Send the disk data from the source VM

    On the source VM, use dd to read the disk and pipe it through gzip for compression before sending it over netcat:
       $ dd if=/dev/sda bs="4M" | gzip | nc destination-ip 9000

    Step 4: Monitor and finalize

      • Once the transfer completes, detach the old disk in OpenStack and reboot the migrated VM.
      • If needed, install the necessary drivers in the new VM.

    Pros & Cons of Strategy 2

    ✅Pros❌ Cons
     Faster for large VMs as there is no intermediate storageRequires a stable and fast network connection.
    Can be done while the VM is running (with minor performance impact)Possible data corruption if the connection is interrupted.

    More manual intervention is needed compared to virt-v2v.

    Amina Mseddi

    Categories -
    Migration
    Share -
    Tags -