Problemas conhecidos

Nesta página, você verá os problemas conhecidos que podem ser encontrados ao usar o Compute Engine.

Problemas conhecidos de instâncias de VMs do Linux

Os seguintes problemas conhecidos estão relacionados às imagens 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 seguinte comando:

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

Bug conhecido com o driver ext4/scsi nos kernels estáveis do Debian e do CentOS em imagens fornecidas pelo Google

Em imagens centos-6-v20131120 e debian-7-wheezy-v20131120, um bug ext4 conhecido pode causar vazamento de memória e eventual falha de uma instância de máquina virtual em discos permanentes muito carregados. 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.

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, é possível que você receba a seguinte mensagem de erro depois que a conexão for estabelecida:

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

Ignore a mensagem de erro.

Problemas conhecidos de instâncias de VMs do Windows

Os seguintes problemas conhecidos estão relacionados a imagens 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 configuração será ignorada.
  • 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 de Preparação do Sistema (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 (em inglês) sem emulação gera falhas de proteção geral. Dependendo do sistema operacional convidado, isso pode causar falha no sistema.