Problemas conhecidos
Nesta página, descrevemos os problemas conhecidos que você pode encontrar ao usar o Google Cloud VMware Engine.
Problemas gerais
A seguir, apresentamos problemas gerais conhecidos que afetam o VMware Engine.
Upgrade do HCX Manager marcado incorretamente como upgrade da versão do vSphere
Problema: o upgrade do HCX Manager está marcado incorretamente como um "upgrade da versão do vSphere upgrade" no Google Cloud console.
Detalhes: embora notificações por e-mail específicas que identificam o upgrade do HCX sejam enviadas pelo menos 14 dias e 24 horas antes do evento, as notificações automatizadas "A atualização da sua nuvem privada foi iniciada" e "A atualização da sua nuvem privada foi concluída" refletem uma atualização geral da nuvem privada. Além disso, a Google Cloud interface do console marca explicitamente a operação como um upgrade da versão do vSphere. Essa incompatibilidade pode causar confusão, principalmente para clientes que concluíram recentemente um upgrade de pilha completa (por exemplo, do vSphere 7.x para 8.x), já que parece que o ambiente está passando por outra atualização importante da plataforma.
Alternativa: revise os e-mails de notificação específicos do HCX enviados antes da janela de manutenção para confirmar o escopo do trabalho. Se a programação estiver alinhada, o "status de upgrade da versão do vSphere" no Google Cloud console se refere estritamente à atualização do HCX Manager. Você não precisa fazer nada.
Status: essa é uma limitação conhecida do design atual do sistema de notificação.
Tempo de provisionamento para nuvens privadas da atualização 3 do vSphere 8.0
Problema: o VMware Engine agora implanta novas nuvens privadas com a atualização 3 da versão 8.0 do VMware vSphere e o NSX-T 4.2.1.2. Durante esse período de upgrade, a criação e a expansão de nuvens privadas usam velocidades de provisionamento padrão para todas as novas implantações com as versões atualizadas.
Detalhes: a criação de nuvens privadas pode levar até 140 minutos.
Alternativa: nenhuma alternativa é necessária, mas planeje um tempo extra ao implantar novas nuvens privadas ou expandir clusters atuais.
Detecção: você pode observar tempos de implantação mais longos do que o normal para novas nuvens privadas ou ao expandir clusters atuais.
Status: esse é o comportamento esperado devido às atualizações de versão e aos upgrades em andamento.
Máquina virtual com o Windows Server 2022 KB5022842 (build 20348.1547 do SO) configurada com a inicialização segura ativada, sem inicialização (90947)
Após a instalação do Windows Server 2022, atualize o KB5022842 (build 20348.1547 do SO) para que o SO convidado não seja inicializado quando as máquina virtual estiverem configuradas com a inicialização segura ativada. Para contornar esse problema, siga um destes procedimentos:
Há um limite de 100 prefixos para divulgações de rota da sua nuvem privada para sua rede VPC
Se o anúncio de rota exceder esse limite, alguns prefixos poderão ser descartados. Para permanecer dentro desse limite, implemente a agregação no NSX-T Edge.
O VMware Engine depende dos Cloud Routers para divulgar intervalos de endereços IP (prefixos ou CIDRs) de NSX para uma rede VPC produtor de serviços. Esses prefixos se tornam rotas dinâmicas personalizadas na rede VPC VPC produtor de serviços que está em peering com sua rede VPC.
Quando você configura sua rede VPC para importar rotas dinâmicas personalizadas nessa relação de peering, os prefixos NSX têm prefixo de rotas personalizadas na rede VPC. O número de prefixos NSX que é possível importar é limitado por dois fatores:
- Limite padrão do Cloud Router para o número de prefixos exclusivos por região, que o VMware Engine herda
- O número máximo de rotas dinâmicas em um grupo de peering na sua rede VPC
Houve falha nas operações da nuvem privada antes que ela fosse totalmente implantada
Operações, como escalonamento de privilégios, expansão de nuvem privada e substituição de nó, são permitidas no portal do Google Cloud VMware Engine em nuvens privadas operacionais que ainda não foram totalmente provisionadas. No entanto, se você tentar essas operações no VMware Engine antes da implantação da nuvem privada (incluindo NSX-T e HCX), essas operações falharão. Não tente essas operações até ter implantado sua nuvem privada totalmente.
O VMware Engine ainda não é totalmente compatível com o VPC Service Controls
O VPC Service Controls implementa uma solução provisória (solução alternativa) para permitir que você ainda consuma o VMware Engine de dentro de um projeto em um perímetro do VPC Service Controls. Consulte VPC Service Controls para mais informações.
Interoperabilidade da Apigee com o roteamento de Internet local
Se você usar a Apigee com o peering de VPC na mesma rede VPC que o VMware Engine e configurar o VMware Engine para rotear o tráfego da Internet por uma conexão local, a comunicação de saída da Apigee também poderá ser roteada pela sua conexão local.
Essa configuração ocorre quando você ativa o VPC Service Controls no
servicenetworking.googleapis.com peering, conforme descrito em
Configurar o acesso à Internet para VMs de carga de trabalho.
Se o tráfego da Apigee for roteado pela sua conexão local, a Apigee não usará mais o endereço IP externo configurado para comunicação de saída com serviços de back-end de API externos. Se você depende do endereço IP externo da Apigee para configurações de firewall, atualize as configurações de firewall para permitir o tráfego da sua rede local.
Os hosts ESXi podem perder a conectividade temporariamente durante a coleta de informações de diagnóstico
Os hosts ESXi em ambientes com dispositivos NVMe PCIe podem perder a conectividade temporariamente durante a coleta de informações de diagnóstico.
Causa raiz
Quando você usa o comando vm-support ou UI do vCenter para coletar informações sobre sistemas ESXi, os registros são armazenados temporariamente no diretório ramdisk /tmp. Se o sistema tiver muitos dispositivos NVMe PCIe ou o arquivo de registro for grande, o diretório ramdisk /tmp ficará cheio rapidamente, o que pode fazer com que o host ESXi perca a conectividade temporariamente até que a coleta vm-support seja concluída.
Alternativa:
Excluir o manifesto NVME da seção de registros selecionados na página de criação do pacote de registros impede que o diretório ramdisk /tmp fique cheio e verifica se o host EXSi não perde a conectividade de rede. Para excluir o manifesto NVMe, faça o seguinte:
- Faça login no vCenter usando o nome de usuário e a senha do
cloudowner. - No inventário, clique com o botão direito do mouse na instância do vCenter Server em que você quer a exclusão.
- Clique em Exportar registros do sistema….
- Selecione o host ESXi do qual você quer excluir o pacote de registros.
- Em Selecionar registros, role até Armazenamento e desmarque a opção NVMe, e clique em Registros exportados. O manifesto NVMe agora está excluído.
Para mais informações sobre essa correção, consulte VMware ESXi 7.0 Update 3q.
Erro de tradução do nome do recurso da nuvem privada
Se você estiver executando o VMware Engine Horizon (VDI) no Google Cloud VMware Engine, talvez encontre erros depois de alterar o nome do recurso da nuvem privada para atender aos padrões da Google Cloud CLI e da API VMware Engine.
O exemplo de erro a seguir ocorre ao alterar os nomes de recursos da nuvem privada sem editar adequadamente o provisionamento do Horizon Desktop Pools:
Error during Provisioning Cloning of VM Desktop-UK-005 has failed. No resource pool available for the pool: ic-pool-1
Error during Provisioning Cloning of VM Desktop-UK-005 has failed. No datastores available for the pool: {}ic-pool-1
Para resolver esse problema, siga estas etapas antes da data de tradução programada do nome:
- Acesse o painel do VMware Horizon.
- Edite todos os pools de computadores do Horizon para clones completos e clones instantâneos e defina-os como Desativar provisionamento.
Depois que a alteração do nome do recurso da nuvem privada for concluída, siga estas etapas:
Edite cada pool de computador e reconfigure as seguintes configurações na guia vCenter Settings para os pools de clones completos e instantâneos:
- Pool de recursos
- Datastore
Defina cada status de pool novamente como Ativar provisionamento.
Teste cada pool adicionando ou removendo um computador do pool para verificar se o provisionamento está funcionando corretamente.
A equipe do VMware Engine está trabalhando ativamente para fornecer uma solução de interoperabilidade o mais rápido possível. Para manter-se em dia quanto à disponibilidade dos recursos, entre em contato com a equipe da sua conta.