Problemas conhecidos


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

Problemas gerais

Mover VMs ou discos usando a API moveInstance ou a ferramenta 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 de forma consistente o limite máximo de desempenho de 100.000 IOPS. 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.

Latência maior em alguns discos permanentes devido a snapshots

O problema a seguir foi resolvido em 30 de março de 2021.

Em alguns casos, snapshots de discos permanentes grandes (aproximadamente 3 TB ou maiores) geram operações que podem ser prejudiciais para o desempenho de E/S deles. 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 acontecer com discos permanentes de qualquer tipo e pode ser causado por snapshots regulares ou programados.

Problemas conhecidos de instâncias de VMs do Linux

Não foi possível verificar a assinatura 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.

Repositórios 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
    

Erro GPG: EXPKEYSIG 3746C208A7317B0F ao atualizar pacotes

Em sistemas Debian e Ubuntu em que você instalou manualmente a ferramenta de linha de comando gcloud, incluindo a estação de trabalho local, é 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:

Sistemas Debian

Execute este comando:

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

Sistemas Ubuntu

Execute este comando:

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg 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

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

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.
  • 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.