Problemas conhecidos

Nesta página são descritos os problemas que você pode encontrar ao usar o Compute Engine. Para problemas que afetam especificamente as VMs confidenciais, consulte Limitações de VMs confidenciais.

Problemas gerais

Os problemas a seguir fornecem orientações para solução de problemas ou informações gerais.

Criar reservas ou solicitações futuras de reserva usando um modelo de instância que especifica um tipo de máquina A2, C3 ou G2 causa problemas

Você encontrará problemas ao usar um modelo de instância que especifica um tipo de máquina A2, C3 ou G2 para criar uma reserva ou para criar e enviar uma solicitação de reserva futura para análise. Especificamente:

  • A criação da reserva pode falhar. Se ela for bem-sucedida, uma das seguintes condições se aplica:

    • Se você criou uma reserva consumida automaticamente (padrão), a criação de VMs com propriedades correspondentes não vai consumir a reserva.

    • Se você criou uma reserva específica, a criação de VMs para visar especificamente a reserva falhará.

  • A criação da solicitação de reserva futura foi bem-sucedida. No entanto, se você enviá-lo para análise, o Google Cloud recusará a solicitação.

Não é possível substituir o modelo de instância usado para criar uma reserva ou solicitação de reserva futura nem modificar as propriedades de VM do modelo. Se você quiser reservar recursos para os tipos de máquina A2, C3 ou G2, siga um destes procedimentos:

Limitações ao usar tipos de máquina c3-standard-*-lssd e c3d-standard-*-lssd com o Google Kubernetes Engine

Ao usar a API Google Kubernetes Engine, o pool de nós com o SSD local anexado que você provisiona precisa ter o mesmo número de SSDs que o tipo de máquina C3 e C3D selecionado. Por exemplo, se você planeja criar uma VM que usa o c3-standard-8-lssd, é necessário ter dois discos SSD, enquanto que para um c3d-standard-8-lssd, apenas um disco SSD é necessário. Se o número do disco não corresponder, você receberá um erro de configuração do SSD local do plano de controle do Compute Engine. Consulte o documento Família de máquinas de uso geral para selecionar o número correto de discos SSD locais com base no tipo de máquina lssd C3 ou C3D.

Usar o console do Google Cloud no Google Kubernetes Engine para criar um cluster ou pool de nós com VMs c3-standard-*-lssd e c3d-standard-*-lssd resulta em falha na criação do nó ou em falha na detecção de SSDs locais como armazenamento temporário.

Variabilidade da capacidade de processamento de TCP de fluxo único em VMs C3D

VMs C3D com mais de 30 vCPUs podem apresentar variação de capacidade de TCP de fluxo único e, às vezes, ser limitadas a 20 a 25 Gbps. Para alcançar taxas mais altas, use vários fluxos de TCP.

O grupo gerenciado de instâncias com série de máquina T2D não faz o escalonamento automático conforme esperado

Os grupos gerenciados de instâncias (MIGs) que têm as VMs com a série de máquina T2D em projetos criados antes de 18 de junho de 2023 não detectam corretamente a carga da CPU em VMs no MIG. Nesses projetos, o escalonamento automático com base na utilização da CPU em um MIG que tem VMs com a série de máquina T2D pode estar incorreto.

Para aplicar uma correção ao seu projeto, entre em contato com o Cloud Customer Care.

A métrica de observabilidade de utilização da CPU está incorreta para VMs que usam uma linha de execução por núcleo

Se a CPU da VM usar uma linha de execução por núcleo, a métrica de observabilidade do Cloud Monitoring de utilização da CPU no Google Compute Engine> Instâncias de VM> Observabilidade a guia só é dimensionada para 50%. Duas linhas de execução por núcleo são o padrão para todos os tipos de máquinas, exceto o Tau T2D. Para ver mais informações, consulte Definir número de linhas de execução por núcleo.

Para ver o uso de CPU da sua VM normalizado em 100%, confira a utilização de CPU no Metrics Explorer. Para mais informações, consulte Criar gráficos com o Metrics Explorer.

As conexões SSH no navegador do console do Google Cloud podem falhar se você usar regras de firewall personalizadas

Se você usa regras de firewall personalizadas para controlar o acesso SSH às instâncias de VM, talvez não seja possível usar o recurso SSH no navegador.

Para resolver esse problema, siga uma destas etapas:

Reduzir ou excluir reservas específicas impede que as VMs consumam outras reservas

Se você reduzir ou excluir uma reserva específica que foi consumida por uma ou mais VMs, as VMs órfãs não poderão consumir reservas.

Saiba mais sobre como excluir reservas e redimensionar reservas.

