Problemas conhecidos

Esta página descreve problemas conhecidos que pode encontrar ao usar o Compute Engine. Para problemas que afetam especificamente as Confidential VMs, consulte as limitações das Confidential VMs.

Problemas gerais

Os problemas seguintes fornecem orientações de resolução de problemas ou informações gerais.

Resolvido: a modificação das IOPS ou da taxa de transferência num disco principal de replicação assíncrona através do comando gcloud compute disks update provoca um erro falso

O seguinte problema foi resolvido a 1 de junho de 2025.

Quando usa o comando gcloud compute disks update para modificar os IOPS e o débito num disco principal de replicação assíncrona, a CLI gcloud mostra uma mensagem de erro, mesmo que a atualização tenha sido bem-sucedida.

Para verificar com precisão se uma atualização foi bem-sucedida, use a CLI gcloud ou a consola para ver se as propriedades do disco mostram os novos valores de IOPS e débito. Google Cloud Para mais informações, consulte o artigo Veja as definições de desempenho aprovisionadas para o Hyperdisk.

O servidor de metadados pode apresentar metadados de VMs physicalHost antigos

Após ocorrer um erro do anfitrião que move uma instância para um novo anfitrião, quando consulta o servidor de metadados, este pode apresentar os metadados physicalHost do anfitrião anterior da instância.

Para contornar este problema, faça uma das seguintes ações:

Os valores baseInstanceName longos em grupos de instâncias geridas (MIGs) podem causar conflitos de nomes de discos

Num MIG, podem ocorrer conflitos de nomes de discos se o modelo de instância especificar discos a criar no momento da criação da VM e o valor baseInstanceName exceder 54 carateres. Isto acontece porque o Compute Engine gera nomes de discos com o nome da instância como prefixo.

Quando gera nomes de discos, se o nome resultante exceder o limite de 63 carateres do nome do recurso, o Compute Engine trunca os carateres em excesso a partir do final do nome da instância. Este corte pode levar à criação de nomes de discos idênticos para instâncias que tenham padrões de nomenclatura semelhantes. Nesse caso, a nova instância tenta anexar o disco existente. Se o disco já estiver anexado a outra instância, a criação da nova instância falha. Se o disco não estiver anexado ou estiver no modo de vários escritores, a nova instância anexa o disco, o que pode levar à danificação de dados.

Para evitar conflitos de nomes de discos, mantenha o valor baseInstanceName com um comprimento máximo de 54 carateres.

A criação de reservas ou pedidos de reserva futuros através de um modelo de instância que especifica um tipo de máquina A2, C3 ou G2 causa problemas

Se usar um modelo de instância que especifique um tipo de máquina A2, C3 ou G2 para criar uma reserva ou para criar e enviar um pedido de reserva futuro para revisão, vai ter problemas. Em concreto:

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

    • Se criou uma reserva consumida automaticamente (predefinição), a criação de VMs com propriedades correspondentes não consome a reserva.

    • Se criou uma reserva específica, a criação de VMs para segmentar especificamente a reserva falha.

  • A criação do pedido de reserva futura é bem-sucedida. No entanto, se o enviar para revisão, Google Cloud recusa o seu pedido.

Não pode substituir o modelo de instância usado para criar uma reserva ou um pedido de reserva futuro, nem substituir as propriedades de VM do modelo. Se quiser reservar recursos para tipos de máquinas A2, C3 ou G2, faça uma das seguintes ações em alternativa:

Limitações ao usar tipos de máquinas -lssd com o Google Kubernetes Engine

Quando usar a API Google Kubernetes Engine, o node pool com SSD local anexado que aprovisiona tem de ter o mesmo número de discos SSD que o tipo de máquina C4, C3 ou C3D selecionado. Por exemplo, se planear criar uma VM que use o c3-standard-8-lssd, tem de haver 2 discos SSD, enquanto que para um c3d-standard-8-lssd, basta 1 disco SSD. Se o número do disco não corresponder, recebe um erro de configuração incorreta do SSD local do plano de controlo do Compute Engine. Consulte os tipos de máquinas que associam automaticamente discos SSD locais para selecionar o número correto de discos SSD locais com base no lssdtipo de máquina.

