Customizing a migration plan

You should review the migration plan file resulting from creating a migration, and customize it before proceeding to executing the migration. The details of your migration plan will be used to extract the workload container artifacts from the source VM, and also to generate Kubernetes deployment files that you can use to deploy the container image to other clusters, such as a production cluster.

This section describes the migration plan's contents and the kinds of customizations you might consider before you execute the migration and generate deployment artifacts.

Before you begin

  • This topic assumes that you've already created a migration and have the resulting migration plan file.

Impact of intent on migration plan

The contents of the migration plan you generated will differ depending on the kind of migration you created with the intent flag of the migctl migration create command.

This topic describes the purpose of each migration plan section. Each section indicates which intent value is relevant for YAML in the section. For more information on using the intent flag, see Creating a migration.

Set the migration's name and namespace

Intent: Any

Using the metadata field, you can specify the name and namespace for the migration. By default, Migrate for Anthos uses the values you specified when you created the migration. (You should not change the kind and apiVersion values.) The fields are the same for all intent values.

  • name -- Name of the migration.
  • namespace -- Namespace for the migration defined in this YAML file.
  kind: Migration
  apiVersion: anthos-migrate.cloud.google.com/v1beta1
  metadata:
    name: "my-migration"
    namespace: "default"

Set specifics of the VM to migrate

Intent: Any

The source field specifies information about the VM to migrate. The fields are the same for all intent values.

Information about the source will differ depending on the source platform.

VMware

  • runMode -- One of the following values:

    • TestClone (default) -- Specifies that the source VM should remain powered on (the source VM was cloned, so its origin can remain powered on), while Migrate for Anthos copies files for image and data from a copy of its disks.

    When the source VM is required to continue to run, while migration processing takes place. With stateful workloads, this mode might require a final data sync (data intent) migration to be executed with the source VM shut down to ensure a fully consistent data migration and transfer of all delta changes.

    • Normal -- Specifies that the source VM is powered off by Migrate for Compute Engine while Migrate for Anthos copies files for image and data from a copy of its disks.

  • vmId -- ID or name of the VM to migrate as it is known on the source platform. 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.

  spec:
    source:
      vmware:
        storageClassName: "my-vmware-src"
        vmId: "centos-mini"

        # Review and set the run mode (Normal/TestClone) of your source vm
        runMode: "TestClone"

AWS

  • runMode -- One of the following values:
    • TestClone -- Specifies that the source VM should remain powered on, while Migrate for Anthos copies files for image and data from a copy of its disks.
    • Normal -- Specifies that the source VM is powered off by Migrate for Compute Engine while Migrate for Anthos copies files for image and data from a copy of its disks.

  • vmId -- Amazon EC2 instance ID for your source VM. To get this value, you can use the Amazon EC2 console.

    The Instance ID in the Amazon EC2 console

  spec:
    source:
      aws:
        storageClassName: "my-aws-src"
        vmId: "centos-mini"

        # Review and set the run mode (Normal/TestClone) of your source vm
        runMode: "TestClone"

Azure

  • runMode -- One of the following values:
    • TestClone -- Specifies that the source VM should remain powered on, while Migrate for Anthos copies files for image and data from a copy of its disks.
    • Normal -- Specifies that the source VM is powered off by Migrate for Compute Engine while Migrate for Anthos copies files for image and data from a copy of its disks.

  • vmId -- The Azure VM resource ID for your source VM. To get this value, you can:

    1. Access and log in to the Azure Portal.
    2. In the navigation panel on the left, click Virtual Machines.
    3. On the Virtual Machines page, click the name of your VM.
    4. On your VM's page, in the navigation panel, click Properties.

    5. In the Properties page, locate the Resource ID value.

      The resource ID in the Azure portal

    6. Use the Resource ID value.

  spec:
    source:
      azure:
        storageClassName: "my-azure-src"
        vmId: "centos-mini"

        # Review and set the run mode (Normal/TestClone) of your source vm
        runMode: "TestClone"

Compute Engine

  • project -- Name of the Google Cloud project containing the VM to migrate.
  • zone -- Zone in which the VM is hosted.
  • vmId -- Name of the VM.
  • gceServiceAccountSecretName -- Name for the Kubernetes secret object that stores the service account key JSON to use for Compute Engine operations. The node-pool default service account is used by default.
  • labels -- Labels which will be applied to intermediate resources, such as Compute Engine snapshots and disks created from those snapshots.
  spec:
    source:
      gce:
        project: "my-project"
        zone: "us-central1-a"
        vmId: "my-vm"

        # The node-pool default service-account will be used for Compute Engine operations.
        # To specify a custom service-account:
        # store the service-account key json in a k8s secret object,
        # in the namespace "default",
        # then uncomment and edit the secret name in the following line:
        # gceServiceAccountSecretName: "my-secret-with-key-json"

        # You can set labels for created resources, such as Compute Engine volume snapshots and disk volumes:
        labels:
          migration-name: "my-migration"
          migration-namespace: "default"
          migration-cluster: "migration-processing"

Specify content to exclude from the migration

Intent: Any

By default, Migrate for Anthos will exclude typical VM content that isn't relevant in the context of GKE. You can customize that filter.

The excludeFilters field value lists paths that should be excluded from migration and will not be part of either the container image or the data volume. The field's value lists rsync filter rules that specify which files to transfer and which to skip. Preceding each path and file with a minus sign specifies that the item in the list should be excluded from migration. The list is processed according to the order of lines in the YAML, and exclusions/inclusions are evaluated accordingly.