Mover VMs ou discos usando a API moveInstance ou a CLI gcloud causa comportamentos inesperados

Mover instâncias de máquina virtual (VM) usando o comando gcloud compute instances move ou o método project.moveInstance pode causar perda de dados, exclusão de VM ou outro comportamento inesperado.

Ao mover VMs, recomendamos seguir as instruções em Mover uma instância de VM entre zonas ou regiões.

Os discos anexados a VMs com tipos de máquina n2d-standard-64 não atingem os limites de desempenho de maneira consistente

Os discos permanentes anexados a VMs com tipos de máquina n2d-standard-64 não alcançam o limite máximo de desempenho de 100.000 IOPS de maneira consistente. Esse é o caso para IOPS de leitura e gravação.

Nomes temporários para discos

Durante a atualização das instâncias de máquina virtual (VM) iniciadas usando gcloud compute instances update comando ou instances.update Método de API, o Compute Engine pode alterar temporariamente o nome dos discos da sua VM adicionando os seguintes sufixos ao nome original:

  • -temp
  • -old
  • -new

O Compute Engine remove o sufixo e restaura os nomes dos discos originais à medida que a atualização é concluída.

Latência maior em alguns discos permanentes devido ao redimensionamento do disco

Em alguns casos, o redimensionamento de discos permanentes grandes (aproximadamente 3 TB ou maiores) pode ser prejudicial para o desempenho de E/S deles. Se esse problema afetar seus processos, os discos permanentes poderão ter latência maior durante a operação de redimensionamento. Isso pode acontecer com discos permanentes de qualquer tipo.

Capacidade de anexar discos PD-Standard e PD-Extreme incompatíveis a VMs C3 e M3

Os discos permanentes padrão (pd-standard) são o tipo de disco de inicialização padrão ao usar a Google Cloud CLI ou a API Compute Engine. No entanto, os discos pd-standard não são compatíveis com as VMs C3 e M3. Além disso, as VMs C3 não são compatíveis com discos pd-extreme.

Os seguintes problemas podem ocorrer ao usar a Google Cloud CLI ou a API Compute Engine:

  • pd-standard é configurado como o tipo de disco de inicialização padrão e o disco é criado, a menos que você especifique um tipo diferente de disco de inicialização suportado, como pd-balanced ou pd-ssd.
  • Antes da disponibilidade geral (GA, na sigla em inglês) da C3, era possível anexar pd-extreme discos às VMs C3 e pd-standard aos VMs C3 e M3.

Se você criou uma VM C3 ou M3 com um tipo de disco não compatível, mova os dados para um novo tipo de disco compatível, conforme descrito em Alterar o tipo do seu disco permanente. Se você não alterar o tipo de disco, as VMs continuarão funcionando, mas algumas operações, como desconexão e reconexão do disco, falharão.

Alternativa

Para resolver esse problema, siga uma destas etapas:

  • Use o console do Google Cloud para criar VMs C3 ou M3 e anexar discos. O console cria VMs C3 e M3 com discos de inicialização pd-balanced e não permite anexar tipos de disco não compatíveis a VMs.
  • Se você estiver usando a Google Cloud CLI ou a API Compute Engine, configure explicitamente um disco de inicialização do tipo pd-balanced ou pd-ssd ao criar uma VM.

Seus processos automatizados podem falhar se usarem dados de resposta da API sobre suas cotas de compromisso baseadas em recursos

Os processos automatizados que consomem e usam dados de resposta da API sobre suas cotas de compromisso baseadas em recursos do Compute Engine poderão falhar se cada uma das situações a seguir acontecer. Os processos automatizados podem incluir snippets de código, lógica de negócios ou campos de banco de dados que usam ou armazenam as respostas da API.

  1. Os dados de resposta são de um dos seguintes métodos da API Compute Engine:

  2. Use int em vez de number para definir o campo do limite de cota de recurso nos corpos de resposta da API. É possível encontrar o campo das seguintes maneiras para cada método:

  3. Você tem uma cota padrão ilimitada disponível para qualquer uma das SKUs confirmadas do Compute Engine.

    Para mais informações sobre cotas de compromissos e SKUs confirmadas, consulte Cotas de compromissos e recursos confirmados.

Causa principal

Quando você tem uma cota limitada, se definir o campo items[].quotas[].limit ou quotas[].limit como um tipo int, os dados de resposta da API para os limites de cota ainda poderão estar dentro do intervalo do tipo int e o processo automatizado não será interrompido. No entanto, quando o limite de cota padrão é ilimitado, a API Compute Engine retorna um valor para o campo limit que está fora do intervalo definido pelo tipo int. Seu processo automatizado não pode consumir o valor retornado pelo método da API e falha como resultado.

