Error: Required compute.subnetworks.use permission

AShared VPC allows an organization toconnect resources from multiple projects to a commonVirtual Private Cloud (VPC) network, so that they can communicate with each other securelyand efficiently using internal IPs from that network.

Migrate to Virtual Machines lets you deploy a Compute Engine instance to a projectthat has access to a Shared VPC.However, if you have not assigned thecompute.subnetworks.use role to theMigrate 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 thecompute.subnetworks.use role on theShared VPC host project to theMigrate to Virtual Machines default service account as described inConfiguring permissions for a Shared VPC.

Error: The user does not have access to service account

As part ofConfiguring the target for a migrated VM, Migrate to Virtual Machines lets you assign a serviceaccount to a Compute Engine instance running on a target project.

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

If you assign a service account to a Compute Engine instance, but the host projectdoes not have theService 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" totarget 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 theiam.serviceAccountUser role on the service account

Ensure that the default Migrate to Virtual Machines service account is configuredcorrectly to allow access to the target service account.SeeConfiguring 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 asource VM utilization report. This report displays information about resource allocation andutilization 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 limithas been reached:

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

See thisvSphere 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=104857600drive 0x000f23d0: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=167772160drive 0x000f2390: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=83886080Sending Seabios boot VM event.Booting from Hard Disk 0...

In order to mitigate this error, clone your disks and connect thoseclones 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:

1. Stop your replicated VM.

2. Clone your original boot disk:

   gcloudcomputediskscreate-project=$PROJECT--zone=$ZONE--source-disk=$DISKnew-disk-name

3. Run the following command to reassign the license to your cloned boot disk andadd relevant tags (Example withwindows2008-r2):

   gcloudcomputediskscreate--project=$PROJECT--zone=$ZONE--source-disk=diskcreatedonstep#2 --licenses=projects/windows-cloud/global/licenses/windows-server-2008-r2-dc --guest-os-features=VIRTIO_SCSI_MULTIQUEUE,MULTI_IP_SUBNET,WINDOWSnew-disk-name

4. Edit the VM:

   1. Detach your current boot disk and attach it on theAdditional disks.
   2. Remove the original boot disk from theAdditional disks.
   3. Attach the created disk fromStep 3 on theBoot 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 inthe cloud based off of a snapshot taken while the source VM is running.

In some cases, this may trigger an automaticchkdsk scan operation in WindowsVMs while the clone is booting in cloud. If such errors are blocking verificationsteps, consider shutting the VM down between replication cycles to allowMigrate 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 downas part of the cut-over process before Migrate to Virtual Machines completes thefinal sync phase.