Fehler: Berechtigung „compute.subnetworks.use“ erforderlich
Eine freigegebene VPC (Virtual Private Cloud) ermöglicht einer Organisation, Ressourcen von mehreren Projekten mit einem gemeinsamen VPC-Netzwerk zu verbinden, sodass sie sicher und effizient über interne IP-Adressen dieses Netzwerks miteinander kommunizieren können.
Mit Migrate to Virtual Machines können Sie eine Compute Engine-Instanz in einem Projekt bereitstellen, das Zugriff auf eine freigegebene VPC hat.
Wenn das Migrate to Virtual Machines-Standarddienstkonto allerdings nicht die Rolle compute.subnetworks.use hat, wird bei dem Versuch, die Compute Engine-Instanz bereitzustellen, eine Fehlermeldung im folgenden Format angezeigt:
"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'
Weisen Sie die Rolle compute.subnetworks.use im Hostprojekt der freigegebenen VPC dem Standarddienstkonto von Migrate to Virtual Machines zu, wie unter Berechtigungen für eine freigegebene VPC konfigurieren erläutert.
Fehler: Der Nutzer hat keinen Zugriff auf das Dienstkonto
Bei der Konfiguration des Ziels für eine migrierte VM können Sie mit Migrate to Virtual Machines ein Dienstkonto einer Compute Engine-Instanz zuweisen, die in einem Zielprojekt ausgeführt wird.
Um einer Compute Engine-Instanz, die in einem Zielprojekt ausgeführt wird, ein Dienstkonto zuweisen zu können, muss das Standarddienstkonto von Migrate to Virtual Machines im Hostprojekt aber die Rolle Service Account User für das Zieldienstkonto haben.
Wenn Sie einer Compute Engine-Instanz ein Dienstkonto zuweisen, das Hostprojekt jedoch nicht die Rolle Service Account User für das Zieldienstkonto hat, wird der folgende Fehler angezeigt, wenn Sie versuchen, einen Testklon der VM zu erstellen oder die VM umzustellen:
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
Prüfen Sie, ob das standardmäßige Dienstkonto für die Migrate to Virtual Machines richtig konfiguriert ist, um den Zugriff auf das Zieldienstkonto zu ermöglichen. Weitere Informationen finden Sie unter Berechtigungen für das Dienstkonto des Zielprojekts konfigurieren.
Fehler: Berichterstellung aufgrund Überschreitung von maximalen vCenter-Abfragen fehlgeschlagen
Damit Sie die optimalen Einstellungen für das Compute Engine-Ziel ermitteln können, können Sie mit Migrate to Virtual Machines einen Quell-VM-Nutzungsbericht erstellen. Dieser Bericht enthält Informationen zur Ressourcenzuweisung und -nutzung für die in vCenter bereitgestellten Quell-VMs.
Der Bericht wird aus Daten generiert, die in vCenter erfasst wurden. Beim Erstellen des Berichts wird möglicherweise ein Fehler im folgenden Format angezeigt, der darauf hinweist, dass ein vCenter-Kontingentlimit erreicht wurde:
Report generation for source source connected to vCenter vcenter failed due to vCenter maximum query limit exceeded. Details: VC message
Weitere Informationen zum Erhöhen des Kontingentlimits finden Sie in diesem vSphere-Artikel.
Fehler: Instanz, die in Migrate to Virtual Machines erstellt wurde, wird nicht gebootet
Wenn das Quell-VM-Bootlaufwerk nicht das erste Laufwerk in der Laufwerkliste der VM ist, erhalten Sie möglicherweise einen seriellen Konsolenfehler mit der folgenden Meldung:
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...
Um diesen Fehler zu beheben, klonen Sie Ihre Laufwerke und verbinden Sie diese Klone in der richtigen Reihenfolge mit einer neuen VM auf Migrate to Virtual Machines.
Gehen Sie folgendermaßen vor, um das Laufwerk zu klonen und in der richtigen Reihenfolge zu verbinden:
- Beenden Sie die replizierte VM.
Klonen Sie das ursprüngliche Bootlaufwerk:
gcloud compute disks create -project=$PROJECT --zone=$ZONE --source-disk=$DISK new-disk-nameFühren Sie den folgenden Befehl aus, um die Lizenz Ihrem geklonten Bootlaufwerk neu zuzuweisen und relevante Tags hinzuzufügen (Beispiel mit
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-nameBearbeiten Sie die VM:
- Trennen Sie das aktuelle Bootlaufwerk und hängen Sie es an Zusätzliche Laufwerke an.
- Entfernen Sie das ursprüngliche Bootlaufwerk aus Zusätzliche Laufwerke.
- Hängen Sie das erstellte Laufwerk aus Schritt 3 an das Bootlaufwerk an.
- Speichern Sie die Änderungen.
Nachdem Sie den Bootvorgang Ihrer VM bestätigt haben, können Sie Ihr ursprüngliches Bootlaufwerk löschen.
Fehler: Windows-VM führt „chkdsk“ beim ersten Start eines Klons aus
Die Testklonphase von Migrate to Virtual Machines instanziiert einen Klon der VM in der Cloud basierend auf einem Snapshot, der während der Ausführung der Quell-VM erstellt wurde.
In einigen Fällen kann dies einen automatischen chkdsk-Scanvorgang in Windows-VMs auslösen, während der Klon in der Cloud gestartet wird. Wenn solche Fehler Bestätigungsschritte blockieren, sollten Sie die VM zwischen Replikationszyklen herunterfahren, damit Migrate to Virtual Machines einen Snapshot erstellt, während die VM deaktiviert ist.
Dies wirkt sich nicht auf die VM aus, wenn sie umgestellt wird, da die VM im Rahmen der Umstellung heruntergefahren wird, bevor Migrate to Virtual Machines die letzte Synchronisierungsphase abgeschlossen hat.