Como contornar esse problema

É possível contornar esse problema e continuar gerando relatórios automatizados das seguintes maneiras:

  • Recomendado: siga a documentação de referência da API Compute Engine e use os tipos de dados corretos para as definições de método da API. Mais especificamente, use o tipo number para definir os campos items[].quotas[].limit e quotas[].limit dos métodos da API.

  • Reduza o limite da cota para um valor abaixo de 9.223.372.036.854.775.807. É preciso definir limites de cota para todos os projetos com compromissos baseados em recursos em todas as regiões. É possível fazer isso de uma das seguintes maneiras:

Problemas conhecidos de instâncias bare metal

Estes são os problemas conhecidos das instâncias bare metal do Compute Engine.

A estatística de pacotes descartados está incorreta

O número de pacotes descartados informados por VIRTCHNL2_OP_GET_STATS é muito grande.

A causa raiz é que o IDPF informa EthStats::rx_discards ao SO como rtnl_link_stats64::rx_dropped. Ele aparece como RX dropped quando você executa ifconfig.

Problemas conhecidos de instâncias de VMs do Linux

Estes são os problemas conhecidos das VMs do Linux.

Desempenho de IOPS mais baixo para SSD local no Z3 com imagens do SUSE 12

As VMs Z3 nas imagens do SUSE Linux Enterprise Server (SLES) 12 têm uma performance significativamente menor do que o esperado para IOPS em discos SSD locais.

Causa principal

Esse é um problema na base de código do SLES 12.

Alternativa

Não há um patch do SUSE para corrigir esse problema. Em vez disso, use o sistema operacional SLES 15.

As VMs do RHEL 7 e do CentOS perdem acesso à rede após a reinicialização

Se as VMs do CentOS ou do RHEL 7 tiverem várias placas de interface de rede (NICs) e uma delas não usar a interface VirtIO, o acesso à rede poderá ser perdido após a reinicialização. Isso acontece porque o RHEL não é compatível com a desativação de nomes de interface de rede previsíveis se pelo menos uma NIC não usar a interface VirtIO.

Resolução

A conectividade de rede pode ser restaurada interrompendo e iniciando a VM até que o problema seja resolvido. Para evitar que a perda de conectividade de rede ocorra novamente, faça o seguinte: 1. Edite o arquivo /etc/default/grub e remova os parâmetros do kernel net.ifnames=0 e biosdevname=0. 2. Gere novamente a configuração do grub. 3. Reinicialize a VM.

As imagens públicas do SUSE do Google Cloud não incluem a configuração udev necessária para criar links simbólicos de dispositivos SSD locais C3 e C3D.

Resolução

Para adicionar regras udev para SUSE e imagens personalizadas, consulte Links simbólicos não criados C3 e C3D com SSD local.

Não foi possível verificar a assinatura do repomd.xml

Nos sistemas baseados em Red Hat Enterprise Linux (RHEL) ou CentOS 7, você talvez veja o erro a seguir ao tentar instalar ou atualizar o software usando o yum. Esse erro mostra que você tem uma chave GPG de repositório expirada ou incorreta.

Exemplo de registro:

[root@centos7 ~]# yum update


...

google-cloud-sdk/signature                                                                  | 1.4 kB  00:00:01 !!!
https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64/repodata/repomd.xml: [Errno -1] repomd.xml signature could not be verified for google-cloud-sdk
Trying other mirror.

...

failure: repodata/repomd.xml from google-cloud-sdk: [Errno 256] No more mirrors to try.
https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64/repodata/repomd.xml: [Errno -1] repomd.xml signature could not be verified for google-cloud-sdk

Resolução

Para corrigir isso, desative a verificação de chave GPG do repositório na configuração do repositório yum configurando repo_gpgcheck=0. Em imagens compatíveis de base do Compute Engine, essa configuração pode ser encontrada no arquivo /etc/yum.repos.d/google-cloud.repo. No entanto, essa VM pode estar definida em diferentes arquivos de configuração de repositório ou ferramentas de automação.

Os repositórios do Yum geralmente não usam chaves GPG para validação de repositório. Em vez disso, o endpoint https é confiável.

Para localizar e atualizar essa configuração, siga estas etapas:

  1. Procure a configuração no seu arquivo /etc/yum.repos.d/google-cloud.repo.

    cat /etc/yum.repos.d/google-cloud.repo


