You are now viewing Migrate to Virtual Machines (formerly Migrate for Compute Engine). For Migrate for Compute Engine versions 4.x, see the 4.x documentation.

Troubleshoot Migrate to Virtual Machines

Learn about troubleshooting steps that you might find helpful if you run into problems using Migrate to Virtual Machines.

Error: Required compute.subnetworks.use permission

A Shared VPC allows an organization to connect resources from multiple projects to a common Virtual Private Cloud (VPC) network, so that they can communicate with each other securely and efficiently using internal IPs from that network.

Migrate to Virtual Machines lets you deploy a Compute Engine instance to a project that has access to a Shared VPC. However, if you have not assigned the compute.subnetworks.use role to the Migrate to Virtual Machines default service account, you see an error message in the following format when you try to deploy the Compute Engine instance:

"Create instance of VM "my-vm" from source "my-proj" to target project "target-proj" using Compute Engine instance name "instance-id" failed due to: Required 'compute.subnetworks.use' permission for 'projects/vpc-proj/regions/us-central1/subnetworks/shared-central1'

Ensure that you assign the compute.subnetworks.use role on the Shared VPC host project to the Migrate to Virtual Machines default service account as described in Configuring permissions for a Shared VPC.

Error: The user does not have access to service account

As part of Configuring the target for a migrated VM, Migrate to Virtual Machines lets you assign a service account to a Compute Engine instance running on a target project.

However, to be able to assign a service account to a Compute Engine instance running on a target project, the default Migrate to Virtual Machines service account on the host project must have the Service Account User role on the target service account.

If you assign a service account to a Compute Engine instance, but the host project does not have the Service Account User role on the target service account, then you see the following error when you try to test-clone or cut-over the VM:

Test-Clone of VM "my-vm" from source "source-vm" to target project "target-proj" using Compute Engine instance name "my-instance" failed due to: The user does not have access to service account 'target-service-account-email'. User: 'host-user-account-email'. Ask a project owner to grant you the iam.serviceAccountUser role on the service account

Ensure that the default Migrate to Virtual Machines service account is configured correctly to allow access to the target service account. See Configuring permissions on target project service account for more.

Error: Report generation failed due to vCenter maximum query limit exceeded

To help you determine the optimal settings for the Compute Engine target, Migrate to Virtual Machines lets you create a source VM utilization report. This report displays information about resource allocation and utilization for the source VMs deployed on vCenter.

The report is generated from data collected on vCenter. When generating the report, you might see an error in the following format indicating that a vCenter quota limit has been reached:

Report generation for source source connected to vCenter vcenter failed due to vCenter maximum query limit exceeded. Details: VC message

See this vSphere article for more information on increasing the quota limit.

Error: Instance created in Migrate to Virtual Machines is not booting

When your source VM boot disk isn't the first disk on your VM's list of disks, you may receive a serial console error that shows the following message:

drive 0x000f2410: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=104857600
drive 0x000f23d0: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=167772160
drive 0x000f2390: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=83886080
Sending Seabios boot VM event.
Booting from Hard Disk 0...

In order to mitigate this error, clone your disks and connect those clones in the correct order to a new VM on Migrate to Virtual Machines.

To clone your disk and connect it in the correct order, follow these steps:

Stop your replicated VM.

Clone your original boot disk:

gcloud compute disks create -project=$PROJECT --zone=$ZONE --source-disk=$DISK new-disk-name

Run the following command to reassign the license to your cloned boot disk and add relevant tags (Example with windows2008-r2):

gcloud compute disks create --project=$PROJECT --zone=$ZONE --source-disk=disk created on step #2 --licenses=projects/windows-cloud/global/licenses/windows-server-2008-r2-dc --guest-os-features=VIRTIO_SCSI_MULTIQUEUE,MULTI_IP_SUBNET,WINDOWS new-disk-name

Edit the VM:
1. Detach your current boot disk and attach it on the Additional disks.
2. Remove the original boot disk from the Additional disks.
3. Attach the created disk from Step 3 on the Boot Disk.
4. Save your changes.

After confirming your VM's boot process, you can delete your original boot disk.

Error: Windows VM is running `chkdsk' on the first boot of a clone

The Migrate to Virtual Machines test-clone phase instantiates a clone of the VM in the cloud based off of a snapshot taken while the source VM is running.

In some cases, this may trigger an automatic chkdsk scan operation in Windows VMs while the clone is booting in cloud. If such errors are blocking verification steps, consider shutting the VM down between replication cycles to allow Migrate to Virtual Machines to take a snapshot while the VM is off.

This does not affect the VM when it is cut over, as the VM is shut down as part of the cut-over process before Migrate to Virtual Machines completes the final sync phase.