MigrateKit

Reference: https://github.com/vexxhost/migratekit

Migratekit is a CLI tool which can help you to migrate your virtual machines from VMware to OpenStack in a near-zero downtime. The goal of this project is to allow you to move as much data as possible online and only have a short downtime window to complete the migration.

How Migratekit works

Migratekit has two phases that it operates in to allow you to migrate your virtual machine with almost no downtime. These phases allow you to move data online as much as possible and have a final cutover phase which takes the virtual machine offline for a short period of time to complete the migration.

Migration Phase

This phase generally runs as many migration as the user need, this phase will run without the need of powering off the source VM, so there won’t be any downtime to the VM.

On the first migration cycle, Migratekit will do a full copy of the VM to OpenStack cloud. On subsequent migration cycles, Migratekit will only copy the changes that have been made since the last migration cycle.

Cutover Phase

Once the VM is ready to cut over to the OpenStack cloud, user can run the cut over phase. This phase will ensure all of the matching resource such as Neutron port exist on the cloud , do the final sync of the VM, power the VM off inside the VMware environment then build a new VM on the OpenStack cloud using the same volumes as the original VM.

Using MigrateKit

The easiest way to run MigrateKit tool is by using Docker Image which is shipped with all of the dependencies required to run MigrateKit except for VMware Disk Development Kit (VDDK) which needed to be downloaded from VMware website.

NOTE: At the moment MigrateKit supports VMware hypervisors that expose an API endpoint . If you see the following error message, it means that MigrateKit does not support your VMware hypervisor:

Error: ServerFaultCode: Current license or ESXi version prohibits execution of the requested operation.

Installing VDDK

In order to use MigrateKit, user need to download VDDK from VMware website. User will need to create a developer account in order to download the VDDK as well as accept EULA.

  1. Download VMware Virtual Disk Development Kit (VDDK) 8.0.2 for Linux
  2. Once you’ve downloaded the file, you will need to extract the contents of the tarball to a directory on your system.
  3. We recommend that you extract the contents of the tarball to /usr/lib64/vmware-vix-disklib/ on your system. If you decide to extract the contents to a different directory, you will need to update the Docker volume mount in the next section to reflect the directory you extracted the tarball to.

Running MigrateKit

NOTE: Ubuntu Noble Numbat (24.04) LTS was released with additional restrictions on unprivileged user namespaces, we suggest either disabling them or using Ubuntu Jammy Jellyfish (22.04) LTS until a solution is found.

Assuming Docker is already installed on the host system, user can use the following command to run the MigrateKit Docker container:

docker run -it --rm --privileged \\
  --network host \\
  -v /dev:/dev \\
  -v /usr/lib64/vmware-vix-disklib/:/usr/lib64/vmware-vix-disklib:ro \\
  --env-file <(env | grep OS_) \\
  ghcr.io/vexxhost/migratekit:main \\
  --help

The command above will download the MigrateKit docker image and run the help command. User can use the following command if the VM is ready for the first migration cycle.

docker run -it --rm --privileged \\
  --network host \\
  -v /dev:/dev \\
  -v /usr/lib64/vmware-vix-disklib/:/usr/lib64/vmware-vix-disklib:ro \\
  --env-file <(env | grep OS_) \\
  ghcr.io/vexxhost/migratekit:main \\
  migrate \\
  --vmware-endpoint vmware.local \\
  --vmware-username username \\
  --vmware-password password \\
  --vmware-path /ha-datacenter/vm/migration-test

In the example above, you would run the migration cycle against a virtual machine located at /ha-datacenter/vm/migration-test on the VMware endpoint vmware.local (which can be both an ESXi host or a vCenter server). The endpoint can also be an IP address if you do not have a DNS entry for the endpoint.

You will also need to make sure you have all of your OpenStack environment variables set in your environment before running the command so that Migratekit can connect to the OpenStack cloud.

Once you’ve ran this command a few times and you’re happy that you’re ready to cutover, you can run the following command to cutover to the OpenStack cloud:

docker run -it --rm --privileged \\
  --network host \\
  -v /dev:/dev \\
  -v /usr/lib64/vmware-vix-disklib/:/usr/lib64/vmware-vix-disklib:ro \\
  --env-file <(env | grep OS_) \\
  ghcr.io/vexxhost/migratekit:main \\
  cutover \\
  --vmware-endpoint vmware.local \\
  --vmware-username username \\
  --vmware-password password \\
  --vmware-path /ha-datacenter/vm/migration-test \\
  --flavor b542cedb-d3b4-4446-a43f-5416711440ee \\
  --network-mapping mac=00:0c:29:7d:2d:68,network-id=2a81f1b0-c1b8-48dd-bd8e-4d976608c06d,subnet-id=21a7110b-2ab2-4cc1-8372-8b552f7a4438,ip=192.168.2.20

You should run it with the same arguments, however, this time you will need to specify the flavor that you want to use for the virtual machine on the OpenStack cloud as well as the network mapping that you want to use for the virtual machine.

The network mapping allows Migratekit to know what network to attach the virtual machine to on the OpenStack cloud, as well as the IP address that you want to assign to the virtual machine since it cannot map this information from VMware.

The format of the network mapping is as follows:

  • mac: The MAC address of the virtual interface on the virtual machine that you want to map to the OpenStack network (required).
  • network-id: The UUID of the network that you want to attach the virtual machine to on the OpenStack cloud (required).
  • subnet-id: The UUID of the subnet that you want to attach the virtual machine to on the OpenStack cloud (required).
  • ip: The IP address that you want to assign to the virtual machine on the OpenStack cloud (optional, Neutron will assign an IP address if this is not specified).

You should ideally match the network mapping to the network that the virtual machine is attached to on the VMware side to ensure that the virtual machine can communicate with the network once it has been migrated to the OpenStack cloud.

You can use more than one network mapping in case your VMWare machine has more than one.

There are a few optional flags to define the following:

  • --security-groups: A comma separated list of security group UUIDs to apply to the virtual machines port, if not supplied only the ‘default’ security group will be applied
  • --volume-type: OpenStack volume type to be used for the block devices
  • --availability-zone: OpenStack availability zone to be associated with both block device and virtual machine
  • --run-v2v: A flag to disable the running of virt-v2v-in-place against the destination machine. Should be disabled with caution as it may result in an unbootable instance. To disable flag must be passed with an =false e.g. -run-v2v=false-disk-bus-type: Flag to define volume disk bus type, currently only supports scsi and virtio.
  • --compression-method: Compression method: skipz, zlib and none.
  • --os-type: Sets the “os_type” volume (image) metadata variable. If set to “auto”, it tries to recognize the correct operating system via the VMware GuestId. Valid values for the most OpenStack installations are “linux” and “windows”
  • --enable-qemu-guest-agent: Sets the “hw_qemu_guest_agent” volume (image) metadata parameter to “yes”.

Leave a Reply

Your email address will not be published. Required fields are marked *