Migrate to Virtual Machines lets you migrate disks from source virtual machine (VM)instances to Persistent Disk volumes on Google Cloud, with minimalinterruptions to the workload. You can also create a new VM instance and attachthe migrated Persistent Disk volumes to it.

Migration process

The following are the steps of the disk migration process:

1. Onboard: Select the VM whose disks you want to migrate.

2. Replicate: Replicate data from the disks of the source VM to Persistent Disk volumes on Google Cloud. Data replication is a continuous process that takes place in the background until the final cut-over or you deleting the migration.

3. Set VM target details: Configure settings for the migrated Persistent Disk volumes. If you choose to create a new VM instance to attach the Persistent Disk volumes to, you must configure the setting for the VM instance as well.

4. Clone disks to target: Create a clone of the source VM's disk based on target details.

5. Cut-over disks to target: Migrate disks from the source VM. This process includes stopping the source VM and performing a final replication of the disks.

6. Finalize: Clean up all resources consumed by the migration following a successful cut-over operation.

The disk migration process follows the same steps as the VM migrationprocess. Therefore, you can choose to switch from VM migration to disk migrationand the other way around at any point during the migration process. For moreinformation, seeSwitch from disk migration to VM migration.

Note: You can migrate your VM's boot disk as a data disk using the disk migrationprocess in cases where OS adaptation is not needed. If you want to migratethe boot disk with the OS (to be able to use it as a boot disk), thenVM migration is more suitable.

Prerequisites

Perform the following steps to configure the migration environment on yourmigration sourceandmigration target.

• Enable Migrate to Virtual Machines services.
• (Only for VMware VM migration)Install the Migrate Connector.

Step 1: Onboard a VM

Disk migration is performed at the VM level, and so the first phase of migrationis to onboard the source VM. For example, a vSphere data center might containmany VMs. Onboard only the VMs whose disks you want to migrate.

You can have up to 200 migrations in progress at a time (excluding migrationsin the Finalize phase), per host project and region. The limitation is formigrating disks from VMs of all source types. For example, you can migrate disksattached to 100 VMs from a VMware source and 100 additional VMs from AWS at thesame time.

To onboard a source VM, follow these steps:

1. Open the Migrate to Virtual Machines page in the Google Cloud console:

   Go to the Migrate to Virtual Machines page

2. Select theSources tab.

3. From the drop-down list, select the migration source from which you want tomigrate disks.

   Below the drop-down you see theSource status of the migration source asfollows:

   • 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 havenot configured the migration source properly. Review the steps for yoursetting your migration source and try again.

4. A table appears showing the source VMs in the migration source available formigration. Select one or more source VMs.

   TheVM Power Status column shows the status asSuspended,On, orOff. You can migrate a VM with any of these statuses.

5. ClickAdd Migrations >Disk Migration.

6. Confirm that you want to create the migration.

   After you create a migration, theReplication status columnfor 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 VM 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 VMto Google Cloud.This process takes place in the background with no disruption to the workload.

Data replication is comprised of two steps, follow these steps:

1. First replication step: Migrate to Virtual Machines creates the initialsnapshot of the source VM data disks and replicates the snapshot data toGoogle Cloud. Depending on the amount of disk data on the source VM,the first replication can take minutes or hours to complete.

   TheReplication status column of a VM on the first replication stepdisplays theFirst sync status followed by the appropriate sub-step.