A utilização da consola do Google Kubernetes Engine Google Cloud para criar um cluster ou um node pool com VMs c4-standard-*-lssd, c4-highmem-*-lssd, c3-standard-*-lssd e c3d-standard-*-lssd resulta na falha da criação de nós ou na falha da deteção de SSDs locais como armazenamento efémero.

Variabilidade da taxa de transferência TCP de fluxo único em VMs C3D

As VMs C3D com mais de 30 vCPUs podem sofrer variabilidade no débito TCP de fluxo único e, ocasionalmente, ficar limitadas a 20 a 25 Gbps. Para alcançar taxas mais elevadas, use vários fluxos TCP.

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

Se a CPU da sua VM usar um thread por núcleo, a métrica de observabilidade de utilização da CPU do Cloud Monitoring no separadorCompute Engine > Instâncias de VM > Observabilidade só é dimensionada até 50%. Dois threads por núcleo é a predefinição para todos os tipos de máquinas, exceto o Tau T2D. Para mais informações, consulte o artigo Defina o número de threads por núcleo.

Para ver a utilização da CPU da VM normalizada para 100%, veja a utilização da CPU no Explorador de métricas. Para mais informações, consulte o artigo Crie gráficos com o explorador de métricas.

As ligações SSH no navegador da consolaGoogle Cloud podem falhar se usar regras de firewall personalizadas

Se usar regras de firewall personalizadas para controlar o acesso SSH às suas instâncias de VM, pode não conseguir usar a funcionalidade SSH no navegador.

Para contornar este problema, efetue uma das seguintes ações:

Nomes temporários para discos

Durante as atualizações de instâncias de máquinas virtuais (VMs) iniciadas através do comando gcloud compute instances update ou do método da API instances.update, o Compute Engine pode alterar temporariamente o nome dos discos da VM, adicionando um dos 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.

Aumento da latência para alguns discos persistentes causado pelo redimensionamento do disco

Em alguns casos, redimensionar discos persistentes grandes (~3 TB ou mais) pode interromper o desempenho de E/S do disco. Se for afetado por este problema, os seus discos persistentes podem sofrer um aumento da latência durante a operação de redimensionamento. Este problema pode afetar discos persistentes de qualquer tipo.

Os seus processos automatizados podem falhar se usarem dados de resposta da API sobre as quotas de compromisso baseadas em recursos

Os seus processos automatizados que consomem e usam dados de resposta da API sobre as suas quotas de compromisso baseadas em recursos do Compute Engine podem falhar se ocorrerem as seguintes situações. Os seus processos automatizados podem incluir quaisquer fragmentos de código, lógica empresarial ou campos da base de dados que usem ou armazenem as respostas da API.

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

  2. Usa um int em vez de um number para definir o campo para o limite de quota de recursos nos corpos das respostas da API. Pode encontrar o campo das seguintes formas para cada método:

  3. Tem uma quota predefinida ilimitada disponível para qualquer uma das suas SKUs comprometidas do Compute Engine.

    Para mais informações sobre as quotas para compromissos e SKUs comprometidos, consulte o artigo Quotas para compromissos e recursos comprometidos.

Motivo principal

Quando tem uma quota limitada, se definir o campo items[].quotas[].limit ou quotas[].limit como um tipo int, os dados de resposta da API para os limites da sua quota podem continuar a estar dentro do intervalo do tipo int e o seu processo automatizado pode não ser interrompido. No entanto, quando o limite de quota predefinido é ilimitado, a API Compute Engine devolve um valor para o campo limit que está fora do intervalo definido pelo tipo int. O seu processo automatizado não consegue usar o valor devolvido pelo método da API e, consequentemente, falha.

