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.
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, o NSX tem prefixo de rotas personalizadas na sua 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 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 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.
O VMware Engine ainda não é totalmente [compatível com o VPC Service Controls][vpc sc supported products]
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.
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 do ESXi perca a conectividade temporariamente até que a coleta de vm-support
seja concluída.
Alternativa:
A exclusão do manifesto NVME da seção de seleção de registros na página de criação de pacotes de registro
impede que o diretório ramdisk /tmp fique cheio e
garante que o host EXSi não perca 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 de onde você quer excluir o pacote de registros.
- Em Selecionar logs, role até Armazenamento e limpe a opção NVMe. Em seguida, clique em Logs 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 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 alteração do nome do recurso da nuvem privada for concluída, siga estas etapas:
Edite cada pool de computadores 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 garantir que o provisionamento esteja 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.