2. Incremental replication step: Following a successful first replicationstep, incremental replication steps occur at set time intervals (every twohours 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 toGoogle Cloud using the Change Block Tracking (CBT) mechanism.

   TheReplication status column of a VM on an incremental replication stepdisplays theActive status followed by the appropriate sub-step.

Initiate replication of a source VM

To initiate replication of a source VM, follow these steps:

1. Open the Migrate to Virtual Machines page in the Google Cloud console:

   Go to the Migrate to Virtual Machines page

2. Select theVM Disk Migrations tab.

   A table appears showing the source VMs along with the disks attached to eachVM. You can start replication of the disks on any VM with the replicationstatusReady.

   Note: Replications are performed at the VM-level. When you replicate a VM,all the disks on the VM are replicated. You cannot select individual disks ona VM to replicate. However, you can select individual disks to create in atest-clone or cut-over phases.

3. Select one or more source VMs.

4. ClickMigration > Start Replication. TheReplication status columnshows replication status along with one of the sub-steps detailed in thereplication cycle sub-steps table.

   To view the replication history of a VM, click the VM to open the detailspage. ClickReplication History to view the replication history of the VMalong with thesub-steps of the replication.

   Migrate to Virtual Machines saves and displays up to 100 cycles ofreplication history for a VM.

5. You can nowconfigure a migration target for thetest-clone and cut-over phases.

You can create a test-clone of a disk at any time after the first replication stepcompletes. Replication continues until you explicitly end it during the cut-overphase.

Pause replication

At any time, you can pause replication for a VM. When you pause replication fora VM, itsReplication status changes toPaused.

To pause replication, follow these steps:

1. Open the Migrate to Virtual Machines page in the Google Cloud console:

   Go to the Migrate to Virtual Machines page

2. Select theVM Disk Migrations tab.

   A table of available source VMs appears.

3. Select one or more VMs.

4. SelectPause.

   To later resume replication, select one or more VMs and then selectResume.

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 every2 hours. To set the replication interval, perform the following steps:

1. Open the Migrate to Virtual Machines page in the Google Cloud console:

   Go to the Migrate to Virtual Machines page

2. Select theVM Disk Migrations tab.

   A table of available source VMs appears.

3. For the VM, select theEdit Target Details button. A panel opens to letyou configure the target.

4. Select theTarget Details tab.

5. In theReplication policy area, set the replication frequency, in seconds.

6. SelectSave.

To set the frequency for multiple VMs, select the VMs and then select theEdit Target Details button. A panel opens to let you configure thereplication frequency of the selected VMs.

Switch from disk migration to VM migration

You can switch between disk migration and VM migration at any time during themigration process. To switch from disk migration to VM migration, follow thesesteps:

1. Open the Migrate to Virtual Machines page in the Google Cloud console:

   Go to the Migrate to Virtual Machines page

2. Select theVM Disk Migrations tab.

3. Select one or more VMs.

4. ClickMigration > Convert to VM migration.

Switching from disk migration to VM migration clears out the target details.This is because the target details for disk migration and VM migration aredifferent. However, the replication progress isn't lost during the switch.

You must update the target details before you clone or cut-overoperations on your VM in order for the migration to succeed. For moreinformation, seeConfiguring the target.

Step 3: Configure the target for a migrated VM disk

Migrate to Virtual Machines lets you migrate the disks of a source VM to Persistent Diskvolumes on Google Cloud with the following options:

• Migrate the disks to Persistent Disk volumes

• Migrate the disks to Persistent Disk volumes and attach them to a new VM instance

You must configure the target details such as project, zone, disk type, and morebased on the option you choose. The target project is the project that containsthe Persistent Disk volumes migrated from the source VM, or the newly created VMinstance to which you want to attach the migrated Persistent Disk volumes. You canmodify the target details at any time. When you create a test-clone or cut-over,Migrate to Virtual Machines uses the target details settings at the time of theoperation.

Thehost projectis automatically added as a target project so there is no need to explicitly addit. If you want to add an additional project as a target project, seeAdding a target project.

To configure the Persistent Disk target, follow these steps:

1. If you have not done so already, add the target project as shown inAdding a target.

2. Open the Migrate to Virtual Machines page in the Google Cloud console:

   Go to the Migrate to Virtual Machines page

3. Select theVM Disk Migrations tab.

   A table of migrations appears.

4. Select a source VM (you can select multiple VMs to edit) and clickEdit target details. On the panel that appears, configure the targetdetails for all of your selected VMs.

5. Set theTarget details that define the characteristics of the Persistent Diskvolumes to which you want to migrate your data. The following table lists thosesettings in detail.

   Section title	Field name	Description
   General	Project	The name of the project hosting the Persistent Disk volumes. It must be a project you have already added earlier in this section.
   	Zone	Zone for the Persistent Disk volumes. See Regions and Zones.
   Disk Configuration	Name	Enter a name for the disk.
   	Disk Type	Select the type of Persistent Disk. SeePersistent Disk types.
   	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. Note: If you've set an encryption key for your source, the same encryption key will be used here. If you've not set a key for the source, then you can't select any encryption type.
   	Labels	To organize your project, add labels as key/value pairs to your resources.SeeLabeling resources.
   Attach to a VM	Attach disks to VM	SelectDon't attach to a VM if you don't want to attachthe Persistent Disk volumes to a VM instance. SelectCreate a VM from a disk image if you want to create aVM instance and attach the Persistent Disk volumes to it. If you choose thisoption, you must set the target details that define the attributes of the newVM instance to which you want to attach the migrated Persistent Disk volumes. Formore information on these settings, seeConfigure the target for a VM.
   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). Note: The replication cycle idle time counter starts after the previous replication cycle ends.

6. ClickSave.

(Optional) Step 4: Test a clone of a migrating disk

In the test-clone phase, you can check if the Persistent Disk volumes created duringthe replication phase are functioning as expected. For example, you can attachthe migrated Persistent Disk volumes to a Compute Engine instance in your targetenvironment to check if the disks are working as expected.

