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:
- Access to GKE on Bare Metal version 1.12.0 or later. You can use any cluster type capable of running workloads. If needed, try Anthos clusters on bare metal on Compute Engine or see Cluster creation overview.
- Make sure the VM runtime is available on the GKE on Bare Metal cluster.
- A source VMware installation meeting the minimum requirements.
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.
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
Export
kubeconfig
:export KUBECONFIG=PATH_TO_KUBECONFIG
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
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 setlocal-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.
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
Enter the vCenter password when prompted.
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.
Create a migration:
migctl migration create MIGRATION_NAME --source SOURCE_NAME --vm-id VM_NAME --intent IMAGE_OR_DATA --type vm
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 theGenerateMigrationPlan
operation changes fromRunning
toCompleted
.migctl migration status MIGRATION_NAME
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.
Generate the artifacts (also called executing a migration):
migctl migration generate-artifacts MIGRATION_NAME
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 theGenerateArtifacts
operation changes fromRunning
toCompleted
.migctl migration status MIGRATION_NAME
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.
Apply the
VirtualMachineInstanceReplicaSet
YAML:kubectl apply -f deployment_spec.yaml
List the running VMs:
kubectl get vmis
List
VirtualMachineInstanceReplicaSets
to locate the one we just created:kubectl get vmirs
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.
Apply the
VirtualMachine
YAML.- For migrations using the Data intent:
kubectl apply -f deployment_spec.yaml
- For migrations using the Image intent:
kubectl apply -f deployment_vm_spec.yaml
List VMs:
kubectl get vms
List VM instances and make sure the VM is running:
kubectl get vmis
Connect to the VM console:
kubectl virt console VMI_NAME
Stop the VM:
kubectl virt stop VM_NAME