Migrate a VM using migctl

The best way to learn the process of migrating assets is by completing the following tutorial, which shows you how to migrate a VM using the CLI. After completing the tutorial, you can explore other topics in the user guide, such as using alternate data sources, editing the migration file, or using the Google Cloud console instead of the command line.

In order to streamline the process, the tutorial does not explore every option along the way. Instead, the steps are designed to get your VM migrated and available in the fastest way possible.

Before you begin

Access to the following resources and tools is required:

Install Migrate on the cluster

Install Migrate on the Google Distributed Cloud Virtual for Bare Metal cluster you want to migrate the vSphere VM workloads into.

  1. Download migctl on your admin workstation:

    curl -O https://modernize-release.storage.googleapis.com/$(curl -s https://modernize-release.storage.googleapis.com/latest)/linux/amd64/migctl
    sudo cp migctl /usr/local/bin/
    sudo chmod +x /usr/local/bin/migctl
    
  2. Export kubeconfig:

    export KUBECONFIG=PATH_TO_KUBECONFIG
    
  3. Install Migrate on the cluster:

    migctl setup install --anthos-bm --json-key=JSON_KEY
    --gcp-project <GCP_PROJECT_NAME --gcp-region GCP_REGION
    

    For example:

    migctl setup install --anthos-bm --json-key=/root/bm-gcr.json  --gcp-project
    a4vm-test --gcp-region us-central1
    
  4. Ensure that the default storage class is set for the Google Distributed Cloud Virtual for Bare Metal cluster.

    Use kubectl get storageclass to see if there is any default storage class set. If not, then set local-shared as the default storage class using the following:

    kubectl patch storageclass local-shared -p '{"metadata": {"annotations":
    {"storageclass.kubernetes.io/is-default-class":"true"}}}'
    

Create a migration source

A source is a system where your existing VMs live, and includes the information required to connect to it. In the case of Migrate A4VM, a source is a VMware vSphere cluster. Once a migration source is ready, it can be used to migrate multiple VMs.

  1. Create a migration source (this should take less than a minute):

    migctl source create local-vmware SOURCE_NAME
    --vc VCENTER_HOSTNAME
    --username VCENTER_USER --access-type export
    
  2. Enter the vCenter password when prompted.

  3. It can take a while to create the migration source, and the source needs to be in the READY state before it can be used. You can check the status of all of the sources using migctl:

    migctl source list
    

Migrate a VM and generate artifacts

To create a migration, specify a name, a source, a VM ID, and an intent.

  1. Create a migration:

    migctl migration create MIGRATION_NAME
    --source SOURCE_NAME
    --vm-id VM_NAME
    --intent IMAGE_OR_DATA --type vm
    
  2. It can take a few minutes to create a migration, so you can use migctl to monitor the status of the migration until the Status of the GenerateMigrationPlan operation changes from Running to Completed.

    migctl migration status MIGRATION_NAME
    
  3. At this point you could optionally edit the migration plan, but to make these instructions simpler the first time through, we've left off that step.

  4. Generate the artifacts (also called executing a migration):

    migctl migration generate-artifacts MIGRATION_NAME
    
  5. This can take some time depending on the storage size of the shifted VM. Use migctl to monitor the status of the migration until the Status of the GenerateArtifactsoperation changes from Running to Completed.

    migctl migration status MIGRATION_NAME
    
  6. You can now download all non-image/disk artifacts to the current directory by running the following command:

    migctl migration get-artifacts MIGRATION_NAME
    

Deploy migrated VMs

This section describes two use cases for deploying migrated workloads.

  • Stateless – Run a fleet of ephemeral VM replicas.
  • Stateful – Run a VM with disks in persistent storage.

For additional information about using shifted VMs after deploying them to the cluster, see the Google Distributed Cloud Virtual for Bare Metal cluster documentation.

Run a fleet of stateless VM replicas

In this use case, you run multiple stateless copies spun off the same containerDisk docker image created during the migration. This use case is only applicable for migrations performed with the Image intent.

  1. Apply the VirtualMachineInstanceReplicaSet YAML:

    kubectl apply -f deployment_spec.yaml
    
  2. List the running VMs:

    kubectl get vmis
    
  3. List VirtualMachineInstanceReplicaSets to locate the one we just created:

    kubectl get vmirs
    
  4. Scale the number of running replicas as desired using the standard k8s scale operation:

    kubectl scale --replicas=DESIRED_REPLICAS
    vmirs/VMI_REPLICA_SET_NAME
    

Run a stateful VM

In this use case, we'll run a single instance of a migrated stateful VM. This use case is applicable for migrations performed with both the Image and Data intents.

  1. Apply the VirtualMachine YAML.

    1. For migrations using the Data intent:
    kubectl apply -f deployment_spec.yaml
    
    1. For migrations using the Image intent:
    kubectl apply -f deployment_vm_spec.yaml
    
  2. List VMs:

    kubectl get vms
    
  3. List VM instances and make sure the VM is running:

    kubectl get vmis
    
  4. Connect to the VM console:

    kubectl virt console VMI_NAME
    
  5. Stop the VM:

    kubectl virt stop VM_NAME