If you have created a new VM instance and attached the migrated Persistent Diskvolumes to it, Migrate to Virtual Machines deploys a clone of the VM instance to aCompute Engine instance in your target environment to test it. While thetesting phase is optional, it is best practice to perform testing before youperform a cut-over to the migrated disk.

Each time you create a test-clone instance, it is cloned from the most recentlycompleted replication cycle data using the current target details. In otherwords, a test-clone instance represents asnapshot of the source VM at thetime of the last completed replication cycle.

Caution: New replication data and modifications to the target details are onlyapplied tonew test-clones, not to existing test-clones.

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 atarget environment for the Persistent Disk volumes or the new VM instance to whichyou want to attach the migrated Persistent Disk volumes. For more information,seeConfiguring the target.

You can only test a VM in thePaused state if it has completed at leastone replication.

For more information on potential issues during the test-clone phase, seetheTroubleshooting section.

Create a test-clone of the disks of a VM

To create a test-clone of the disks of a VM using Migrate to Virtual Machines, usethe following steps:

1. Verify that you have configured a testing target environment as described inConfiguring VM target.

   Note: You can only test-clone a disk with a valid target environment.

2. Open the Migrate to Virtual Machines page in the Google Cloud console:

   Go to the Migrate to Virtual Machines page

3. Select theVM Disk Migrations tab.

   A table of available source VMs appears. You can test any VM that is in theActive (Current cycle: XX%) orActive (Idle) state. TheActivestate means the first replication sync of the VM succeeded and VM data isbeing incrementally replicated.

4. Select a VM.

5. SelectCut-Over and Test-Clone > Test-Clone. TheTest-Clone/Cut-Over statuscolumn shows the status of the operation along with one of the sub-stepsdetailed in thetest-clone sub-steps table.

6. Wait for theTest-Clone/Cut-Over status column to showSucceeded. Thisindicates that the clone was created successfully.

   You can view the test-clone history of a VM in one of the following ways:

   • Click theInfo panel icon, for the VM. On the panel that opens from the right, theMonitoring tab displays the history, including the name of eachtest-clone instance.

   • Click the VM to open the details page. ClickTest-Clone/Cut-Over Historyto view the test-clone history of the VM along with thesub-steps of the test-clone.

   You can cancel an active test-clone operation by clickingCut-Over and Test-Clone >Cancel Test-Clone.

7. You can now create any VM and attach the test-clone disks to it tocheck if the migrated disks are working as expected.

8. After you have completed testing, delete the VM instance to free up resourcesso that you are no longer 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 thefollowing:

• Modifications you make to your source VM to support migration
• Modifications you make to the target details
• 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 asnapshot of the source VM created from thecurrent replication data and target details. New replication data and modificationsto the target details are only applied tonew test-clones, not to existingtest-clones.

If you have an existing test-clone instance running, then before you create anew test-clone you can either:

• Delete the existing test-clone instance and create a new one with the sameinstance name. You cannot create a new instance with the same name as anexisting instance.

• Edit the target details to set new unique names for the disks.

To monitor all test-clone instances, follow these steps:

1. View the test-clone history of a VM in one of the following ways:

   • Click theInfo panel icon, for the VM. On the panel that opens from theright, theMonitoring tab displays the history, including the name ofeach test-clone instance.

   • Click the VM to open the details page. ClickTest-Clone/Cut-Over Historyto view the test-clone history of the VM along with thesub-steps of the test-clone.

   After you create a test-clone, it is up to you to manage it. If you want tomodify or delete a running test-clone disk or the VM instance you created totest the disk, you must use the respective product's tools. You cannot managethese resources using Migrate to Virtual Machines tools.

Step 5: Create a cut-over

In the cut-over phase, you transfer control to your migrated disk, or the new VMyou created with the migrated Persistent Disk volumes attached to it, in your targetenvironment on Google Cloud.

The cut-over process, follow these steps:

1. If data replication is active, that is, theReplication statusof the VM isActive (Current cycle: XX%), waits for it to complete.

   Note: To perform cut-over, replication cannot be paused.

2. Shuts down the source VM.

3. Performs the final data replication. Because replication occurs throughoutall migration phases, the amount of data to replicate shouldn't be very large.

4. Stops replication.

5. Creates the Persistent Disk volumes from the final replicated data.

   Note: You must have already configured the Persistent Disk target detailsbefore you can initiate a cut-over. For more information, seeConfiguring the target.

The cut-over phase includes a short VM downtime and should take place during ascheduled maintenance window. You must determine the maintenance window duringwhich you can stop the source VM and redirect traffic to the migrated disk.

