read 20 minutes

How to migrate virtual machines between platforms and not lose anything:...

When needing to migrate a virtual machine from one site to another, the success rate can fluctuate. Mistakes during the migration process can negatively impact business operations. Therefore, understanding the correct procedure for VM migration is crucial to avoid pitfalls and ensure a smooth transition.

When Might VM Migration Be Necessary?

Several factors might necessitate the migration of virtual machines, including but not limited to:

  • Scheduled maintenance;
  • Upgrades in IT infrastructure;
  • Changing service providers.

These are just a few reasons one might consider migrating virtual machines.

How to Prepare for VM Migration

It’s essential to have a plan to avoid problems during virtual machine migration. If you don’t have enough experience, you can use the scheme below.


Having a detailed plan is crucial. Your plan should encompass:

  • The current status of your VM;
  • Characteristics of both the current and the intended platforms;
  • A clear migration strategy;
  • Time allocations for each step and the overall project;
  • A contingency plan for unforeseen issues.

The step is rather difficult but meticulous planning can help preempt potential issues.

Preparing Scripts

Before migrating, ensure that all necessary components are installed and configured as per the requirements. This preparation is needed, specifically, to enable the virtual machine from VMware to operate in OpenStack.

Uploading the System Image

It’s necessary to export the VM image from the current platform. The export options can vary, depending on the platform where the VM is deployed.

Intermediate Conversion

When migrating virtual machines from VMware or other platforms, it's important to export the image in VMDK format. However, this feature isn't available by default everywhere, so an intermediate conversion using third-party tools might be necessary.


A VMDK image should be uploaded to a new virtual platform.


The VM should be launched on a new platform. Don’t forget that the IP address will change. This means that before launching, you need to reconfigure the DNS records and switch the load.

If the VM continues to operate on the original platform during the migration, after launching it on the new platform, it's necessary to upload the delta of the data - the information that has accumulated during the migration.

Migration of VMware Virtual Machines to 3HCloud

Let's delve into the migration using the example of transferring VMware to 3HCloud.

Linux Migration Blueprint

  1. It’s necessary to check whether the OS kernel supports the VirtIO drivers.

    grep -i virtio/boot/config-$(uname -r)

    Verify if the VirtIO drivers are contained in the temporary file system, either initramfs or initrd.

    lsinitrd/boot/initramfs-$ (uname -r).img | grep virtio

    If the initramfs includes the virtio_blk driver along with dependencies such as virtio.ko, virtio_pci.ko, and virtio_ring.ko, then you're set to import custom images into OpenStack.

    However, if the initramfs lacks the VirtIO drivers, ensure you restore the temporary file system prior to importing any custom images into OpenStack.

  2. Restoring the temporary file system for CentOS or similar Red Hat based distributions.

    CentOS/RedHat 5

    mkinitrd -f --allow-missing --with=xen-vbd --preload=xen-vbd --with=xen-platform-pci — preload=xen-platform-pci --with=virtio_blk --preload=virtio_blk --with=virtio_pci — preload=virtio_pci --with=virtio_console --preload=virtio_console

    CentOS/RedHat 6/7

    mkinitrd -f --allow-missing --with=xen-blkfront --preload=xen-blkfront --with=virtio_blk --preload=virtio_blk --with=virtio_pci --preload=virtio_pci --with=virtio_console — preload=virtio_console /boot/initramfs-$(uname -r).img $(uname -r)

  3. QEMU Guest Agent and Cloud-init installation.

    yum install -y qemu-guest-agent cloud-init && systemctl enable --now qemu-guest-agent

  4. VMware tools deleting.


  5. Stop the VM and export it as a template in OVF packaging format.

    Once the export is finished, download the file in .vmdk format.

  6. Copy the VMDK disk to any node with OpenStack CLI or kolla-ansible.
  7. Converting a VMDK file to RAW.

    qemu-img convert -f vmdk -O raw centos-for-migrate.vmdk centos-for-migrate.raw

  8. You can proceed to manually import the VMDK disk using the openstack-client into the image storage. But if you're uncertain about the process, reach out to 3HCloud technical support - our team will handle the image upload for you.

    openstack image create --private --disk-format raw --container-format bare --property hw_qemu_guest_agent=yes --property hw_scsi_model=virtio-scsi --property os_admin_user=root --property os_distro=centos --property hw_scsi_model=virtio-scsi --file centos-for-migrate.raw centos-for-migrate(image name)

  9. Check the image in the Control Panel.

  10. Create a VM based on the downloaded image. Ensure the size of system volume is at least as large as that of the original VM.

Check that everything is working correctly.

Windows Migration Blueprint

  1. Delete VMware tools and install Cloudbase-init.
  2. Stop the VM and export it as a template in OVF packaging format.
  3. Copy the VMDK disk to any node with OpenStack CLI or kolla-ansible.
  4. Convert a VMDK file to RAW.

    qemu-img convert -f vmdk -O raw сentos-for-migrate.vmdk centos-for-migrate.raw

  5. Create an image based on the RAW file.

    openstack image create --disk-format raw --file

    centos-for-migrate.raw win8-image

  6. Create a bootable volume.

    openstack volume create --image win8-image –size


  7. Download the image with VirtIO drivers to the host where the openstack-client is installed.

  8. Download the VirtIO image from the ISO and create a disk.

    openstack image create --private --container-format bare --disk-format iso --file .iso virtio-img

    openstack volume create --image virtio-img –size 1


  9. Launch VM where the first CD-ROM device is the ISO file loaded with VirtIO drivers, and the second is the previously created disk from the uploaded Windows image. Execute the following command:

    nova boot --flavor Tiny-1-1-10 --nic net-id= --block-device


    device=/dev/ vdb,size=1,type=cdrom,bootindex=1 --block-device source=volume,id=,dest=volume,bus=virtio,device=/dev/ vda,size=35,bootindex=0


  10. Use the recovery mode.

    After starting the VM, switch to the console. Windows will try to boot but will be halted by a BSOD (Blue Screen of Death). After a few failed attempts, it will automatically enter recovery mode.

    In recovery mode, first select the appropriate keyboard layout. When presented with options, choose "Troubleshoot." From there, open the command prompt. Review the list of available drives. To access the VM's drives, you'll need to temporarily install the virtio driver.

    Then install viostor, viorng, and netkvm drivers, press “Continue”.

  11. Virtio installation.

    Switch to the ISO drive with VirtIO and select the installation of virtio-win-gt-x64.

    Ensure the disk and network card are operating on the VirtIO driver.

  12. Stop VM computing processes and disconnect the ISO disk from the instance.

    openstack server stop win8-centos-for-migrate

    nova volume-detach

  13. Make the main Windows disk clone.

    openstack volume create –volume


  14. Create a public image from a clone.

    openstack image create --container-format bare --disk-format

    raw –volume win8-volumeclone –public --property

    os_type='windows' --property os_version='8.1' –property

    hw_qemu_guest_agent='true' win8-bios

  15. Create VM.

Final Thoughts

Migrating VMs is a complex process, but sometimes it's essential for business. In this article, we've detailed a potential migration process. However, if you have any questions, you can always reach out to 3HCloud technical support.

20 February 202302/20/2023
read 1 minuteread 1 min
Refreshing tariffs for data storage
8 February 202302/08/2023
read 3 minutesread 3 min
Cloud servers with NVIDIA Tesla V100
2 February 202302/02/2023
read 2 minutesread 2 min
Co-location services in TIER-III level data centers