VM Runtime on Google Distributed Cloud (GDC) is designed to run virtual machines (VMs) in specialized use cases, such as Retail Edge. VM Runtime on GDC isn't intended as a full replacement for existing data center virtualization technologies. If you have any questions, contact your Google Cloud account team for more information.

Migration parameters and artifacts

To perform a migration, you must specify the following parameters.

Parameter	Value
migration-name	A name that describes the migration. The migration name may use up to 63 characters, lowercase alphanumeric or "-" (hyphen) only. The name must start and end with an alphanumeric character.
source-name	The name of the migration source used for the migration.
vm-id	You can use either the VM name or ID. If you're confident that each VM name is unique across your VMware deployment, the simple VM name works. You can get the VM name from the vSphere web client. If VM names are not unique, use the VM ID (also called a MoRef) from vSphere. You can find the VM ID in three ways: From the fit assessment report. From the URL of the vSphere web client when selecting the VM. By using PowerCLI.
intent	`Data` or `Image`, depending on whether the workload is stateful or stateless, respectively.
type	This parameter is `vm` for VM migrations.

Intent parameter

When you perform a migration, you specify an intent flag value based on the nature of your workload. The flag's value determines the contents of your migration plan, which in turn guides the migration. For image intents, we produce deployment specs for a KubeVirt virtual machine and KubeVirt virtual machine replica set. For data migrations, we produce deployment specs for a GVM virtual machine and KubeVirt virtual machine.

Intent flag value	Workload	Notes
Image	Stateless	Creates a containerDisk docker image based on the disk of the source VM, and uploads it to the configured Docker registry. Additionally, a YAML artifact is created, defining a VirtualMachineInstanceReplicaSet based on the containerDisk. Note: Currently, only single-disk VMs can be migrated using the `Image` intent.
Data	Stateful	Creates a PersistentVolumeClaim (PVC) for each disk of the source VM. The PVCs are backed by Persistent Volumes provisioned either using the cluster's default storage class, or by a storage class explicitly specified in the migration plan. Additionally, a yaml artifact is created, defining a VirtualMachine using said PVCs as the disks of the resulting KubeVirt VM. Note: These VMs can only be used in the cluster which was used to migrate them.

Migration artifacts

When generating artifacts, migrate does the following:

Exports the source VM disks into temporary storage.
Converts the VM disk images to VM Runtime on Google Distributed Cloud compatible formats ("qcow2" for Image intent, "raw" for Data intent).
Adapts the guest OS to properly run on VM Runtime on Google Distributed Cloud virtual hardware.
Generates configuration YAML files that you can use to deploy the extracted VM workloads to the target Google Distributed Cloud Virtual for Bare Metal cluster. These are copied into the defined artifacts repository as an intermediate location. You can later download these files.

Image intent migration artifacts

When performing an "Image" migration Migrate creates a KubeVirt "containerDisk" and uploads it to the configured/default docker registry. A "containerDisk" is a docker image containing a single qcow2 virtual disk file that can be executed as a VM using VM Runtime on Google Distributed Cloud, including support for standard Kubernetes scaling.

Migrate creates the following artifacts during an "Image" migration:

Name	Description
containerDisk image	A docker image containing the migrated VM disk. It is uploaded to the configured docker registry.
deployment_spec.yaml	Contains a VirtualMachineInstanceReplicaSet which is the KubeVirt VM equivalent to a standard k8s ReplicaSet. This VirtualMachineInstanceReplicaSet references the containerDisk uploaded to the docker registry as its disk image.
deployment_vm_spec.yaml	Contains a VirtualMachine that describes a VM that the containerDisk uploaded to the docker registry as its disk image.
migration.yaml	A copy of the migration plan.

When performing an Image-intent migration, it is possible to use different Google Distributed Cloud Virtual for Bare Metal clusters for the migration process (for example, processing clusters) and for the deployment of migrated workloads, as long as the latter have access to the docker registry to which the Image is uploaded. However in most cases we suggest using the same cluster for both performing the migration and deploying the migrated workloads.

Data intent migration artifacts

When performing a "Data" migration, for each disk of the source VM - Migrate creates a PVC on the target cluster bound to a PV containing a raw disk image copy of the original disk for each of the VM's disks. By default, the PVC is provisioned using the default storage class, but this could be customized in the migration plan.

We create the following artifacts during a "Data" migration:

Name	Description
PVCs in target cluster	A separate PVC is created for each disk of the source VM in the selected namespace.
deployment_spec.yaml	Contains a VirtualMachine that describes a VM that references the disks from the generated PVCs.
migration.yaml	A copy of the migration plan.