[google-compute-engine]
name=Google Compute Engine
baseurl=https://packages.cloud.google.com/yum/repos/google-compute-engine-el7-x86_64-stable
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
[google-cloud-sdk]
name=Google Cloud SDK
baseurl=https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

  2. Altere todas as linhas que dizem repo_gpgcheck=1 para repo_gpgcheck=0.

    sudo sed -i 's/repo_gpgcheck=1/repo_gpgcheck=0/g' /etc/yum.repos.d/google-cloud.repo

  3. Verifique se a configuração foi atualizada.

    cat /etc/yum.repos.d/google-cloud.repo

[google-compute-engine]
name=Google Compute Engine
baseurl=https://packages.cloud.google.com/yum/repos/google-compute-engine-el7-x86_64-stable
enabled=1
gpgcheck=1
repo_gpgcheck=0
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
[google-cloud-sdk]
name=Google Cloud SDK
baseurl=https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=0
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

Mensagem de login retornada após a conexão de instâncias que usam o Login do SO

Em algumas instâncias que usam o login do SO, você pode receber a seguinte mensagem de erro após a conexão ter sido estabelecida:

/usr/bin/id: cannot find name for group ID 123456789

Resolução

Ignore a mensagem de erro.

Problemas conhecidos de instâncias de VM do Windows

  • O suporte para NVMe no Windows usando o driver da comunidade NVMe está na versão Beta. O desempenho pode não corresponder ao das instâncias do Linux. O driver NVMe da comunidade foi substituído pelo driver Microsoft StorNVMe nas imagens públicas do Google Cloud. Recomendamos que você substitua o driver NVME nas VMs criadas antes de maio de 2022 e use o driver Microsoft StorNVMe.
  • Depois de criar uma instância, não é possível se conectar a ela instantaneamente. Todas as instâncias novas do Windows usam a ferramenta System Preparation (sysprep) para configurar sua instância, o que pode levar de 5 a 10 minutos.
  • As imagens do Windows Server não podem ser ativadas sem uma conexão de rede com kms.windows.googlecloud.com e param de funcionar quando não são autenticadas dentro de 30 dias. O software ativado pelo KMS precisa ser reativado a cada 180 dias, mas o KMS tenta reativá-lo a cada 7 dias. Configure as instâncias do Windows para que elas permaneçam ativadas.
  • O software de kernel que acessa registros específicos de modelo sem emulação gerará falhas de proteção geral. Dependendo do sistema operacional convidado, isso pode causar uma falha no sistema.

Erros ao medir o deslocamento de tempo NTP usando w32tm em VMs do Windows

Para VMs do Windows no Compute Engine que executam NICs VirtIO, há um bug conhecido em que a medição do deslocamento de NTP produz erros ao usar o seguinte comando:

w32tm /stripchart /computer:metadata.google.internal

Os erros são semelhantes a estes:

Tracking metadata.google.internal [169.254.169.254:123].
The current time is 11/6/2023 6:52:20 PM.
18:52:20, d:+00.0007693s o:+00.0000285s  [                  *                  ]
18:52:22, error: 0x80072733
18:52:24, d:+00.0003550s o:-00.0000754s  [                  *                  ]
18:52:26, error: 0x80072733
18:52:28, d:+00.0003728s o:-00.0000696s  [                  *                  ]
18:52:30, error: 0x80072733
18:52:32, error: 0x80072733

Esse bug afeta apenas as VMs do Compute Engine com NICs VirtIO. As VMs que usam a gVNIC não encontram esse problema.

Para evitar esse problema, o Google recomenda o uso de outras ferramentas de medição de deslocamento do NTP, como o Monitor de servidor de tempo Meinberg.

Dispositivo de inicialização inacessível após atualizar uma VM de 1ª ou 2ª geração para uma VM de 3ª geração ou mais recente

O Windows Server vincula a unidade de inicialização ao tipo de interface de disco inicial na primeira inicialização. Para mudar uma VM de uma série de máquinas mais antiga que usa uma interface de disco SCSI para uma série de máquinas mais recente que usa uma interface de disco NVMe, execute um sysprep de driver PnP do Windows antes de desligar a VM. Esse sysprep prepara apenas drivers de dispositivo e garante que todos os tipos de interface de disco sejam verificados para a unidade de inicialização na próxima inicialização.

Para atualizar a série de máquinas de uma VM, faça o seguinte:

Em um prompt do PowerShell como Administrator, execute:

PS C:\> start rundll32.exe sppnp.dll,Sysprep_Generalize_Pnp -wait
  1. Pare a VM.
  2. Mude a VM para o novo tipo de máquina.
  3. Inicie a VM.