For more, see the INCLUDE/EXCLUDE PATTERN RULES section of the rsync man page

You can edit this list to add or remove paths.

  artifacts:
      # Files and directories to exclude from the migration, in rsync format
      excludeFilters:
      - "- *.swp"
      - "- /etc/fstab"
      - "- /boot/"
      - "- /tmp/*"
      - "- /var/log/*"
      - "- /var/cache/*"

Set the name of the container image

Intent: Image or ImageAndData

The image field value defines the names and locations of two images created from a migrated VM. You can change these values if you prefer to use other names.

During migration, Migrate for Anthos copies files and directories representing your migrating workload to (by default) Container Registry for use during migration. The migration process adapts the VMextracted workload to an image runnable on GKE.

Migrate for Anthos preserves files and directories from the original VM (at the base path) in the registry. This image functions as a non-runnable base layer that includes the extracted workload files, which is then combined with the Migrate for Anthos runtime software layer to build an executable container image.

The use of separate layers simplifies later updates to the container image by allowing separate updates to the base layer or to the Migrate for Anthos software layer, as needed.

This image isn't runnable, but makes it possible for Migrate for Anthos to update the container from that original when you upgrade Migrate for Anthos.

The base and name field values specify images that will be created in the registry.

  • base -- Name of the image that will be created from the VM files and directories copied from the source platform. This image will not be runnable on GKE because it hasn't been adapted for deployment there.
  • name -- Name of the runnable image that will be used for the container. This image contains both the content from the source VM, and the Migrate for Anthos runtime, which allows it to be runnable.
  • containerRegistrySecretName -- Name for the Kubernetes secret object that stores the service account key JSON to use for Container Registry operations. The node-pool default service account is used by default.
        image:
          # Review and set the name for extracted non-runnable base image
          base: "gcr.io/my-project/centos-mini-non-runnable-base:v1.0.0"

          # Review and set the name for runnable container image
          name: "gcr.io/my-project/centos-mini:v1.0.0"

          # The node-pool default service-account will be used for GCR operations.
          # To specify a custom service-account:
          # store the service-account key json in a k8s secret object,
          # in the namespace "default",
          # then uncomment and edit the secret name in the following line:
          # containerRegistrySecretName: "my-secret-with-key-json"

Set handling for the data volume

Intent: Data or ImageAndData

The dataVolumes field specifies the PersistentVolumeClaim to use for your data volume, along with a list of folders to include in the data volume.

  • pvcName -- Name of the PersistentVolumeClaim to use. This should be in default namespace. A PersistentVolumeClaim definition is included in the migration plan.

    This is pre-filled by default with an auto-created PersistentVolumeClaim (PVC) that will result in a Compute Engine persistent disk. You can replace this PVC with a different PVC of your own choice if you want to migrate the data to your own choice of a storage class.

  • folders -- Folders to include in the data volume.

        dataVolumes:
        # Review and set the PVC name for your data volume. The referenced PVC needs to be in the namespace "default"
        - pvcName: "pvc-my-vm"

        # Folders to include in the data volume, e.g. "/var/lib/mysql"
        # Included folders contain data and state, and therefore are automatically excluded from a generated container image
        folders:
        - "<folder>"

Set the Cloud Storage location for deployment artifacts

Intent: Any

During migration, Migrate for Anthos uses Cloud Storage to store files that you'll later use to deploy you VM on a production cluster. You can change the bucket and folder names to use your own.

  • bucket -- Name of the Cloud Storage bucket in which to store artifacts.
  • pathPrefix -- Name of the folder inside bucket in which to store artifacts.
  • appName -- Name to give the Kubernetes controller to use in the deployment file. The type of controller will differ based on the value you specified for the intent flag when you created the migration:
    • For an image-and-data value, the result will be a StatefulSet object with this name.
    • For an image value, the result will be a Deployment object with this name.
        deployment:
          # Bucket that stores the deployment artifacts, such as YAML specs and Dockerfile
          bucket: "my-project-migration-artifacts"

          # Review and set the migration folder in the bucket, for the deployment artifacts, such as YAML specs and Dockerfile
          pathPrefix: "default-my-migration/"

          # Review and set the app-name for your StatefulSet or Deployment YAML spec
          appName: "app-centos-mini"

          # The node-pool default service-account will be used for Cloud Storage operations.
          # To specify a custom service-account:
          # store the service-account key json in a k8s secret object,
          # in the namespace "default",
          # then uncomment and edit the secret name in the following line:
          # repositorySecretName: "my-secret-with-key-json"

Configure persistent storage

Intent: Data or ImageAndData

For most migration intents, the migration plan includes a StorageClass and PersistentVolumeClaim definition (they're commented out in the Image intent migration plan). These are Kubernetes standard definitions with default values you can change to match the needs of your system.

Note that the PersistentVolumeClaim metadata name value should be the same as the value used in corresponding fields in the plan, including the dataVolumes pvcName field. Note: By default, a PVC is created to generate a Compute Engine persistent disk as the data target. You can choose to the existing PVC or create one of your own storage class choice to change the target to a different storage type

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: retain-standard-ssd
provisioner: kubernetes.io/gce-pd
reclaimPolicy: Retain
parameters:
  type: pd-ssd
  replication-type: none

---

# Review and set the persistent volume type (the default is zonal SSD Persistent Disk)
# Review and set the size for the Persistent Volume (the default is 10G)
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: "pvc-my-vm-instance-1"
  namespace: "default"
spec:
  storageClassName: retain-standard-ssd
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10G

Next Steps