Problemas conhecidos


Nesta página são descritos os problemas que você pode encontrar ao usar o Compute Engine.

Problemas gerais

Latência maior em alguns discos permanentes

Em alguns casos, snapshots de discos permanentes grandes (~3 TB ou mais) acionam operações que podem prejudicar o desempenho de E/S do disco. Se você for afetado por esse problema, os discos permanentes poderão ter latência maior durante a operação de snapshot. Esse problema pode afetar discos permanentes de qualquer tipo e pode ser acionado por snapshots regulares ou programados.

Erro na permissão de operações de computação

O problema a seguir foi resolvido em 21 de dezembro de 2020.

Se o projeto usa a versão 286.0.0 ou posterior da ferramenta gcloud, você poderá receber um dos seguintes erros ao executar comandos que atualizam dados, como gcloud compute instances start ougcloud compute disks snapshot:

ERROR: (gcloud.compute.METHOD) Could not fetch resource:
 - Required 'compute.globalOperations.get' permission
ERROR: (gcloud.compute.METHOD) Could not fetch resource:
 - Required 'compute.regionOperations.get' permission
ERROR: (gcloud.compute.METHOD) Could not fetch resource:
 - Required 'compute.zoneOperations.get' permission
ERROR: (gcloud.compute.METHOD) HTTPError 403:
Required 'compute.globalOperations.get' permission for RESOURCE
ERROR: (gcloud.compute.METHOD) HTTPError 403:
Required 'compute.regionOperations.get' permission for RESOURCE
ERROR: (gcloud.compute.METHOD) HTTPError 403:
Required 'compute.zoneOperations.get' permission for RESOURCE

Talvez também encontre erros semelhantes ao chamar os métodos de API compute.globalOperations.wait, compute.regionOperations.wait ou compute.zoneOperations.wait.

Se tiver permissões do IAM definidas no nível da instância e não no nível do projeto, os erros de permissão poderão ser causados pelo problema 171947836 do Compute Engine. Para minimizar isso, tente uma das seguintes soluções:

  • Crie um papel de IAM personalizado no nível do projeto que inclua a permissão ausente: compute.regionOperations.get, compute.regionOperations.get ou compute.zoneOperations.get. Atribua esta função aos usuários que receberam o erro de permissão.
  • Faça downgrade da ferramenta gcloud para a versão 285 ou anterior.
  • Atribua o papel roles/compute.viewer aos usuários que receberam o erro de permissão.

Resolvido: alguns projetos têm a conta de serviço padrão incorreta

O problema a seguir foi resolvido em 1o de dezembro de 2020.

Ao ativar a API Compute Engine no projeto, uma conta de serviço padrão é adicionada ao projeto. Normalmente, a conta de serviço padrão tem o seguinte e-mail:

PROJECT_NUMBER-compute@developer.gserviceaccount.com

Para um pequeno número de projetos, o e-mail da conta de serviço padrão é definido incorretamente como:

service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com

Se você tiver sido afetado por esse problema, há a possibilidade de encontrar erros 403 Forbidden e não conseguir criar novos recursos do Compute Engine. Nesse caso, entre em contato com o Suporte do Google Cloud para resolver o problema e responder às suas dúvidas. Há uma correção automatizada executada para resolver o problema enquanto uma solução de longo prazo é desenvolvida.

Para acompanhar o status do problema, consulte Problema 171305221 do Compute Engine.

Problemas conhecidos de instâncias de VMs do Linux

Erro GPG: EXPKEYSIG 3746C208A7317B0F ao atualizar pacotes

Nos sistemas baseados em Debian e Ubuntu, inclusive estações de trabalho locais, é possível encontrar um erro semelhante ao seguinte exemplo:

W: An error occurred during the signature verification.
The repository is not updated and the previous index files will be used.
GPG error: http://packages.cloud.google.com/apt cloud-sdk-stretch InRelease:
The following signatures were invalid: EXPKEYSIG 3746C208A7317B0F
Google Cloud Packages Automatic Signing Key <gc-team@google.com>

