Some workloads present challenge for a live migration, like the workload being a physical machine, running on a non-VMWare hypervisor, or on a VMware hypervisor where the user lacks the necessary privileges to run the solution. For such workloads you can use the VMware Cloud Director Availability cold migration.

VMware Cloud Director Availability 4.7 introduces the option for a cold migration of the workload to transfer from non-VMware environments, such as KVM, Hyper-V, physical hosts, and others, to a Cloud Director site. The cold migration means that the source machine is powered off and rebooted into an ISO image. As a caveat, workloads to-be migrated which require 24/7 uptime and cannot be powered off cannot use cold migration.

The ISO image for cold migration has the following requirements.
  • Minumum 768 MiB of memory (RAM) or more.
  • Support for x86-64 architecture from the hypervisor and the CPUs for the physical workloads.

Workflow Overview

  1. As a provider, configure a VMware Cloud Director Availability 4.7 site on the destination – either by installing a fresh instance, or by upgrading an existing site. For more information, see Installing and configuring the appliances in the Cloud Director site or Upgrading in the Cloud Director site.
  2. As a provider, activate the cold migration.

    Perform the remaining steps as either a provider or as a tenant user.

  3. Create a cold migration template.
  4. Download the ISO image, generated as part of the cold migration template.
  5. Power-off the source workload, attach the ISO image to the virtual machine then boot from the ISO image.
  6. Once the virtual machine is booted from the ISO image, a new migration appears on the destination site.
  7. Depending on the template settings, the migration can either automatically begin or can require an explicit confirmation from the user on the destination site.
  8. Once the migration finishes, power-off the original workload manually.

As per steps 4-6, the cold migration requires that the original workload is powered off and booted into a special VMware Cloud Director Availability-generated ISO image that contains the necessary VMware Cloud Director Availability services for the migration. Specifically, the ISO image is based on Debian 12 and contains the VMware Cloud Director Availability Cold Migration Agent (h4dm-agent) that drives the migration process:

  • Discover the following hardware information.
    • CPU sockets and cores per socket
    • Physical memory
    • Number of NICs
  • Mount all disks into read-only mode.
    Note: The agent does not make any changes to the underlying disks.
  • Discover the guest operating system (OS) type, version, and the computer name for Windows and Linux guest OS. An exception are Linux guests that use Logical Volume Management (LVM) or disk encryption. In case the guest OS cannot be recognized, VMware Cloud Director Availability uses the source workload IP address as the computer name.
  • Establish a network connection to VMware Cloud Director Availability.
  • Copy each disk over the network to the destination VMware Cloud Director Availability site.
  • Create, then optionally power-on the destination virtual machine. Once all of the disks finish copying, a new virtual machine is created in the underlying vCenter Server instance. Then it is imported into the VMware Cloud Director instance and becomes available to the tenant.
Note:
  • The ISO image agent (h4dm-agent) is stateless - all of the information that it needs to perform the migration is stored in-memory. This means that the disk copying must happen in a single run; you cannot do a partial sync, power off or reboot, and then resume from the last copied block. Each (re-)boot creates a new migration instance and begins synchronization from scratch.
  • If the guest OS is encrypted, for example, by technologies such as dm-crypt in Linux and BitLocker in Windows, the disk content is copied as-is, in its encrypted form. Whether it can be decrypted on the destination side, depends on the used encryption technology:
    • If the decryption key is a user-provided password, the decryption is likely to succeed.
    • If the disk encryption key is stored in a Trusted Platform Module (TPM), the data remains unusable in the destination.