Problemas conhecidos

Nesta página, descrevemos os problemas conhecidos que você pode encontrar ao usar o Compute Engine.

Problemas conhecidos de instâncias de VMs do Linux

Veja a seguir problemas conhecidos nas imagens do Linux:

Erro GPG: EXPKEYSIG 3746C208A7317B0F ao atualizar pacotes

Nos sistemas baseados em Debian e Ubuntu, incluindo suas estações de trabalho locais, você pode 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 solucionar o erro, adquira a chave apt-key.gpg mais recente válida em https://packages.cloud.google.com:

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

Como alternativa, nas instâncias de VM do Compute Engine que executam imagens do Debian ou do Ubuntu, você pode adquirir as chaves mais recentes se recriar suas instâncias usando as seguintes versões de imagem:

  • Projeto de imagem debian-cloud:
    • debian-9-stretch-v20180401 ou família de imagem debian-9
    • debian-8-jessie-v20180401 ou família de imagem debian-8
  • Projeto de imagem ubuntu-os-cloud:
    • ubuntu-1710-artful-v20180315 ou família de imagem ubuntu-1710
    • ubuntu-1604-xenial-v20180323 ou família de imagem ubuntu-1604-lts
    • ubuntu-1404-trusty-v20180308 ou família de imagem 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 e anteriores ou centos-7-v20170719 e anteriores podem inicializar 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 apresentarão falha.

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 instâncias afetadas:

Identifique as instâncias potencialmente afetadas com os seguintes comandos da 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, é possível corrigi-la com o seguinte processo:

  1. Conecte-se à instância usando SSH. Se a conexão falhar, poder 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, é possível usar este comando da gcloud para reativar 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 criadas antes de rhel-7-v20160418 ou imagens do CentOS 7 criadas antes de centos-7-v20160418:

  1. Conecte-se à instância usando SSH. Se a conexão falhar, poder 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, é possível usar este comando da gcloud para reativar 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 desse arquivo. A opção de ativação default precisa ser a única 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á ter uma aparência semelhante à do 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 inválida na imagem v20131120 do CentOS quando a opção iptables é ativada por padrão.

A versão v20131120 da imagem do CentOS 6, centos-6-v20131120, tem uma alteração interruptiva em que as iptables são ativadas por padrão. Isso impede que as instâncias do CentOS que executam centos-6-v20131120 sejam alcançadas pelo tráfego externo, mesmo quando há um recurso de regra de firewall relevante que permite a conexão.

Como alternativa, os usuários desativam ou atualizam a opção iptables para possibilitar a conexão, além de concederem acesso ao tráfego com as regras de firewall. Para desativar as iptables, execute:

# 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 erro ext4 conhecido pode causar um vazamento de memória e a falha de uma instância de máquina virtual sob carga pesada do disco permanente. Para mais detalhes, veja este tópico da lista de e-mails do kernel Linux.

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

Informado em: junho de 2012

Apesar de o limite para nomes de instância ser de até 63 caracteres, nomes maiores que 32 caracteres podem causar instabilidade em algumas ferramentas, inclusive naquelas usadas 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 VMs do Windows

Veja a seguir problemas conhecidos das imagens do Windows:

  • As instâncias do Windows podem usar a interface NVMe com SSD local. Porém, 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 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 é compatível com IPv6. Mesmo se você ativar o IPv6 selecionando a opção em uma instância do Windows, a definição será ignorada.
  • Após a criação de uma nova 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.
  • Não é possível ativar as imagens do Windows Server sem uma conexão de rede para kms.windows.googlecloud.com. Elas deixarão de funcionar se não forem autenticadas inicialmente em 30 dias. O software ativado pelo KMS precisa ser reativado a cada 180 dias, mas o KMS tenta reativar a cada 7 dias. Crie um IP externo para as instâncias do Windows para que seja possível autenticá-las periodicamente.
  • 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.
Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Compute Engine