Esse erro impede que você receba as atualizações mais recentes para várias ferramentas do Google Cloud, incluindo os seguintes itens:

Para resolver esse erro, consiga o arquivo de chave apt-key.gpg válido mais recente em https://packages.cloud.google.com executando o comando a seguir:

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

Como alternativa, nas instâncias de VM do Compute Engine que executam imagens do Debian ou do Ubuntu, é possível adquirir as chaves mais recentes recriando suas instâncias com as seguintes versões de imagem:

  • Projeto de imagem debian-cloud:
    • debian-9-stretch-v20180401 ou família de imagens debian-9
    • debian-8-jessie-v20180401 ou família de imagens debian-8
  • Projeto de imagem ubuntu-os-cloud:
    • ubuntu-1710-artful-v20180315 ou família de imagens ubuntu-1710
    • ubuntu-1604-xenial-v20180323 ou família de imagens ubuntu-1604-lts
    • ubuntu-1404-trusty-v20180308 ou família de imagens ubuntu-1404-lts

Problema no sistema de arquivos raiz somente leitura do Red Hat Enterprise Linux 7 e do CentOS 7

As instâncias de VM que executam imagens públicas rhel-7-v20170719 ou anteriores ou centos-7-v20170719 ou anteriores podem ser inicializadas com o sistema de arquivos raiz ativado no modo somente leitura. Aplicativos, daemons ou scripts que exigem acesso de gravação ao sistema de arquivos raiz falharão.

Não reinicialize ou reinicie instâncias em execução que usem as imagens públicas afetadas. Caso contrário, elas não sairão do modo somente leitura. Se as instâncias já estiverem travadas no modo somente leitura, restaure remotamente o modo de leitura e gravação para o sistema de arquivos raiz e corrija o problema.

Identificar de instâncias afetadas:

Identifique as instâncias potencialmente afetadas usando os seguintes comandos gcloud compute disks list:

RHEL 7:

gcloud compute disks list --filter="sourceImage ~ rhel-7-v201[4-6].* OR sourceImage ~ rhel-7-v20170[1-7].*" --uri

CentOS 7:

gcloud compute disks list --filter="sourceImage ~ centos-7-v201[4-6].* OR sourceImage ~ centos-7-v20170[1-7].*" --uri

Se esses discos estiverem anexados às instâncias, você poderá corrigir o problema nelas. O processo para corrigir instâncias afetadas depende da versão da imagem usada para criar a instância.

Instâncias criadas usando imagens do RHEL 7 entre rhel-7-v20160418 e rhel-7-v20170719 ou imagens do CentOS 7 entre centos-7-v20160418 e centos-7-v20170719:

Se a instância usar atualizações automáticas, o yum-cron instalará automaticamente o pacote fixo e removerá a opção de ativação inválida do arquivo /etc/fstab. Caso a instância não tenha atualizações automáticas ativadas, use o seguinte processo para corrigi-la:

  1. Conecte-se à instância usando SSH. Se a conexão falhar, pode ser que a instância esteja travada no modo somente leitura. No entanto, é possível tentar recuperá-la. Caso você tenha se conectado à instância afetada por SSH antes, suas chaves SSH públicas já estarão no sistema de arquivos raiz e continuarão a funcionar. Execute um comando remoto por ssh para reativar o sistema de arquivos no modo rw. Por exemplo, use o seguinte comando gcloud para ativar o sistema de arquivos raiz:

    gcloud compute ssh [INSTANCE_NAME] --command "sudo mount -o remount,rw /dev/sda1 /"
    

    Depois que o sistema de arquivos for ativado no modo de leitura e gravação novamente, conecte-se à instância por SSH.

  2. Execute sudo yum -y update para atualizar todos os pacotes instalados, inclusive gce-disk-expand, que contém a correção.

Agora a instância pode ser reinicializada sem ativar o sistema de arquivos raiz no modo somente leitura.

