Migration process
The migration process for an individual source VM occurs in the following phases:
Onboard: Select the VMs to migrate.
Replicate: Replicate data from the source VM to Google Cloud. Data replication is a continuous process that takes place in the background until the final cut-over or you deleting the migration.
Set VM target details: Configure settings for the migrated VM, such as the project, instance type, memory, network, and more.
(Optional) Test-clone: Create a clone of the source VM from the replication data and test it on Google Cloud.
Cut-over: Migrate the source VM. This process includes stopping the source VM, performing a final replication, and creating the production instance from the source VM.
Finalize: Clean up all resources consumed by the migration following a successful cut-over operation.
For a complete description of each of these phases, see VM Migration lifecycle.
You should also see Migration progress details for more insight into how to monitor progress during your migration journey.
The VM migration process follows the same steps as that of the disk migration process. Therefore, you can choose to switch from VM migration to disk migration and the other way around at any point during the migration process. For more information, see Switch from VM migration to disk migration.
This document describes the phases of migrating a source VM to Google Cloud.
Prerequisites
Perform the following steps to configure the migration environment on your migration source and migration target.
- Enabling Migrate to Virtual Machines services.
- (Only for VMware VM migration) Installing the Migrate Connector.
- Some Compute Engine features require agents and services running on the VM. These agents and services are installed automatically during the migration. However, certain security features such as SELinux, anti-viruses, and firewalls, may interfere with these services and prevent certain features from functioning. In order to make sure that the guest environment functions properly, follow the steps in Loaded services for the guest environment and if needed, the Troubleshooting steps for Compute Engine.
Licensing
Compute Engine supports premium pay as you go (PAYG) licenses and bring your own (BYOL) licenses, based on the operating system of the source VM. PAYG licenses are billed based on the resources that you use.
See Supported operating systems for details on licensing for all supported operating system.
Step 1: Onboard a VM
The first phase of migration is to onboard the source VM. For example, a vSphere data center might contain tens, hundreds, or even thousands of VMs. Onboard only the VMs that you want to migrate.
You can have up to 200 migrations in progress at a time (excluding migrations in the Finalize phase), per host project and region. This limitation is for migrating VMs of all source types. For example, you can migrate 100 VMs from a VMware source and 100 additional VMs from AWS at the same time.
To onboard a source VM, follow these steps:
Open the Migrate to Virtual Machines page in the Google Cloud console:
Select the Sources tab.
From the drop-down list, select the migration source from which you want to migrate a VM.
Below the drop-down you see the Source status of the migration source as:
- Active: The source is active and connected to Migrate to Virtual Machines.
- Offline: The source is unavailable.
- Pending: The source is in the process of being connected and verified.
If you don't see any entries in the drop-down list, it indicates that you have not configured the migration source properly. Review the steps for your setting your migration source and try again.
A table appears showing the source VMs in the migration source available for migration. Select one or more source VMs.
The VM Power Status column shows the status as Suspended, On, or Off. You can migrate a VM with any of these statuses.
Click Add Migrations > VM Migration.
Confirm that you want to create the migration.
After you create a migration, the Replication status column for a VM displays one of the following:
- Pending: VM is in the process of being onboarded.
- Ready: VM is onboarded but has not started replicating yet.
You can now start replication of the VMs as described in the next step.
Step 2: Start replication of the source VM
After onboarding a source VM, start replicating the disk data from the source VM to Google Cloud. This process takes place in the background with no disruption to the workload.
Data replication is comprised of two steps:
First replication step: Migrate to Virtual Machines creates the initial snapshot of the source VM data disks and replicates the snapshot data to Google Cloud. Depending on the amount of disk data on the source VM, the first replication can take minutes or hours to complete.
The Replication status column of a VM on the first replication step displays the First sync status followed by the appropriate sub-step.
Incremental replication step: Following a successful first replication step, incremental replication steps occur at set time intervals (every two hours by default). In each step, a new snapshot is created for each data disk. Only data updates that occurred after the previous step are replicated to Google Cloud using the Change Block Tracking (CBT) mechanism.
The Replication status column of a VM on an incremental replication step displays the Active status followed by the appropriate sub-step.
Initiate replication of a source VM
To initiate replication of a source VM, follow these steps:
Open the Migrate to Virtual Machines page in the Google Cloud console:
Select the Migrations tab.
A table appears showing the source VMs in the migration source that you have onboarded. You can start replication on any VM with the replication status Ready.
Select one or more source VMs.
Click Migration > Start Replication. The Replication status column shows replication status along with one of the sub-steps detailed in the replication cycle sub-steps table.
To view the replication history of a VM, click the VM to open the details page. Click Replication History to view the replication history of the VM along with the sub-steps of the replication.
You can now configure a migration target for the test-clone and cut-over phases.
Migrate to Virtual Machines generates an adaptation report after your replication cycle is complete. For more information about adaptation reports, see the adaptation report documentation.
You can create a test-clone at any time after the first replication step completes. Replication continues until you explicitly end it during the cut-over phase.
Pause replication
To pause replication, follow these steps:
At any time, you can pause replication for a VM. When you pause a VM, its Replication status changes to Paused.
Open the Migrate to Virtual Machines page in the Google Cloud console:
Select the Migrations tab.
A table of available source VMs appears.
Select one or more VMs.
Select Pause.
To later resume replication, select one or more VMs and then select Resume.
Set the replication interval
To set the replication interval, follow these steps:
By default, Migrate to Virtual Machines performs a replication of the source VM every 2 hours. To change the replication frequency:
Open the Migrate to Virtual Machines page in the Google Cloud console:
Select the Migrations tab.
A table of available source VMs appears.
For the VM, select the Edit Target Details button. A panel opens to let you configure the target.
To set the frequency for multiple VMs, select the VMs and then select the Edit Target Details button. A panel opens to let you configure the replication frequency of the selected VMs.
Select the Target Details tab.
In the Replication policy area, set the replication frequency, in seconds.
Select Save.
Switch from VM migration to disk migration
You can switch between VM migration and disk migration at any time during the migration process.
To switch from VM migration to disk migration, follow these steps:
Open the Migrate to Virtual Machines page in the Google Cloud console:
Select the Migrations tab.
Select one or more VMs.
Click Migration > Convert to disk migration.
Switching from VM migration to disk migration clears out the target details. This is because the target details for VM migration and disk migration are different. However, the replication progress won't be lost during the switch.
You must update the target details before you clone or cut-over operations on your VM in order for the migration to succeed. For more information, see Configuring the target.
Step 3: Configure the target for a migrated VM
To configure a target, perform two main steps:
Add a target project. The target project is the project that contains the Compute Engine instance used to host the migrated VM.
The host project is automatically added as a target project so there is no need to explicitly add it. If you want to add an additional project as a target project, see Adding a target project.
Configure the Compute Engine instance used to host the migrated VM. For both a test and a production environment, configure the target Compute Engine instance to specify settings including:
- Google project
- Number of CPUs
- Amount of memory
This section describes how to set the initial configuration of the Compute Engine instance used to host the migrated VM. However, there are many additional settings that you can apply to a Compute Engine instance. See the Compute Engine documentation for detailed descriptions of all settings.
You can modify the target details at any time. When instantiating a Compute Engine instance for either the test-clone or cut-over phase, Migrate to Virtual Machines uses the target details settings at the time of the operation.
To configure the Compute Engine target, follow these steps:
If you have not done so already, add the target project as shown in Adding a target.
Open the Migrate to Virtual Machines page in the Google Cloud console:
Select the Migrations tab.
A table of migrations appears.
Select a VM (you can select multiple to edit) and then select the Edit target details button. On the panel that appears, configure the target details for all of your selected VMs.
Set the Target details that define the characteristics of the Compute Engine instance used to host the migrated VM. The following table lists those settings and provides links to the Compute Engine documentation for detailed descriptions.
Migrate to Virtual Machines does not support all Compute Engine settings. You can only set those described in the following table. After the Compute Engine instance is created, you can modify all of its settings:
Section title Field name Description General Instance name The name of the Compute Engine instance. See Resource naming convention for the naming rules. Project The name of the project hosting the Compute Engine instance. It must be a project you have already added earlier in this section. Zone Zone for the Compute Engine instance. See Regions and Zones.
The region of the deployed instance is the one you specified when you registered the Migration Connector. See Installing the Migration Connector for more.Labels To organize your project, add labels as key/value pairs to your resources. See Labeling resources. Machine configuration Machine type series Compute Engine offers predefined machine type series that you can use when you create an instance. Each option has a different cost. Select the machine type series that is most appropriate for your workload.
See Pricing for more information.
Migrate to Virtual Machines determines the OS type of the Compute Engine instance automatically based on the source VM and applies PAYG licensing to the instance. See Licensing.Machine type Compute Engine offers predefined machine types that you can use when you create an instance. The available machine types depend on the machine series you select in the Machine type series field.
See predefined machine types documentation for more information.On host maintenance When Compute Engine performs periodic infrastructure maintenance, it can migrate your VM instances to other hardware without downtime. Set this option to Migrate VM Instance (Recommended), the default, to migrate the VM. Set it to Terminate to terminate the instance. Automatic restart When set to On (Recommended), the default, Compute Engine automatically restarts instances when they are terminated for non-user-initiated reasons, such as a maintenance event, hardware failure, or software failure. Set it to Off to disable restart. Metadata Specify VM metadata key/value pairs that will be stored for your migrated VM.
For more information about Compute Engine VM metadata, see the VM metadata documentation.
Migrate to Virtual Machines enforces a limitation of 64K characters for all metadata key/value pairs in each migrated VM.Networking Network name Specify the VPC network that the instances will be part of. Subnetwork name Specify the subnet associated with a region. This must be a subnetwork of the specified Network. External IP address Set to None (default) to disable external access, and to Ephemeral to allow gcloud CLI to assign an IP address. See Configure static external IP addresses. Internal IP address Set to Ephemeral (Automatic) (default) to allow gcloud CLI to assign an IP address, Ephemeral (Custom) to set your own IP address, or reserved-internal-ip (IP) to use a predefined IP address. See Configure static internal IP addresses. Hostname You can create a VM with a custom hostname by specifying any fully qualified DNS name. Custom hostnames must conform to RFC 1035 requirements for valid hostnames.
For more information about formatting custom hostnames, see the Custom hostname documentation.
You can change the hostname for Windows VMs using the TargetDetails API. After changing a Windows VM hostname locally, ensure that you update the hostname in the Active Directory (AD) so that AD trust doesn't break.
Add Network Interface Migrate to Virtual Machines lets you optionally create a Compute Engine instance with multiple network interfaces (NICs). Each interface is attached to a different VPC network, giving that instance access to different VPC networks in gcloud CLI.
Before you add additional network interfaces, be aware of the following considerations:
- Attaching multiple network interfaces to the same VPC network is not supported. While the configuration may save, the instantiation of the VM will fail.
- After a Compute Engine instance is instantiated, by using
test-cloneorcut-over, you cannot add or remove a network interface on the created instance. You can repeattest-cloneorcut-overwith different target details to recreate the instance.
To add or remove a network interface: - Select Add network interface to add an additional network interface to the Compute Engine instance. You can set all of the same options as you do with the initial network interface.
Network tags Tags enable you to make firewall rules and routes applicable to specific instances. See Configuring network tags. Additional configuration Service account Specify the service account on the target project used to run the Compute Engine instance. By default, no service account is assigned to the Compute Engine instance.
If you plan to run an application on the Compute Engine instance that needs access to other gcloud CLI services and APIs, create a service account in the target project with the necessary permissions to access those services and APIs before creating the Compute Engine instance. Then, specify that service account here. For more information, see set up a VM to run as a service account.
To attach the service account to the Compute Engine instance, your user account on the Migrate to Virtual Machines host project requires the necessary permissions. See Configuring permissions on target project service account for more.Disk type Specify the storage type for the instance. See Storage options. Customer managed encryption key The key you want to use to protect your data in Google Cloud. By default, Google Cloud automatically encrypts data when it is at rest using encryption keys managed by Google. If you have specific compliance or regulatory requirements related to the keys that protect your data, you can use customer-managed encryption keys (CMEK) to encrypt and decrypt your data at rest. These encryption keys are created, managed, and owned by you.
When you add a CMEK, you must also assign the Cloud KMS CryptoKey Encrypter/Decrypter role permissions to the Compute Engine Service Agent account you are using. For more information, see Protect resources by using Cloud KMS keys.Convert BIOS to UEFI (Preview) Enable this option to convert the OS boot type of a VM instance from Basic Input/Output System (BIOS) to Unified Extensible Firmware Interface (UEFI). This option is useful when you want to securely boot your VM instance, as secure boot is only supported by UEFI. However, you can also just convert the boot type from BIOS to UEFI, without using secure boot.
The capability to convert the boot type of a VM instance from BIOS to UEFI is available as part of a Preview. To participate in the preview, send a request to the email address: m2vm-bios-to-uefi@google.com.
Secure boot All selected VMs must have an EFI boot option to enable secure boot. Compute Engine enforces up-to-date policies that may prevent your VM from loading when secure boot is enabled. For more information, see Secure Boot in the Compute Engine documentation. License type Compute Engine supports pay as you go (PAYG) licenses and bring your own licenses (BYOL) for your deployed VMs. The default license type for a migrated VM is assigned by Migrate to Virtual Machines based on the migrated operating system, as described in Supported operating systems.
If your operating system supports multiple license types, you can override the default license type to explicitly specify a license type of PAYG or BYOL.
Additional licenses Migrate to Virtual Machines supports up to 10 additional licenses (using valid URL format) that you can add in the Additional configuration section of the Target details dialog.
For example, you can add additional licenses using this URL format:
https://www.googleapis.com/compute/beta/projects/windows-sql-cloud/global/licenses/sql-server-2012-enterprise
Sole tenancy Node affinity labels Compute Engine supports the deployment of migrated workloads to sole-tenant nodes. A sole-tenant node is a Compute Engine server that is dedicated to hosting only your project's VMs.
Before you can configure your migrated workloads to run on sole-tenant nodes, you must have already created a sole-tenant node template and sole-tenant node group in the target project and zone. See Provisioning VMs on sole-tenant nodes.
Affinity labels let you logically group nodes and node groups. When provisioning your Compute Engine instances, use affinity labels to schedule your instances to run on a specific set of nodes or node groups.
You can add affinity labels to your migrating VMs by entering them manually in the Info panel by key-value pair, or by using the Browse Node dialog to select a node or node group. You can then edit the VM affinity labels to customize the sole-tenant deployment:
- Select Browse Node to add an affinity label from the list of available sole-tenant nodes and node groups. A key-value pair will automatically be created for you upon selecting the node or node group.
- Select Add New to manually enter the affinity label.
Minimum vCPUs allocated Set the Minimum vCPUs allocated for the Compute Engine instance.
See Node affinity and anti-affinity and Configure node affinity labels for more information.Replication Policy Replication idle duration between cycles By default, Migrate to Virtual Machines performs a replication of the source VM every 2 hours. Set the replication frequency (in seconds).
Select Save.
You can later edit the target details. When instantiating a Compute Engine instance
for either the test-clone or cut-over phase, Migrate to Virtual Machines uses the
target details settings at the time of the operation.
(Optional) Step 4: Test a clone of a migrating VM
In the test-clone phase, Migrate to Virtual Machines deploys a clone of your migrated VM to a Compute Engine instance in your testing environment. While the testing phase is optional, it is best practice to perform testing before deploying a migrated VM to production.
Each time you create a test-clone instance, it is cloned from the most recently completed replication cycle data using the current target details. In other words, a test-clone instance represents a snapshot of the source VM at the time of the last completed replication cycle.
For Azure source VMs that have more than one disk, the Migrate to Virtual Machines replication cycles take snapshots of each disk independently of each other. As these snapshots are not taken simultaneously, the data captured might sometimes have minor discrepancies. Therefore, it is recommended that you don't use test-clones as a production replacement when you cut-over.
Initiate your first test-clone
You can create your first test-clone after the initial replication cycle completes, and then create additional test-clones throughout your migration process.
In order for you to initiate a test-clone, you must have already configured a target environment for the Compute Engine instance before you can initiate a test-clone. See Configuring the target documentation for more information.
You can only test a VM in the Paused state if it has completed at least one replication.
For more information on potential issues during the test-clone phase, see the Troubleshooting section.
Create a test-clone of a VM
To create a test-clone of a VM using Migrate to Virtual Machines, follow these steps:
Ensure that you have configured a testing VM target environment as shown in Configuring VM target.
Open the Migrate to Virtual Machines page in the Google Cloud console:
Select the Migrations tab.
A table of available source VMs appears. You can test any VM that is in the Active (Current cycle: XX%) or Active (Idle) state. The Active state means the first replication sync of the VM succeeded and VM data is being incrementally replicated.
Select a VM.
Select Cut-Over and Test-Clone > Test-Clone. The Test-Clone/Cut-Over status column shows the status of the operation along with one of the sub-steps detailed in the test-clone sub-steps table.
Wait for the Test-Clone/Cut-Over status column to show Succeeded. This indicates that the clone was created successfully.
You can view the test-clone history of a VM in one of the following ways:
Click the Info panel icon,
for the VM. On the panel that opens from the
right, the Monitoring tab displays the history, including the name of
each test-clone instance.Click the VM to open the details page. Click Test-Clone/Cut-Over History to view the test-clone history of the VM along with the sub-steps of the test-clone.
You can cancel an active test-clone operation by clicking Cut-Over and Test-Clone > Cancel Test-Clone.
For the test-clone VM, click Show details to view the VM instance name.
To manage the running Compute Engine instance, go to the VM instances page in the Google Cloud console for your project:
From the Google Cloud console manage the Compute Engine instance to:
- Start, stop, and delete the instance.
- Determine the internal and external IP address of the instance.
- View and modify characteristics of the instance.
- Perform all other management tasks.
Perform any validation testing or other testing on the migrated VM.
After you have completed testing, delete the Compute Engine instance to free up resources so that you will no longer be charged for the instance.
Manage multiple test-clones
Over the duration of your migration journey, you might create multiple test-clones. For example, you create the first test-clone after the initial replication cycle. Then, as you refine your migration, you create new test-clones because of:
- Modifications you make to your source VM to support migration
- Modifications you make to the target details of the migrated VM
- New replication data from the source VM
- Any other changes you make over the duration of your testing cycle
Remember that a test-clone is a snapshot of the source VM created from the current replication data and target details. New replication data and modifications to the target details are only applied to new test-clones, not to existing test-clones.
If you have an existing test-clone instance running, then before you create a new test-clone you can either:
Delete the existing test-clone instance and then create a new one with the same instance name. You cannot create a new instance with the same name as an existing instance.
Edit the target details to set a new instance name. In addition, if you specified a reserved or custom IP address for an existing test-clone instance, make sure to use different values for any additional instances.
To monitor all test-clone instances, follow these steps:
View the test-clone history of a VM in one of the following ways:
Click the Info panel icon,
for the VM. On the panel that opens from the
right, the Monitoring tab displays the history, including the name of
each test-clone instance.Click the VM to open the details page. Click Test-Clone/Cut-Over History to view the test-clone history of the VM along with the sub-steps of the test-clone.
To manage a running Compute Engine instance, select the arrow icon to open the VM instance in the Google Cloud console.
Or, go directly to the VM instances page in the Google Cloud console:
After you create a test-clone, it is up to you to manage it. If you want to modify or delete a running test-clone VM, you use the Compute Engine tools, not Migrate to Virtual Machines.
Step 5: Create a Cut-over
In the cut-over phase, you transfer control to your migrated VM running in a Compute Engine instance in your production environment on Google Cloud.
Migrate to Virtual Machines generates an adaptation report when your cut-over cycle is complete. For more information about adaptation reports, see the adaptation report documentation.
The cut-over process, follow these steps:
If data replication is active, that is, the Replication status of the VM is Active (Current cycle: XX%), waits for it to complete.
Shuts down the source VM.
Performs the final data replication. Because replication occurs throughout all migration phases, the amount of data to replicate shouldn't be very large.
Stops replication.
Creates the Compute Engine instance from the final replicated data.
The cut-over phase includes a short VM downtime and should take place during a scheduled maintenance window. You must determine the maintenance window during which you can stop the source VM and redirect traffic to the migrated VM running on Compute Engine.
To create a cut-over, follow these steps:
Ensure that you have configured the VM target details as shown in Configuring VM target. If the target details were previously configured for test-clone operation, you might want to edit the target details to point to a new target.
Open the Migrate to Virtual Machines page in the Google Cloud console.
Select the Migrations tab.
A table of available source VMs appears. You can cut-over any VM that is in the Active (Current cycle: XX%) or Active (Idle) state. The Active state means the first replication sync of the VM succeeded and VM data is being incrementally replicated.
The Estimated cut-over time column shows an estimate of the time it takes to complete a cut-over job for a VM after you initiate a cut-over. This field is populated only for an active VM that has completed a few replication cycles.
The Test-Clone/Cut-Over status column shows the status of the operation along with one of the sub-steps detailed in the cut-over sub-steps table.
Select a source VM.
Select Cut-Over and Test-Clone > Cut-Over. Initiating a cut-over on a migrating VM starts the following sequence of actions performed by Migrate to Virtual Machines:
Shuts down the source VM.
Performs the final data replication. Because continuous replication occurs throughout all migration phases, the amount of data to replicate should not be very large.
Creates the Compute Engine instance hosting the migrated VM from the final replicated data.
Stops data replication.
Wait for the Test-Clone/Cut-Over status column to show Cut-over job completed. This indicates that the cut-over succeeded.
You can view the cut-over history of a VM in one of the following ways:
Click the Info panel icon,
, for the VM. On the panel that opens from the
right, the Monitoring tab displays the history, including the name of
each cut-over instance.Click the VM to open the details page. Click Test-Clone/Cut-Over History to view the cut-over history of the VM along with the sub-steps of the cut-over.
You can cancel an active cut-over operation by clicking Cut-Over and Test-Clone > Cancel Cut-Over. However, if you want to resume use of the source VM, you must manually restart the VM.
To manage a running Compute Engine instance, select the arrow icon to open the VM instance in the Google Cloud console.
Or, go directly to the VM instances page in the Google Cloud console:
From the Google Cloud console manage the Compute Engine instance to:
- Start, stop, and delete the instance.
- Determine the internal and external IP address of the instance.
- View and modify characteristics of the instance.
- Perform all other management tasks.
Perform validation test on the migrated workload.
If for any reason you want to retry cut-over or roll back from the cut-over:
Retry cut-over
To retry cut-over, follow these steps:
Select a VM in the Cut-Over state.
Select Migration > Resume Replication.
Retry cut-over.
Rollback from cut-over
To rollback from cut-over, follow these steps:
Cut-over stops the original source VM in your migration source, so you must start it and redirect traffic back to the source VM.
If necessary, copy new data created on the Compute Engine instance so that you can write it to the source VM.
(Optional) delete or shutdown the Compute Engine instance running the migrated VM.
Resume replication on the source VM. Replication resumes from the last snapshot taken.
Retry cut-over.
Step 6: Finalize a migration
The replication data used to create a Compute Engine VM is retained after cut-over to allow you to resume replication from the last replication snapshot.
However, you are charged for the storage used by the replication data until you delete it in the finalize phase. Finalizing deletes all replication data and all other storage resources associated with a migrated VM.
The Finalize phase does not delete Compute Engine instances running a migrated VM. If you created Compute Engine instances during the testing phase, you must manually delete them. You will be charged for those test-clone instances until they are deleted.
To finalize a migration, follow these steps:
Open the Migrate to Virtual Machines page in the Google Cloud console:
Select the Migrations tab.
A table of available source VMs appears. Finalize can be performed only on VMs in the Cut-Over state.
Select a source VM.
Select Finalize and then confirm the finalize.
After finalize completes, the state of the VM is set to Finalized. The only allowed operations on a migration in the Finalized state are:
- Delete the migration
- Add to or remove from a group
Delete a migration
Deleting a migration removes:
- The replication data for the VM stored on Google Cloud
- The Compute Engine configuration information
- The monitoring history
- All other data associated with migrating a VM
- The VM from the list of onboarded VMs on the Migrations tab
- The VM from its group, if the VM is a member of a group
However, deleting a migration does not remove the source VM from the list of available VMs for the migration source displayed on the Sources tab. That is, only the migration data for the VM is deleted. The original source VM itself is not affected when you delete a migration.That means you can later onboard the source VM again to migrate it.
To delete a migration, follow these steps:
Open the Migrate to Virtual Machines page in the Google Cloud console:
Select the Migrations tab.
Select a source VM.
Select Delete and then confirm the deletion.
The VM is removed from the Migration table.
Select the Sources tab.
From the drop-down list, select the migration source that you want to delete.
A table appears showing the source VMs in the migration source available for migration. Notice that the source VM corresponding to the deleted migration is still listed.
If necessary, you can restart a migration on the VM.