Problemas conhecidos
Nesta página, descrevemos os problemas conhecidos que você pode encontrar ao usar o Google Cloud VMware Engine.
Problemas gerais
Confira a seguir os problemas gerais conhecidos que afetam o VMware Engine.
Upgrade do HCX Manager rotulado incorretamente como upgrade da versão do vSphere
Problema: o upgrade do HCX Manager está rotulado incorretamente como um "upgrade da versão do vSphere" no console do Google Cloud .
Detalhes: embora notificações específicas por e-mail identificando o upgrade do HCX sejam enviadas pelo menos 14 dias e 24 horas antes do evento, as notificações automáticas "A atualização da sua nuvem privada começou" e "A atualização da sua nuvem privada foi concluída" refletem uma atualização geral da nuvem privada. Além disso, a interface do console do Google Cloud rotula 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 grande atualização da plataforma.
Solução alternativa: analise os e-mails de notificação específicos do HCX enviados antes da janela de manutenção para confirmar o escopo do trabalho. Se o cronograma estiver alinhado, o status "Upgrade da versão do vSphere" no console do Google Cloud 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ções.
Tempo de provisionamento para nuvens privadas do vSphere 8.0 Update 3
Problema: agora o VMware Engine 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 da nuvem privada pode levar até 140 minutos.
Solução alternativa: nenhuma solução alternativa é necessária, mas planeje um tempo extra ao implantar novas nuvens privadas ou expandir clusters atuais.
Detecção: talvez você observe 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 de produtor de serviço. Esses prefixos se tornam rotas dinâmicas personalizadas na rede VPC VPC de produtor de serviço 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 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 completa da nuvem privada (incluindo NSX-T e HCX), elas vão falhar. 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 (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.
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 temporariamente a conectividade 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 temporariamente a conectividade até que a coleta de vm-support seja concluída.
Alternativa:
Excluir o manifesto NVME da seção de logs selecionados na página de criação do pacote de logs
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 do 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 de que você quer excluir o pacote de registros.
- Em Selecionar registros, role até Armazenamento e desmarque a opção NVMe. Em seguida, 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 (em inglês).
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 mudar 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 mudar 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 instantâneos e defina-os como Desativar provisionamento.
Depois que a mudança 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.