Como contornar este problema

Pode contornar este problema e continuar a gerar os seus relatórios automatizados das seguintes formas:

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

  • Diminua o limite da quota para um valor inferior a 9 223 372 036 854 775 807. Tem de definir limites máximos de quota para todos os projetos que tenham compromissos baseados em recursos, em todas as regiões. Pode fazê-lo de uma das seguintes formas:

Problemas conhecidos para instâncias bare metal

Seguem-se os problemas conhecidos para instâncias bare metal do Compute Engine.

O C4D bare metal não suporta imagens do SUSE Linux 15 SP6

As instâncias bare metal C4D não podem executar o SO SUSE Linux Enterprise Server (SLES) versão 15 SP6.

Solução alternativa

Em alternativa, use o SLES 15 SP5.

A simulação da manutenção do anfitrião não funciona para instâncias de metal nu C4

Os tipos de máquinas c4-standard-288-metal e c4-highmem-288-metal não suportam a simulação de eventos de manutenção do anfitrião.

Alternativa

Pode usar instâncias de VM criadas com outros tipos de máquinas C4 para simular eventos de manutenção.

  1. Crie uma instância de VM com um tipo de máquina C4 que não termine em -metal.

    Quando criar a instância da VM, configure a VM C4 para Terminate em vez de usar a migração em direto durante os eventos de manutenção do anfitrião.

  2. Simule um evento de manutenção do anfitrião para esta VM.

Durante um evento de manutenção do anfitrião simulado, o comportamento das VMs configuradas para terminar é o mesmo que o das instâncias de metal sem SO C4.

Desempenho inferior ao esperado com instâncias bare metal Z3 no RHEL 8

Quando usa a versão 8 do Red Hat Enterprise Linux (RHEL) com uma instância de hardware físico Z3, o desempenho da rede é inferior ao esperado.

Motivo principal

Existe uma funcionalidade Page Pool em falta na versão do kernel do Linux (4.18) que é usada pelo RHEL 8.

Alternativa

Use uma versão mais recente do RHEL ou um sistema operativo diferente quando estiver a trabalhar com instâncias bare metal Z3.

Problemas relacionados com a utilização de interfaces de rede dinâmicas

Esta secção descreve problemas conhecidos relacionados com a utilização de várias interfaces de rede e interfaces de rede dinâmicas.

Perda de pacotes com tamanhos de MTU personalizados

Uma NIC dinâmica com uma vNIC principal pode sofrer perda de pacotes com tamanhos de MTU personalizados.

Alternativa

Para evitar a perda de pacotes, use um dos seguintes tamanhos de MTU:

  • 1460 bytes (o valor predefinido para redes VPC)
  • 1500 bytes (Ethernet padrão)
  • 8896 bytes (o valor máximo possível)

Interações da firewall quando reutiliza um ID de VLAN com NICs dinâmicos

Numa instância, a reutilização de um ID de VLAN para uma nova NIC dinâmica tem implicações no acompanhamento da ligação da firewall. Se eliminar uma NIC dinâmica e criar uma NIC dinâmica de substituição que use o mesmo ID da VLAN, as entradas da tabela de monitorização da ligação da firewall não são limpas automaticamente. O exemplo seguinte mostra as considerações de segurança relevantes:

  1. Uma instância de computação tem uma NIC dinâmica de exemplo com o ID da VLAN 4 ligada a uma sub-rede na rede da VPC network-1.
  2. A instância envia pacotes para o endereço IP de destino 192.0.2.7:443 e a porta de destino. As regras de firewall de saída aplicáveis permitem a ligação de saída.
  3. Uma vez que as regras da NGFW da nuvem têm estado, a ligação de saída permitida cria uma entrada na tabela de monitorização de ligações da firewall que permite pacotes de entrada do endereço IP de origem e da porta de origem 192.0.2.7:443.
  4. Elimina a NIC dinâmica de exemplo e cria uma NIC dinâmica de substituição. A NIC dinâmica de substituição também usa o ID da VLAN 4, mas liga-se a uma sub-rede numa rede VPC diferente, network-2.
  5. Todas as entradas da tabela de acompanhamento de ligações da firewall não expiradas que eram aplicáveis à NIC dinâmica original são aplicáveis à NIC dinâmica de substituição. Isto significa que um recurso na rede VPC pode enviar pacotes cujas origens correspondem a 192.0.2.7:443 e a instância de computação aceita-os sem ter de avaliar as regras de firewall de entrada.network-2

