Version: latest

Create Source Providers

Follow this guide to create source providers using the VM Migration Assistant. Source providers host the Virtual Machines (VMs) that need to be migrated.

Limitations

You can only migrate VMs hosted in VMware vSphere 7.0 and 8.0.
Only VMs whose operating systems are included under virt-v2v supported guest systems can be migrated.

Prerequisites

The Virtual Machine Migration Assistant pack must be added to your cluster profile. Refer to Create a VM Migration Assistant Cluster Profile for guidance.
- The VM Migration Assistant service console must be accessible from a web browser.

A healthy VMO cluster. Refer to the Create a VMO Profile for further guidance.

The VMO cluster must have network connectivity to vCenter and ESXi hosts, and the VMs you want to migrate.

warning

If you need to provision Block storage volumes during the VM migration process, add the following custom configuration to your VMO cluster OS pack. Applying this configuration may cause a cluster repave. For more information, refer to Repave Behaviors and Configurations

Additionally, we recommend provisioning volumes with the ReadWriteMany access mode to ensure that VMs can be live migrated.

kubeadmconfig:
   preKubeadmCommands:
      # Start containerd with new configuration
      - systemctl daemon-reload
      - systemctl restart containerd
   files:
      - targetPath: /etc/containerd/config.toml
      targetOwner: "root:root"
      targetPermissions: "0644"
      content: |
         ## template: jinja

         # Use config version 2 to enable new configuration fields.
         version = 2

         imports = ["/etc/containerd/conf.d/*.toml"]

         [plugins]
            [plugins."io.containerd.grpc.v1.cri"]
            sandbox_image = "registry.k8s.io/pause:3.9"
            device_ownership_from_security_context = true
            [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
            runtime_type = "io.containerd.runc.v2"
            [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
            SystemdCgroup = true

A vCenter user account with the following necessary privileges to perform migrations.

Privileges	Description
Virtual machine.Interaction.Power Off	Allows shutting down a powered-on virtual machine, powering down its guest operating system.
Virtual machine.Interaction.Power On	Enables starting a powered-off virtual machine or resuming a suspended one.
Virtual Machine Interaction Privileges (all)	Allow creating, cloning, modifying, customizing, and managing templates, virtual machines, their files, and customization specifications, as well as performing disk and deployment-related operations.
Virtual machine.Snapshot management.Create snapshot	Allows capturing the current state of a virtual machine as a snapshot.
Virtual machine.Snapshot management.Remove Snapshot	Permits deletion of a snapshot from the snapshot history.

Migrations can be optionally accelerated by providing credentials for the ESXi hosts where the VMs reside.

One or more VMs hosted in VMware vSphere. Only VMs whose operating systems are included under virt-v2v supported guest systems can be migrated.
- If you are migrating more than one VM in the same plan, they must all share the same network.
- For cold migrations, ensure that VMs operating Windows are shut down at the guest OS level.
- For warm migrations, Changed Block Tracking must be enabled on your VMs.
We recommend providing a VMware Virtual Disk Development Kit (VDDK) image for the migration. This will significantly speed up the migration. The migration engine uses VDDK on the destination VMO cluster to read virtual disks from the source environment, transfer the data, and write it to the target storage.
- You must build and host the VDDK image in your own image registry, which must be accessible to the destination VMO cluster for migrations.
  Example steps to build and upload VDDK image
  Download the VDDK image from the Broadcom Developer Portal.
  
  Decompress the downloaded image.
  
  tar -xzf VMware-vix-disklib-<version>.x86_64.tar.gz
  
  Create a Dockerfile to build the VDDK image.
  
  cat > Dockerfile <<EOF FROM <myregistry/myrepository:tag> USER 1001 COPY vmware-vix-disklib-distrib /vmware-vix-disklib-distrib RUN mkdir -p /opt ENTRYPOINT ["cp", "-r", "/vmware-vix-disklib-distrib", "/opt"] EOF
  
  Replace the <myregistry/myrepository:tag> with your chosen base image registry/repository (for example: alpine:latest).
  
  Build the image.
  
  docker buildx build --platform linux/amd64 --tag <docker-registry>/vddk:<tag> .
  
  Push the built image to your image registry.
  
  docker push <docker-registry>/vddk:<tag>
- If you are using a private image registry, you must create a Secret to be used for the migration. The Secret must be created in the namespace where the VMs will be migrated to, and the metadata.name value must be vddk-image-pull-secret.
  Example Secret Creation
  A Secret can be created by issuing the following command.
  kubectl create secret docker-registry vddk-image-pull-secret \ --docker-server=myRegistryServer \ --docker-username=myUsername \ --docker-password=myPassword \ --docker-email=myEmail \ --kubeconfig=/path/to/myKubeconfig \ --namespace=myVmMigrationNamespace \ --output yaml
  This creates the Secret named vddk-image-pull-secret in your destination cluster under the namespace provided. Ensure that this namespace matches the one you have chosen for the VM migration.
  apiVersion: v1 kind: Secret metadata: name: vddk-image-pull-secret data: .dockerconfigjson: #base64 encoded dockerconfigjson type: kubernetes.io/dockerconfigjson
  The data.dockerconfigjson value contains your registry credentials, which have been base64 encoded by the command.
  Alternatively, you can manually encode a config.json by issuing the following command.
  cat path/to/config.json | base64 --wrap=0
  Example output
  eyJodHRwczovL2luZGV4L ... J0QUl6RTIifX0=
  You can then use this output to create your own Secret manually. Ensure that the metadata.name is set to vddk-image-pull-secret.
  Refer to the Pull an Image from a Private Registry and kubectl create secret docker-registry documentation for additional guidance.