Create a cut-over

To create a cut-over, perform the following steps:

1. Verify that you have configured the target details as described inConfiguring VM target. If the target details werepreviously configured for test-clone operation, you might want to edit thetarget details to point to a new target.

   Note: You can only cut-over a VM with a valid target environment.

2. Open the Migrate to Virtual Machines page in the Google Cloud console.

   Go to the Migrate to Virtual Machines page

3. Select theVM Disk Migrations tab.

   A table of available source VMs appears. You can cut-over any VM that is intheActive (Current cycle: XX%) orActive (Idle) state. TheActivestate means the first replication sync of the VM succeeded and VM data isbeing incrementally replicated.

   • TheEstimated cut-over time column shows an estimate of the time ittakes 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 fewreplication cycles.

   • TheTest-Clone/Cut-Over status column shows the status of the operationalong with one of the sub-steps detailed in thecut-over sub-steps table.

4. Select a source VM.

5. SelectCut-Over and Test-Clone > Cut-Over. Initiating a cut-over on aVM starts the following sequence of actions performed by Migrate to Virtual Machines:

   1. Shuts down the source VM.

   2. Performs the final data replication. Because continuous replication occursthroughout all migration phases, the amount of data to replicate shouldn'tbe very large.

   3. Creates the Persistent Disk volumes hosting the migrated VM from the finalreplicated data.

   4. Stops data replication.

6. Wait for theTest-Clone/Cut-Over status column to showCut-over jobcompleted. This indicates that the cut-over succeeded.

   You can view the cut-over history of a VM in one of the following ways:

   • Click theInfo panel icon,, for the VM. On the panel that opens from the right, theMonitoring tab displays the history, including the name of eachcut-over instance.

   • Click the VM to open the details page. ClickTest-Clone/Cut-Over Historyto view the cut-over history of the VM along with thesub-steps of the cut-over.

   You can cancel an active cut-over operation by clickingCut-Over and Test-Clone > Cancel Cut-Over.However, if you want to resume use of the source VM, you must manually restartthe VM.

7. Perform validation test on the migrated disks.

Retry cut-over

If for any reason you want to retry cut-over, follow these steps:

1. Select a VM in theCut-Over state.

2. SelectMigration > Resume Replication.

3. Retry cut-over.

Roll back from the cut-over

To rollback from cut-over, follow these steps:

1. Cut-over stops the original source VM in your migration source, so you muststart it and redirect traffic back to the source VM.

2. If necessary, copy new data created on the Persistent Disk volumes so that youcan write it to the source VM.

3. (Optional) Delete Persistent Disk volumes.

4. Resume replication on the source VM. Replication resumesfrom the last snapshot taken.

5. Retry cut-over.

Step 6: Finalize a migration

The replication data used to create Persistent Disk volumes is retained after cut-overto 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 itin the finalize phase. Finalizing deletes all replication data and storageresources.

The Finalize phase does not delete Persistent Disk volumes. If you createdPersistent Disk volumes during the testing phase, you must manually delete them. Youare charged for those test-clone Persistent Disk volumes until they are deleted.

To finalize a migration, follow these steps:

1. Open the Migrate to Virtual Machines page in the Google Cloud console:

   Go to the Migrate to Virtual Machines page

2. Select theVM Disk Migrations tab.

   A table of available source VMs appears. Finalize can be performed only on VMsin theCut-Over state.

3. Select a source VM.

4. ClickFinalize and then confirm the finalize.

   After finalize phase completes, the state of the VM is set toFinalized.The only allowed operations on a migration in theFinalized state are:

   • Delete the migration
   • Add to or remove from a group

Delete a migration

Deleting a migration removes the following:

• The replication data for the VM stored on Google Cloud
• The Persistent Disk configuration information
• The monitoring history
• All other data associated with migrating a disk
• The VM from the list of onboarded VMs on theVM Disk 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 ofavailable VMs for the migration source displayed on theSources tab. That is,only the migration data for the VM is deleted. The original source VM itself isnot affected when you delete a migration.That means you can later onboard thesource VM again to migrate it.

To delete a migration, follow these steps:

1. Open the Migrate to Virtual Machines page in the Google Cloud console:

   Go to the Migrate to Virtual Machines page

2. Select theVM Disk Migrations tab.

3. Select a source VM.

4. ClickDelete and then confirm the deletion.

   The VM is removed from the Migration table.

5. Select theSources tab.

6. From the drop-down list, select the migration source that you want to delete.

7. A table appears showing the source VMs in the migration source available formigration. Notice that the source VM corresponding to the deleted migrationis still listed.

If necessary, you can restart a disk migration on the VM.