Para mais informações sobre a monitorização de ligações e as regras de firewall, consulte as especificações na documentação da firewall de nova geração do Google Cloud.

Solução

Por instância, se precisar de criar uma NIC dinâmica que use o mesmo ID de VLAN que uma NIC dinâmica removida da instância:

  • Aguarde, pelo menos, 10 minutos entre a eliminação da NIC dinâmica original e a criação da NIC dinâmica de substituição.
  • Pare a instância, elimine a NIC dinâmica original e crie a NIC dinâmica de substituição e, em seguida, inicie a instância.

A interceção de pacotes pode resultar em pacotes perdidos devido à falta de etiquetas VLAN nos cabeçalhos Ethernet

A interceção de pacotes quando usa a NIC dinâmica pode resultar em pacotes perdidos. A perda de pacotes pode ocorrer quando o pipeline é terminado prematuramente. O problema afeta os modos baseados em sessões e não baseados em sessões.

Motivo principal

Os pacotes rejeitados ocorrem durante a interceção de pacotes quando o pipeline é terminado antecipadamente (interceção de entrada e reinjeção de saída). O encerramento antecipado faz com que o ID da VLAN esteja em falta no cabeçalho Ethernet do pacote de entrada. Uma vez que o pacote de saída é derivado do pacote de entrada modificado, o pacote de saída também não tem o ID de VLAN. Isto leva a uma seleção incorreta do índice do ponto final e a perdas de pacotes subsequentes.

Alternativa

Não use Google Cloud funcionalidades que dependam da interceção de pacotes, como endpoints de firewall.

Problemas conhecidos para instâncias de VM do Linux

Seguem-se os problemas conhecidos para VMs do Linux.

As VMs Debian 11 que usam a versão da imagem do SO anterior à v20250728 não conseguem executar a atualização apt

A 22 de julho de 2025, a comunidade Debian removeu as portas posteriores do Debian 11 (Bullseye) do upstream principal do Debian. Esta atualização faz com que o comando sudo apt update falhe com o seguinte erro:

The repository 'https://deb.debian.org/debian bullseye-backports Release' does
not have a Release file.

Motivo principal

Uma vez que a comunidade Debian removeu os repositórios de backports do upstream principal, já não existe qualquer referência ao bullseye-backports Release.

Resolução

Use a versão debian-11-bullseye-v20250728 ou mais recente da imagem. Estas versões não contêm os repositórios de backports. Em alternativa, pode atualizar as instâncias atuais modificando /etc/apt/sources.list:

  • Para atualizar o URL do repositório e usar o arquivo para bullseye-backports:

    sudo sed -i 's/^deb https:\/\/deb.debian.org\/debian bullseye-backports main$/deb https:\/\/archive.debian.org\/debian bullseye-backports main/g; s/^deb-src https:\/\/deb.debian.org\/debian bullseye-backports main$/deb-src https:\/\/archive.debian.org\/debian bullseye-backports main/g' /etc/apt/sources.list

  • Para eliminar o URL do repositório e rejeitar bullseye-backports:

    sudo sed -i '/^deb https:\/\/deb.debian.org\/debian bullseye-backports main$/d; /^deb-src https:\/\/deb.debian.org\/debian bullseye-backports main$/d' /etc/apt/sources.list

As VMs do Ubuntu que usam a versão da imagem do SO v20250530 mostram o FQDN incorreto

