Migrating VMware VMs to GKE

Migrate for Anthos containerizes your source VMs into StatefulSet Pods on Google Kubernetes Engine. It runs migrated system containers with the source VM disks transformed and migrated to Google Kubernetes Engine PersistentVolumes.

Copy the code examples provided here into configuration files of your own, replacing placeholders and applying the configuration code to your own GKE instance to configure the instance.

The YAML you'll use here includes fields specific to Migrate for Anthos. For more information about them, see YAML reference.


  • Before migrating VMs to GKE, be sure you've set up or verified the prerequisites described in Prerequisites for migrating VMware VMs to GKE.

  • You'll also need the following values to complete the steps in this topic.

    • A unique identifier for your VM on VMware. You can use one of the following values.

      • The VM name. If you're confident that each VM name is unique across your VMware deployment, the simple VM name will work. If VM names might be duplicated, use the VM ID as described below.

        You can get the VM name from the vSphere web client, as shown in the following image.

      • The VM ID from vSphere (also called a MoRef). This is visible from the URL of the vSphere web client when selecting the VM.

        The MoRef is in the URL from vSphere

        You can find also the MoRef by using PowerCLI

    • The StorageClass name from your cluster's environment. For example, csi-disk-sc01. This was defined when you created your Migrate for Anthos deployment.

  • Verify that your VMware instance is available as a source for migration. You can do this using the StorageClass that was created when you created the cluster using Marketplace.

    1. Run the following command:

       kubectl describe storageclass storageclass-name
    2. In the command's output, look in the Events list for warnings. If the connection is healthy, you'll see no events.

Configure storage for streaming data during migration

For more about portions of the YAML specific to Migrate for Anthos, be sure to see the YAML reference.

  1. Create a YAML file and paste the following into it.

    You can also configure logging to Stackdriver Logging here. For more, see Configuring logging to Stackdriver Logging.

    kind: PersistentVolumeClaim
    apiVersion: v1
      name: [PVC_NAME]
        # Replace vm-id with a unique identifier. See the prerequisites
        # earlier in this topic.
        anthos-migrate.gcr.io/vm-id: [VM_ID]
        anthos-migrate.gcr.io/vm-data-access-mode: "FullyCached"
        anthos-migrate.gcr.io/run-mode: "TestClone"
      - ReadWriteOnce
      # Replace with your Storage Class name defined when adding Migrate for Anthos to your cluster
      storageClassName: [STORAGE_CLASS_NAME]
          storage: 1Gi
    kind: StatefulSet
    apiVersion: apps/v1
      name: [APPLICATION_NAME]
      namespace: default
      serviceName: [SERVICE_NAME]
      replicas: 1
          app: [APPLICATION_NAME]
            app: [APPLICATION_NAME]
            anthos-migrate.gcr.io/action: run
            anthos-migrate.gcr.io/source-type: streaming-disk
            # source-pvc needs to match the name of the PVC declared above.
            anthos-migrate.gcr.io/source-pvc: [PVC_NAME]
          - name: [APPLICATION_NAME]
          # The image for the Migrate for Anthos system container.
            image: anthos-migrate.gcr.io/v2k-run:v1.0.0


    • [VM_ID] is VM's unique identifier. See the prerequisites in this topic for more.
    • [STORAGE_CLASS_NAME] is the name from the environment configuration YAML you used in configuring your cluster.
    • [APPLICATION_NAME] is the name of your GKE workload.

    • If you would like to fully cache volumes on Google Cloud after starting them on GKE, change the value of anthos-migrate.gcr.io/vm-data-access-mode to FullyCached.

  2. Save the file.

  3. Apply the YAML to your cluster

    kubectl apply -f deployment-yaml
  4. Open the GKE Workloads page on the Google Cloud Console.

  5. Check that your workload is running on the cluster.

Test your migrated VMs

Run tests that exercise the functionality on your VMs. The nature of your tests will depend on what your applications are designed to do. Your tests should verify that your applications work as they did before you migrated the VMs.

Once you've validated your migrated VMs with tests, you're ready to move on to export your VM storage to a permanent location. Exporting storage enables your migrated VMs to run independent of their source VM disks.

Be sure to export storage before turning down or deleting your source VMs.

For more, see Exporting streaming PVs to permanent storage.

Executing bash commands on your container

You can access a container through a bash shell using the kubectl exec command.

  1. Use kubectl describe pods to find the name of the Pod in your cluster that you want to connect to.

    In the following example, the command lists the suitecrm-0 pod.

    kubectl describe pods | grep Name
    Name:               suitecrm-0
  2. Execute shell commands using one of the following methods:
    • Use kubectl exec to open a bash command shell where you can execute commands.
      kubectl exec -it pod-name -- /bin/bash

      The following example gets a shell to the suitecrm-0 pod:

      kubectl exec -it suitecrm-0 -- /bin/bash
    • Use kubectl exec to execute commands directly.
      kubectl exec -it pod-name -- /bin/bash -c "command(s)"

      The following example lists the root directory of the suitecrm-0 pod:

      kubectl exec -it suitecrm-0 -- /bin/bash -c "ls /"

For more information, see the Kubernetes documentation.

My workload won't start

See Troubleshooting.

Next Steps

Export your VM storage to a permanent location. For more, see Exporting streaming PVs to permanent storage.

Was this page helpful? Let us know how we did:

Send feedback about...

Migrate for Anthos Documentation