Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Práticas recomendadas de migração
Esta página apresenta algumas práticas recomendadas para migrar instâncias de máquina virtual (VM) do VMware
para sua nuvem privada usando o Google Cloud VMware Engine.
Planejar o projeto de migração
Antes de migrar as VMs do VMware para a nuvem privada, planeje a migração da seguinte maneira:
Identifique o pessoal, incluindo o seguinte:
Partes interessadas do cliente
Patrocinador e proprietário do programa
A equipe técnica responsável pela migração
As partes interessadas dos sistemas e aplicativos no escopo
O gerente técnico de contas (TAM), gerente de engenharia de parceiros (PEM, na sigla em inglês) ou engenheiro de clientes (CE) relevante do Google
as metas e os critérios de sucesso, incluindo os scripts de UAT e de controle de qualidade
as funções e responsabilidades
o modelo de comunicação, incluindo reuniões diárias, relatórios de status,
caminho de encaminhamento e salas de chat
os dados que não podem ser migrados e as estratégias relacionadas
marcos e horários
Garanta o alinhamento com todas as partes interessadas.
Avaliar as opções de migração
Para avaliar as diferentes opções de migração para o VMware Engine,
considere as seguintes opções:
Considere planejar a migração em ondas.
Considere as dependências e os mapeamentos do aplicativo.
Agrupar VMs com base na programação de manutenção.
Para evitar vários ciclos de energia, identifique as VMs com atualizações
do sistema pendentes e alinhe a programação com as reinicializações de migração.
Verifique se o vSphere, o vCenter, o HCX e, se aplicável, o NSX-T local
atendem à compatibilidade mínima de versionamento com as
versões do componente do VMware Engine.
Identifique VMs com requisitos de memória, CPU ou armazenamento que excedam a
especificação do tipo de nó atual ou que possam causar conflito se
forem combinadas com outras VMs grandes.
Por exemplo, servidores de banco de dados podem exigir grandes quantidades de memória, ou
servidores de armazenamento de arquivos podem exigir grandes repositórios de dados.
Desenvolva estratégias de pré-migração e pós-migração para conteúdo que não pode ser
migrado devido a hardware ou marcação persistente, como ISOs montadas, tags do NSX-T,
dispositivos de passagem que usam
E/S do DirectPath,
discos multigravador
e RDMs físicos. Um exemplo de estratégia é converter
RDMs físicas para o
modo de compatibilidade virtual.
Embora uma topologia de rede plana tenha suporte para implantações do HCX Connector e do HCX
Service Mesh, para evitar problemas de roteamento e erros de conectividade, configure o HCX Management e os perfis de rede do HCX Uplink
em redes e VLANs separadas.
A equipe de SRE gerencia os backups do HCX Manager, mas não os do HCX Connector.
Os dispositivos de serviço do HCX, incluindo o HCX-IX e o HCX-NE, não exigem
backups individuais. Um HCX Manager restaurado se reconecta aos dispositivos de serviço
existentes que foram criados durante a duração do backup. Se os appliances
de serviço não estiverem mais funcionais, o HCX Manager implantará novas VMs
de appliance com base na configuração de backup.
Para VMs que se comunicam de ou para uma nuvem privada por uma extensão HCX L2, configure a melhor configuração de MTU com base nas configurações de endpoint da VPN. Isso é especialmente importante nos casos em que um aplicativo
não pode controlar o tamanho máximo do payload.
O Google recomenda uma configuração de MTU de 1.350 a 1.390 bytes ou menos para interfaces de VM
que permitem a transferência de dados das seguintes maneiras:
De um endpoint local para uma nuvem privada e vice-versa
De uma VM em uma nuvem particular para uma VM em outra nuvem particular por uma
extensão L2
Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas
sobre Google Cloud. Acesse o Centro de arquitetura do Cloud para
mais informações.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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."]]
