Problemas conhecidos
Nesta página, descrevemos os problemas conhecidos que você pode encontrar ao usar o Google Cloud VMware Engine.
Problemas gerais
A seguir, confira os problemas gerais conhecidos que afetam o VMware Engine.
Alarmes de erro pNIC integrados do vCenter acionados em eventos de rede temporários
Problema: os alarmes de infraestrutura integrados do vCenter, como "Taxa de erro pNIC alta detectada", podem ser acionados intermitentemente no console do vSphere Client devido a anomalias de pacotes localizadas temporárias.
Detalhes: a estrutura de alertas integrada do VMware avalia os contadores de placa de interface de rede física (pNIC, na sigla em inglês) subjacentes em janelas de amostragem curtas e rígidas. Devido a esse design, o vCenter pode acionar alertas imediatos para eventos de rotina e sem impacto, como ruído temporário ou comportamento esperado de descarte de pacotes em uplinks vSAN em espera, mesmo quando a camada de rede está íntegra. Devido à redundância de caminho integrada, esses alertas não afetam a disponibilidade do ambiente nem a integridade de dados.
Alternativa: nenhuma ação ou solução alternativa do cliente é necessária. Como não é esperado que a sensibilidade de amostragem de alarme integrada do vCenter seja atualizada no curto prazo, o Google implantou a inteligência da plataforma subjacente para gerenciar e filtrar esses falsos positivos. Para ambientes de produção direcionados, o Google suprime esses alertas de console integrados voltados ao cliente. Em vez disso, o mecanismo de análise do Google monitora os dados de infraestrutura e avalia a camada física continuamente usando uma média móvel de 30 minutos. Se o mecanismo de análise do Google identificar uma degradação física persistente, como um cabo ou uma fibra óptica com defeito, a plataforma vai alertar automaticamente o suporte do Google para investigar e resolver o problema, além de enviar uma notificação automatizada para você.
Status: essa é uma limitação conhecida da lógica de avaliação de alarme integrada do vCenter. O Google gerencia esse comportamento por meio da inteligência da plataforma integrada e subjacente. O VMware está ciente desse problema e aconselhou sobre a solução alternativa.
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 específicas por e-mail que identifiquem 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 "upgrade da versão do vSphere" no Google Cloud console se refere estritamente à atualização do HCX Manager. Nenhuma ação é necessária.
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 o VMware vSphere versão 8.0 Update 3 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 solução alternativa é necessária, mas planeje um tempo adicional 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 vai mais usar 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 vai 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 foi 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 de nome programada:
- 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.