Erstellen Sie einen Plan, in dem Folgendes definiert ist:
die Migrationsstrategie
die Architektur der neuen Umgebung
die Ziele und Erfolgskriterien, einschließlich der UAT- und QA-Scripts
die Rollen und Verantwortlichkeiten
das Kommunikationsmodell, einschließlich täglicher Stand-ups, Statusberichte, Eskalationspfade, Chatrooms
die Daten, die nicht migriert werden können, und die zugehörigen Strategien
Meilensteine und Zeitplan
Achten Sie darauf, dass alle Stakeholder einverstanden sind.
Migrationsoptionen bewerten
Bei der Bewertung der verschiedenen Migrationsoptionen für die VMware Engine sollten Sie die folgenden Optionen berücksichtigen:
Sie können die Migration in mehreren Schritten planen.
Berücksichtigen Sie Anwendungsabhängigkeiten und ‑zuordnungen.
Gruppieren Sie VMs basierend auf ihrem Wartungszeitplan.
Um mehrere Aus- und Einschaltvorgänge zu vermeiden, identifizieren Sie die VMs mit ausstehenden Systemupdates und richten Sie den Zeitplan an den Neustarts für den Migrationsübergang aus.
Achten Sie darauf, dass vSphere, vCenter, HCX und gegebenenfalls NSX-T on-premises die Mindestversionskompatibilität mit den VMware Engine-Komponentenversionen erfüllen.
Identifizieren Sie VMs mit Arbeitsspeicher-, CPU- oder Speicheranforderungen, die die Spezifikation des aktuellen Knotentyps überschreiten oder die bei Kombination mit anderen großen VMs zu Konflikten führen können.
So können Datenbankserver beispielsweise große Mengen an Arbeitsspeicher erfordern oder Dateispeicherserver große Datenspeicher.
Entwickeln Sie Strategien vor und nach der Migration für Inhalte, die aufgrund von persistenter Hardware oder Tagging nicht migriert werden können, z. B. bereitgestellte ISOs, NSX-T-Tags, Passthrough-Geräte, die DirectPath-I/O verwenden, Festplatten mit mehreren Schreibzugriffen und physische RDMs. Eine mögliche Strategie wäre die Umwandlung physischer RDMs in den virtuellen Kompatibilitätsmodus.
Verwenden Sie die Bulk-Migration.
Beachten Sie die entsprechenden Anforderungen und Einschränkungen.
VMware HCX für Migrationen verwenden
Beachten Sie bei der Verwendung von HCX für die Migration die folgenden Empfehlungen:
Für HCX Connector- und HCX Service Mesh-Bereitstellungen wird zwar eine flache Netzwerktopologie unterstützt, um Routingprobleme und Verbindungsfehler zu vermeiden, sollten Sie jedoch HCX Management und die Netzwerkprofile für den HCX-Uplink in separaten Netzwerken und VLANs einrichten.
Achten Sie darauf, dass in Ihrer VMware-Umgebung die neuesten HCX-Versionen installiert sind. Weitere Informationen finden Sie unter HCX-Dienstaktualisierungsverfahren.
Das SRE-Team verwaltet HCX Manager-Sicherungen, aber keine HCX Connector-Sicherungen.
Für HCX-Service-Appliances wie HCX-IX und HCX-NE sind keine individuellen Sicherungen erforderlich. Ein wiederhergestellter HCX Manager stellt eine Verbindung zu vorhandenen Service-Appliances her, die innerhalb der Sicherungsdauer erstellt wurden. Wenn die Dienst-Appliances nicht mehr funktionieren, stellt der HCX Manager anhand der gesicherten Konfiguration neue Appliance-VMs bereit.
Wenn Sie ein Layer 2-Netzwerk mit HCX-Netzwerkerweiterungen erweitern, aktivieren Sie die TCP-Flow-Bedingung. Weitere Informationen finden Sie unter In HCX verfügbare Traffic-Engineering-Funktionen.
Konfigurieren Sie für VMs, die über eine HCX-L2-Erweiterung mit oder von einer privaten Cloud kommunizieren, die beste MTU-Einstellung auf der Grundlage von VPN-Endpunktkonfigurationen. Dies ist besonders wichtig, wenn eine Anwendung die maximale Nutzlastgröße nicht steuern kann.
Google empfiehlt eine MTU-Einstellung von 1.350 Byte bis 1.390 Byte oder weniger für VM-Schnittstellen, die die Datenübertragung auf folgende Weise ermöglichen:
Von einem lokalen Endpunkt zu einer privaten Cloud und umgekehrt
Von einer VM in einer privaten Cloud zu einer VM in einer anderen privaten Cloud über eine L2-Erweiterung
Referenzarchitekturen, Diagramme, Anleitungen und Best Practices zu Google Cloudkennenlernen Weitere Informationen finden Sie im Cloud Architecture Center.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[],[],null,["# Migration best practices\n========================\n\nThis page presents some best practices for migrating VMware virtual machine (VM)\ninstances to your private cloud by using Google Cloud VMware Engine.\n\nPlan the migration project\n--------------------------\n\nBefore migrating VMware VMs to your private cloud, plan the migration as follows:\n\n- Identify the personnel, including the following:\n\n - Customer stakeholders\n - Program sponsor and owner\n - The technical team responsible for the migration\n - The stakeholders for in-scope systems and applications\n - The relevant Google Technical Account Manager (TAM), Partner Engineering Manager (PEM), or Customer Engineer (CE)\n- Assess the [source environment](/vmware-engine/docs/workloads/classic-console/howto-migrate-workloads#assess_the_source_environment).\n\n- Create a plan that defines the following:\n\n - the migration strategy\n - the architecture of the new environment\n - the goals and success criteria, including the UAT and QA scripts\n - the roles and responsibilities\n - the communication model, including daily standups, status reporting, escalation paths, chat rooms\n - the data that cannot be migrated and related strategies\n - milestones and timings\n- Ensure alignment with all stakeholders.\n\nEvaluate migration options\n--------------------------\n\nTo evaluate the different migration options for VMware Engine,\nconsider the following options:\n\n- Consider planning the migration in waves.\n\n - Factor in application dependencies and mappings.\n - Group VMs based on their maintenance schedule.\n - To avoid multiple power cycles, identify the VMs with pending system updates and align the schedule with the migration switchover reboots.\n- Establish a backup and DR strategy for VMs. Consider using\n [Google Cloud Backup and DR](/backup-disaster-recovery/docs) and\n [VMware Engine Protected](/vmware-engine/docs/concepts-vmware-engine-protected).\n\n- Ensure that vSphere, vCenter, HCX, and, if applicable, NSX-T on-premises\n meet the minimum versioning compatibility with\n [VMware Engine component versions](/vmware-engine/docs/concepts-vmware-components#vmware_component_versions).\n\n- Identify VMs with memory, CPU, or storage requirements that exceed the\n specification of the current node type or that might cause contention if\n combined with other large VMs.\n\n For example, database servers might require large amounts of memory or\n file storage servers might require large datastores.\n- Develop pre- and post-migration strategies for content that cannot be\n migrated due to persistent hardware or tagging, such as mounted ISOs, NSX-T\n tags, passthrough devices that use\n [DirectPath I/O](https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-networking/GUID-BF2770C3-39ED-4BC5-A8EF-77D55EFE924C.html),\n [multi-writer disks](https://core.vmware.com/blog/migrating-vms-shared-or-multi-writer-disks),\n and physical RDMs. An example strategy might be to consider converting\n physical RDMs to\n [virtual compatibility mode](https://knowledge.broadcom.com/external/article?legacyId=1006599).\n\n- Assess and evaluate [migration methods](https://docs.vmware.com/en/VMware-HCX/4.9/hcx-user-guide/GUID-8A31731C-AA28-4714-9C23-D9E924DBB666.html).\n\n Prefer [bulk migration](https://docs.vmware.com/en/VMware-HCX/4.9/hcx-user-guide/GUID-20EA2946-57CD-4A87-AE25-866E5336AEA9.html#GUID-20EA2946-57CD-4A87-AE25-866E5336AEA9).\n Consider the related requirements and restrictions.\n\nUse VMware HCX for migrations\n-----------------------------\n\nWhen using [HCX for migration](/vmware-engine/docs/workloads/howto-migrate-vms-using-hcx),\nconsider the following recommendations:\n\n- Although a flat network topology is supported for HCX Connector and HCX\n Service Mesh deployments, to avoid routing problems and connectivity\n errors, set up HCX Management and the HCX Uplink [network profiles](https://docs.vmware.com/en/VMware-HCX/4.9/hcx-getting-started/GUID-AB56D9A9-7E2C-436F-9E20-445E447E300F.html)\n on separate networks and VLANs.\n\n- Ensure that your VMware environment has the latest HCX versions. For more\n information, see\n [HCX Service Update Procedures](https://docs.vmware.com/en/VMware-HCX/4.9/hcx-user-guide/GUID-77111C61-EC4C-4C8C-8340-5828CC4D489D.html).\n\n- Be sure to configure\n [HCX backups and restore operations](https://docs.vmware.com/en/VMware-HCX/4.9/hcx-user-guide/GUID-50C416BC-5415-42AB-AA7A-3A5CB46A60C7.html),\n as required.\n\n The SRE team manages HCX Manager backups, but not HCX Connector backups.\n\n HCX service appliances, including HCX-IX and HCX-NE, don't require\n individual backups. A restored HCX Manager reconnects to existing service\n appliances that were created within the backup duration. If the service\n appliances are no longer functional, the HCX Manager deploys new appliance\n VMs based on the backed-up configuration.\n- When stretching a Layer 2 network by using HCX network extensions, enable\n TCP Flow Conditioning. For related information, see\n [Traffic engineering features provided in HCX](https://blogs.vmware.com/cloud/2020/01/16/traffic-engineering-hcx-enterprise/).\n\n- For VMs that communicate to or from a private cloud over an HCX L2\n extension, configure the best MTU setting based on VPN endpoint\n configurations. This is especially important in cases where an application\n isn't able to control the maximum payload size.\n\n Google recommends an MTU setting of 1350 bytes to 1390 bytes or lower for VM\n interfaces that allow data transfer in the following ways:\n - From an on-premises endpoint to a private cloud and conversely\n - From a VM in one private cloud to a VM in another private cloud over an L2 extension\n\n For additional guidance on calculating encapsulation overhead, see\n [MTU considerations](/network-connectivity/docs/vpn/concepts/mtu-considerations)\n and [VMware NSX-T VPNs](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.0/administration/GUID-A8B113EC-3D53-41A5-919E-78F1A3705F58.html).\n\nWhat's next\n-----------\n\n- Read about best practices for [compute](/vmware-engine/docs/best-practices-compute), [networking](/vmware-engine/docs/best-practices-networking), [security](/vmware-engine/docs/best-practices-security), [storage](/vmware-engine/docs/best-practices-storage), and [costs](/vmware-engine/docs/best-practices-costs).\n- Try out VMware Engine. Visit [features, benefits, and use\n cases](/vmware-engine/docs/overview) for more information.\n- Explore reference architectures, diagrams, tutorials, and best practices about Google Cloud. Visit [Cloud Architecture Center](/architecture) for more information."]]