Pode ver um nome de domínio totalmente qualificado (FQDN) incorreto com a adição do sufixo .local quando faz uma das seguintes ações:

  • Atualize para a versão 20250328.00 do pacote google-compute-engine.
  • Inicie instâncias a partir de qualquer imagem do Ubuntu oferecida pela Canonical com o sufixo v20250530 da versão. Por exemplo, projects/ubuntu-os-cloud/global/images/ubuntu-2204-jammy-v20250530.

Se tiver este problema, pode ver um NQD semelhante ao seguinte:

   [root@ubuntu2204 ~]# apt list --installed | grep google
   ...
   google-compute-engine/noble-updates,now 20250328.00-0ubuntu2~24.04.0 all [installed]
   ...

   [root@ubuntu2204 ~]# curl "http://metadata.google.internal/computeMetadata/v1/instance/image" -H "Metadata-Flavor: Google"
   projects/ubuntu-os-cloud/global/images/ubuntu-2204-jammy-v20250530

   [root@ubuntu2204 ~]# hostname -f
   ubuntu2204.local

Motivo principal

Em todas as imagens do Ubuntu com a versão v20250530, a versão guest-config do pacote 20250328.00 adiciona local ao caminho de pesquisa devido à introdução de um novo ficheiro de configuração: https://github.com/GoogleCloudPlatform/guest-configs/blob/20250328.00/src/etc/systemd/resolved.conf.d/gce-resolved.conf

   [root@ubuntu2204 ~]# cat /etc/resolv.conf
   # This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
   # Do not edit.
   ...

   nameserver 127.0.0.53
   options edns0 trust-ad
   search local ... google.internal

A presença desta entrada local no caminho de pesquisa no ficheiro /etc/resolv.conf resulta na anexação de um elemento .local ao nome do anfitrião quando é pedido um FQDN.

Tenha em atenção que a versão 20250501 de guest-configs já corrige o problema, mas a Canonical ainda não incorporou a correção nas respetivas imagens.

Alternativa

  1. Modifique o ficheiro de configuração de resolução de nomes de rede /etc/systemd/resolved.conf.d/gce-resolved.conf alterando Domains=local para Domains=~local
  2. Execute o seguinte comando para reiniciar o serviço systemd-resolved: systemctl restart systemd-resolved
  3. Verifique se local foi removido do caminho de pesquisa em /etc/resolv.conf

  4. Confirme o FQDN através do comando hostname -f

    [root@ubuntu2204 ~]# hostname -f
ubuntu2204.us-central1-a.c.my-project.internal

mkfs.ext4 em falta nas imagens do openSUSE

A versão v20250724 recente de imagens do openSUSE (a partir de opensuse-leap-15-6-v20250724-x86-64) de agosto de 2025 não tem o pacote e2fsprogs, que fornece utilitários para gerir sistemas de ficheiros. Um sintoma comum deste problema é a apresentação de uma mensagem de erro, como command not found, quando tenta usar o comando mkfs.ext4.

Alternativa

Se encontrar este problema, instale o pacote em falta manualmente através do gestor de pacotes do openSUSE, zypper.

# Update the package index
user@opensuse:~> sudo zypper refresh

# Install the e2fsprogs package
user@opensuse:~> sudo zypper install e2fsprogs

# Verify the installation
user@opensuse:~> which mkfs.ext4

As VMs do SUSE Enterprise não arrancam após a alteração dos tipos de instâncias