Se a nova VM não iniciar corretamente, mude-a de volta para o tipo de máquina original para que ela volte a funcionar. Ela vai ser iniciada com sucesso. Confira os requisitos de migração para garantir que você os atenda. Em seguida, tente seguir as instruções novamente.

Largura de banda limitada com gVNIC em VMs Windows

Em sistemas operacionais Windows, o driver da gVNIC não atinge os limites de largura de banda documentados para o tipo de máquina. O driver da gVNIC pode atingir até 50 Gbps de largura de banda de rede em VMs Windows, para desempenho de rede padrão e por VM de Tier_1.

A quantidade de discos anexados é limitada para séries de máquinas de VM mais recentes

As VMs executadas no Microsoft Windows com a interface de disco NVMe (que inclui T2A, todas as VMs de terceira geração e mais recentes e as VMs que usam a Computação confidencial) têm um limite de conexão de disco de 16 discos. Para evitar erros, consolide o armazenamento do Persistent Disk e do Hyperdisk em um máximo de 16 discos por VM. O armazenamento SSD local não é afetado por esse problema.

Substitua o driver NVME nas VMs criadas antes de maio de 2022

Se você quiser usar o NVMe em uma VM que usa o Microsoft Windows e ela tiver sido criada antes de 1º de maio de 2022, atualize o driver NVMe atual no SO convidado para usar o Driver Microsoft StorNVMe.

Atualize o driver NVMe na VM antes de alterar o tipo de máquina para uma série de máquinas de terceira geração ou antes de criar um snapshot do disco de inicialização que será usado para criar novas VMs que usam uma máquina de terceira geração.

Use os seguintes comandos para instalar o pacote de driver do StorNVME e remover o driver da comunidade, se estiver presente no SO convidado.

googet update
googet install google-compute-engine-driver-nvme

Desempenho mais baixo do SSD local no Microsoft Windows com VMs C3 e C3D

O desempenho do SSD local é limitado para VMs C3 e C3D que executam o Microsoft Windows.

As melhorias no desempenho estão em andamento.

Baixa capacidade de rede ao usar o gVNIC

As VMs do Windows Server 2022 e do Windows 11 que usam o driver gVNIC versão do pacote GooGet 1.0.0@44 ou anterior podem ter uma capacidade de rede ruim ao usar a NIC virtual do Google (gVNIC).

Para resolver esse problema, atualize o pacote GooGet do driver da gVNIC para a versão 1.0.0@45 ou mais recente fazendo o seguinte:

  1. Verifique qual versão do driver está instalada na VM. Para isso, execute o comando a seguir em um prompt de comando ou sessão do PowerShell como administrador:

    googet installed

    A saída será assim:

    Installed packages:
  ...
  google-compute-engine-driver-gvnic.x86_64 VERSION_NUMBER
  ...

  2. Se a versão do driver google-compute-engine-driver-gvnic.x86_64 for 1.0.0@44 ou anterior, atualize o repositório de pacotes GooGet executando o seguinte comando em um prompt de comando ou sessão do PowerShell como administrador:

    googet update

Os tipos de máquina de vCPU C3D 180 e 360 não são compatíveis com imagens do SO Windows.

Os tipos de máquina C3D de 180 vCPUs não são compatíveis com imagens do SO Windows Server 2012 e 2016. As VMs C3D criadas com 180 vCPUs e as imagens dos SO Windows Server 2012 e 2016 não serão inicializadas. Para contornar esse probema, selecione um tipo de máquina menor ou use outra imagem do SO.

As VMs C3D criadas com 360 vCPUs e imagens do SO Windows não vão ser inicializadas. Para contornar esse probema, selecione um tipo de máquina menor ou use outra imagem do SO.

Erro de disco genérico no Windows Server 2016 e 2012 R2 para VMs M3, C3 e C3D

No momento, a capacidade de adicionar ou redimensionar um Persistent Disk ou Hyperdisk em uma VM do M3, C3 ou C3D em execução não funciona como esperado em convidados específicos do Windows. O Windows Server 2012 R2 e o Windows Server 2016 e as variantes correspondentes do Windows não relacionadas ao servidor não respondem corretamente aos comandos de anexação e redimensionamento de disco.

Por exemplo, remover um disco de uma VM M3 em execução desconecta o disco de uma instância do Windows Server sem que o sistema operacional Windows reconheça que o disco sumiu. As gravações subsequentes no disco retornarão um erro genérico.

Resolução

É necessário reiniciar a VM do M3, C3 ou C3D em execução no Windows depois de modificar um Hyperdisk ou Persistent Disk para que as modificações de disco sejam reconhecidas por esses convidados.