Instâncias criadas usando imagens do RHEL 7 geradas antes de rhel-7-v20160418 ou imagens do CentOS 7 geradas antes de centos-7-v20160418:

  1. Conecte-se à instância usando SSH. Se a conexão falhar, pode ser que a instância esteja travada no modo somente leitura. No entanto, é possível tentar recuperá-la. Caso você tenha se conectado à instância afetada por SSH antes, suas chaves SSH públicas já estarão no sistema de arquivos raiz e continuarão a funcionar. Execute um comando remoto por ssh para reativar o sistema de arquivos no modo rw. Por exemplo, use o seguinte comando gcloud para ativar o sistema de arquivos raiz:

    gcloud compute ssh [INSTANCE_NAME] --command "sudo mount -o remount,rw /dev/sda1 /"
    

    Depois que o sistema de arquivos for ativado no modo de leitura e gravação novamente, conecte-se à instância por SSH.

  2. Edite o arquivo /etc/fstab e remova todas as opções de ativação barrier=1 nesse arquivo. default precisa ser a única opção de ativação definida para a entrada do sistema de arquivos raiz. Para corrigir essa opção de ativação inválida, use o seguinte comando:

    sudo sed -i 's/defaults,barrier[^ ,]*/defaults/' /etc/fstab
    

    Depois que você remover a opção de ativação barrier=1, a entrada do sistema de arquivos raiz no arquivo /etc/fstab precisará ser semelhante ao exemplo abaixo, mas com um valor diferente para o UUID:

    UUID=b5e54172-67e3-4d52-95f4-4314e71b25fd / xfs defaults 0 0
    

Agora a instância pode ser reinicializada sem ativar o sistema de arquivos raiz no modo somente leitura.

Alteração interruptiva na imagem do CentOS v20131120 que faz o iptables ser ativado por padrão

A versão v20131120 da imagem do CentOS 6, centos-6-v20131120, sofre uma alteração interruptiva que faz o iptables ser ativado por padrão. Isso impede que o tráfego externo alcance instâncias do CentOS que executam centos-6-v20131120, mesmo quando há um recurso de regra de firewall relevante que permite a conexão.

Como solução alternativa, os usuários podem desativar ou atualizar o iptables para permitir a conexão desejada, além de permitir o tráfego usando regras de firewall. Para desabilitar o iptables, execute os seguintes comandos:

# Save your iptable settings
user@centos-instance:~$ sudo service iptables save
# Stop the iptables service
user@centos-instance:~$ sudo service iptables stop
# Disable iptables on start up
user@centos-instance:~$ sudo chkconfig iptables off

Imagens fornecidas pelo Google têm um bug conhecido com o driver ext4/scsi nos kernels estáveis do Debian e do CentOS

Para imagens centos-6-v20131120 e debian-7-wheezy-v20131120, um bug ext4 conhecido pode causar um vazamento de memória e a falha de uma instância de máquina virtual sob o disco permanente com carga pesada. Para detalhes, veja a pergunta sobre a linha de execução de tempo excessivo do ext4 na lista de e-mails do kernel do Linux.

Nomes de instância com mais de 32 caracteres podem causar problemas com várias ferramentas do UNIX

Informado em: junho de 2012

O limite para nomes de instância ser de até 63 caracteres, mas nomes com mais de 32 caracteres podem causar instabilidade em algumas ferramentas, inclusive naquelas que são executadas durante a inicialização. Como alternativa, escolha nomes de instância com menos de 32 caracteres.

Instâncias que usam o login do SO retornam uma mensagem de login após a conexão

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

Ignore a mensagem de erro.

Problemas conhecidos de instâncias de VM do Windows

  • As instâncias do Windows podem usar a interface NVMe com SSD local. No entanto, a compatibilidade com NVMe no Windows está na versão Beta, o que nos impede de garantir o mesmo desempenho verificado nas instâncias do Linux.
  • No Windows Server 2008 R2, a instalação do Python 2.7.9 ou posterior requer o Visual C++. O Python 2.7.8 evita essa dependência, mas recomendamos instalar a versão mais recente.
  • O Compute Engine ainda não aceita IPv6. Mesmo que você ative o IPv6 selecionando a opção em uma instância do Windows, a definição será ignorada.
  • Depois de criar uma instância, não será 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.