Depois de alterar o tipo de instância de uma VM do SUSE Linux Enterprise, o arranque pode falhar com o seguinte erro repetido na consola série:

            Starting [0;1;39mdracut initqueue hook[0m...
   [  136.146065] dracut-initqueue[377]: Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks:
   [  136.164820] dracut-initqueue[377]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2fD3E2-0CEB.sh: "[ -e "/dev/disk/by-uuid/D3E2-0CEB" ]"
   [  136.188732] dracut-initqueue[377]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2fe7b218a9-449d-4477-8200-a7bb61a9ff4d.sh: "if ! grep -q After=remote-fs-pre.target /run/systemd/generator/systemd-cryptsetup@*.service 2>/dev/null; then
   [  136.220738] dracut-initqueue[377]:     [ -e "/dev/disk/by-uuid/e7b218a9-449d-4477-8200-a7bb61a9ff4d" ]
   [  136.240713] dracut-initqueue[377]: fi"

Motivo principal

A SUSE cria as respetivas imagens na nuvem com um initramfs (sistema de ficheiros RAM inicial) versátil que suporta vários tipos de instâncias. Isto é conseguido através das flags --no-hostonly --no-hostonly-cmdline -o multipath durante a criação inicial da imagem. No entanto, quando é instalado um novo kernel ou o initramfs é regenerado, o que acontece durante as atualizações do sistema, estas flags são omitidas por predefinição. Isto resulta num initramfs especificamente adaptado ao hardware do sistema atual, excluindo potencialmente os controladores necessários para outros tipos de instâncias.

Por exemplo, as instâncias C3 usam unidades NVMe, que requerem módulos específicos a incluir no initramfs. Se um sistema com um initramfs que não tenha estes módulos NVMe for migrado para uma instância C3, o processo de arranque falha. Este problema também pode afetar outros tipos de instâncias com requisitos de hardware exclusivos.

Alternativa

Antes de alterar o tipo de máquina, regenere o initramfs com todos os controladores:

dracut --force --no-hostonly

Se o sistema já estiver afetado pelo problema, crie uma VM de recuperação temporária. Use o comando chroot para aceder ao disco de arranque da VM afetada e, em seguida, regenere o initramfs com o seguinte comando:

dracut -f --no-hostonly

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

As VMs Z3 em imagens do SUSE Linux Enterprise Server (SLES) 12 têm um desempenho significativamente inferior ao esperado para IOPS em discos SSD locais.

Motivo principal

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

Alternativa

Não está disponível nem planeada uma correção da SUSE para resolver este problema. Em alternativa, deve usar o sistema operativo SLES 15.

As VMs do RHEL 7 e do CentOS perdem o acesso à rede após o reinício

Se as suas VMs do CentOS ou RHEL 7 tiverem várias placas de interface de rede (NICs) e uma destas NICs não usar a interface VirtIO, o acesso à rede pode ser perdido no reinício. Isto acontece porque o RHEL não suporta a desativação de nomes de interfaces de rede previsíveis se, pelo menos, uma NIC não usar a interface VirtIO.

Resolução

Pode restaurar a conetividade de rede parando e iniciando a VM até o problema ser resolvido. Pode evitar a recorrência da perda de conetividade de rede fazendo o seguinte:

  1. Edite o ficheiro /etc/default/grub e remova os parâmetros do kernel net.ifnames=0 e biosdevname=0.

  2. Volte a gerar a configuração do GRUB.

  3. Reinicie a VM.

Não foi possível validar a assinatura de repomd.xml

Em sistemas baseados no Red Hat Enterprise Linux (RHEL) ou no CentOS 7, pode ver o seguinte erro ao tentar instalar ou atualizar software através do yum. Este erro mostra que tem uma chave GPG do repositório expirada ou incorreta.

Exemplo de registo:

[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 este problema, desative a verificação da chave GPG do repositório na configuração do repositório yum definindo repo_gpgcheck=0. Nas imagens base do Compute Engine suportadas, esta definição pode ser encontrada no ficheiro /etc/yum.repos.d/google-cloud.repo. No entanto, a VM pode ter esta definição em diferentes ficheiros de configuração do repositório ou ferramentas de automatização.

Normalmente, os repositórios Yum não usam chaves GPG para validação de repositórios. Em alternativa, o ponto final https é fidedigno.

Para localizar e atualizar esta definição, conclua os seguintes passos:

  1. Procure a definição no ficheiro /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 definição está 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

As instâncias que usam o Início de sessão do SO devolvem uma mensagem de início de sessão após a ligação

Em algumas instâncias que usam o início de sessão do SO, pode receber a seguinte mensagem de erro após o estabelecimento da ligação:

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

Resolução

Ignorar a mensagem de erro.

Problemas conhecidos para instâncias de VM do Windows

  • O suporte para NVMe no Windows através do controlador NVMe da comunidade está em versão beta, e o desempenho pode não corresponder ao das instâncias do Linux. O controlador NVMe da comunidade foi substituído pelo controlador StorNVMe da Microsoft em Google Cloud imagens públicas. Recomendamos que substitua o controlador NVME nas VMs criadas antes de maio de 2022 e use o controlador Microsoft StorNVMe em alternativa.
  • Depois de criar uma instância, não pode estabelecer ligação à mesma instantaneamente. Todas as novas instâncias do Windows usam a ferramenta System preparation (sysprep) para configurar a sua instância, o que pode demorar 5 a 10 minutos a concluir.
  • As imagens do Windows Server não podem ser ativadas sem uma ligação de rede a kms.windows.googlecloud.com e deixam de funcionar se não forem autenticadas inicialmente no prazo de 30 dias. O software ativado pelo KMS tem de ser reativado a cada 180 dias, mas o KMS tenta reativá-lo a cada 7 dias. Certifique-se de que configura as suas instâncias do Windows para que permaneçam ativadas.
  • O software de kernel que acede a registos específicos do modelo não emulados gera falhas de proteção geral, o que pode causar uma falha do sistema, dependendo do sistema operativo convidado.

Windows Server 2025 e Windows 11 24h2: suspensão e retoma do apoio técnico

O Windows Server 2025 e o Windows 11 24h2 não conseguem ser retomados quando são suspensos. Até este problema ser resolvido, a funcionalidade de suspensão e retoma não é suportada para o Windows Server 2025 e o Windows 11 24h2.

Erros ao medir a variação de tempo do NTP com o w32tm em VMs do Windows

Para VMs Windows no Compute Engine com NICs VirtIO, existe um erro conhecido em que a medição da variação do NTP produz erros quando usa o seguinte comando:

w32tm /stripchart /computer:metadata.google.internal

Os erros são semelhantes aos seguintes:

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

Este erro só afeta as VMs do Compute Engine com NICs VirtIO. As VMs que usam gVNIC não têm este problema.

Para evitar este problema, a Google recomenda a utilização de outras ferramentas de medição da variação do NTP, como o Meinberg Time Server Monitor.

Dispositivo de arranque inacessível após a atualização de uma VM de 1.ª ou 2.ª geração para uma VM de 3.ª geração ou superior

O Windows Server associa a unidade de arranque ao respetivo tipo de interface de disco inicial no primeiro arranque. Para alterar uma VM existente 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 do controlador PnP do Windows antes de encerrar a VM. Este sysprep apenas prepara os controladores de dispositivos e verifica se todos os tipos de interface de disco são analisados para a unidade de arranque no próximo início.

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

A partir de um comando do Powershell, execute o seguinte como Administrator:

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

Se a nova MV não for iniciada corretamente, altere a MV novamente para o tipo de máquina original para que a MV volte a ser executada. Deve iniciar com êxito. Reveja os requisitos de migração para verificar se os cumpre. Em seguida, repita as instruções.

Anexação de contagem de discos limitada para séries de máquinas de VMs mais recentes

As VMs executadas no Microsoft Windows com a interface de disco NVMe, que inclui T2A e todas as VMs de terceira geração, têm um limite de anexos de disco de 16 discos. Esta limitação não se aplica a VMs de quarta geração (C4 e M4). Para evitar erros, consolide o armazenamento de discos persistentes e Hyperdisk num máximo de 16 discos por VM. O armazenamento SSD local está excluído deste problema.

Substitua o controlador NVME em VMs criadas antes de maio de 2022

Se quiser usar NVMe numa VM que use o Microsoft Windows e a VM tiver sido criada antes de 1 de maio de 2022, tem de atualizar o controlador NVMe existente no SO convidado para usar o controlador Microsoft StorNVMe.

Tem de atualizar o controlador 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 uma captura instantânea do disco de arranque que vai ser usada para criar novas VMs que usam uma série de máquinas de terceira geração.

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

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

Desempenho inferior 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.

Estão em curso melhorias no desempenho.

Desempenho inferior para volumes Hyperdisk Extreme anexados a instâncias n2-standard-80 que executam o Microsoft Windows

As instâncias do Microsoft Windows em execução em tipos de máquinas n2-standard-80 podem atingir, no máximo, 80 000 IOPS em todos os volumes Hyperdisk Extreme anexados à instância.

Resolução

Para alcançar até 160 000 IOPS com instâncias N2 a executar o Windows, escolha um dos seguintes tipos de máquinas:

  • n2-highmem-80
  • n2-highcpu-80
  • n2-standard-96
  • n2-highmem-96
  • n2-highcpu-96
  • n2-highmem-128
  • n2-standard-128

Débito de rede fraco quando usa o gVNIC

As VMs do Windows Server 2022 e do Windows 11 que usam o pacote GooGet do controlador gVNIC versão 1.0.0@44 ou anterior podem ter um débito de rede fraco quando usam a NIC virtual da Google (gVNIC).

Para resolver este problema, atualize o pacote GooGet do controlador gVNIC para a versão 1.0.0@45 ou posterior fazendo o seguinte:

  1. Verifique que versão do controlador está instalada na sua VM executando o seguinte comando a partir de uma sessão do PowerShell ou da Linha de comandos de administrador:

    googet installed

    O resultado tem um aspeto semelhante ao seguinte:

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

  2. Se a google-compute-engine-driver-gvnic.x86_64versão do controlador for1.0.0@44 ou anterior, atualize o repositório de pacotes GooGet executando o seguinte comando a partir de uma sessão de Powershell ou de uma linha de comandos de administrador:

    googet update

Os tipos de máquinas de vCPU C4, C4D e C3D grandes não suportam imagens do SO Windows

Os tipos de máquinas C4 com mais de 144 vCPUs e os tipos de máquinas C4D e C3D com mais de 180 vCPUs não suportam imagens do SO Windows Server 2012 e 2016. Os tipos de máquinas C4, C4D e C3D maiores que usam imagens do SO Windows Server 2012 e 2016 não são iniciados. Para contornar este problema, selecione um tipo de máquina mais pequeno ou use outra imagem do SO.

As VMs C3D criadas com 360 vCPUs e imagens do SO Windows não são iniciadas. Para contornar este problema, selecione um tipo de máquina mais pequeno ou use outra imagem do SO.

As VMs C4D criadas com mais de 255 vCPUs e o Windows 2025 não vão arrancar. Para contornar este problema, selecione um tipo de máquina mais pequeno ou use outra imagem do SO.

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

A capacidade de adicionar ou redimensionar um Hyperdisk ou um disco persistente para uma VM M3, C3, C3D ou C4D em execução não funciona como esperado em convidados específicos do Windows neste momento. O Windows Server 2012 R2 e o Windows Server 2016, bem como as respetivas variantes do Windows não pertencentes a servidores, não respondem corretamente aos comandos de anexação e redimensionamento de disco.

Por exemplo, a remoção de um disco de uma VM M3 em execução desliga o disco de uma instância do Windows Server sem que o sistema operativo Windows reconheça que o disco foi removido. As escritas subsequentes no disco devolvem um erro genérico.

Resolução

Tem de reiniciar a VM M3, C3, C3D ou C4D que está a ser executada no Windows depois de modificar um Hyperdisk ou um disco persistente para que as modificações do disco sejam reconhecidas por estes convidados.