Problemas conhecidos

Nesta página, descrevemos os problemas conhecidos que você pode encontrar ao usar instâncias do Compute Engine. Para problemas que afetam especificamente as VMs confidenciais, consulte Limitações de VMs confidenciais.

Problemas gerais

Os problemas a seguir fornecem orientações para solução de problemas ou informações gerais.

As instâncias do Compute com a Inicialização segura ativada podem não ser iniciadas

Em raras ocasiões, as instâncias de VM protegida criadas antes de 7 de novembro de 2025 com a inicialização segura ativada ou que usam software de criptografia de disco completo ou lacre secreto para PCRs do vTPM podem não inicializar. Isso pode ser causado por uma sequência incorreta de atualizações (por exemplo, atualizar o shim sem ter certificados adequados) após o vencimento dos certificados de inicialização segura da Microsoft no segundo semestre de 2026.

Resolução

Para resolver esse problema, atualize as instâncias de computação com os novos certificados. Para mais informações, consulte o guia de expiração dos certificados de inicialização segura da Microsoft.

Os discos SSD locais anexados às instâncias C4A, C4D, C4 e H4D podem não capturar todas as gravações em caso de perda de energia

Após uma perda de energia em um servidor host, se o Compute Engine conseguir recuperar os dados nos discos SSD locais, uma instância de computação em execução nesse servidor host será reiniciada com todos os discos anexados, e os dados incluirão todas as gravações concluídas antes do erro de host.

Para instâncias C4A, C4D, C4 e H4D, os discos SSD locais restaurados podem não incluir gravações concluídas imediatamente antes do evento de perda de energia. Quando a instância de computação é reiniciada, a leitura de um endereço de bloco lógico (LBA) afetado retorna um erro indicando que o LBA não pode ser lido. Se a instância de computação passar por uma reinicialização inesperada, verifique os registros de erros do SO para falhas de leitura ou gravação após a reinicialização.

A capacidade de processamento do Hyperdisk Throughput e do Hyperdisk Extreme consome cotas de Persistent Disk simultaneamente

Ao criar discos Hyperdisk Throughput ou Hyperdisk Extreme, a capacidade do disco é contabilizada em duas cotas separadas ao mesmo tempo: a cota específica do Hyperdisk e uma cota correspondente do Persistent Disk.

  • Hyperdisk Throughput Capacity (GB) (HDT-TOTAL-GB) também conta para sua cota de Persistent disk standard (GB) (DISKS-TOTAL-GB).
  • Hyperdisk Extreme Capacity (GB) (HDX-TOTAL-GB) também conta para sua cota de Persistent disk SSD (GB) (SSD-TOTAL-GB).

Se o limite de cota Persistent Disk for menor que o limite de cota do Hyperdisk, você vai encontrar erros QUOTA_EXCEEDED. Não é possível criar discos adicionais quando o limite do Persistent Disk é atingido, mesmo que você tenha cota restante do Hyperdisk disponível.

Para atenuar esse problema, ajuste as duas cotas sempre que solicitar um aumento. Ao ajustar a cota de HDT-TOTAL-GB ou HDX-TOTAL-GB, você também precisa ajustar a cota de DISKS-TOTAL-GB ou SSD-TOTAL-GB, respectivamente.

Interrupções de carga de trabalho em instâncias A4 devido a problemas de firmware em GPUs NVIDIA B200

A NVIDIA identificou dois problemas de firmware para GPUs B200, que são usadas por instâncias A4 e causam interrupções na carga de trabalho. Especificamente, se você notar interrupções de carga de trabalho em instâncias A4, verifique se uma das seguintes opções é verdadeira:

  • O tempo de atividade da instância de computação (campo lastStartTimestamp) excede 65 dias.
  • Os registros mostram uma mensagem Xid 149 que menciona 0x02a.

Para minimizar esse problema, redefina as GPUs. Para evitar o problema, redefina as GPUs nas instâncias A4 pelo menos uma vez a cada 60 dias.

Possíveis erros de host durante a criação de instâncias C4 em nós de locatário individual

As instâncias do tipo de máquina C4 executadas em nós de locatário único podem encontrar encerradas inesperadamente devido a erros de host ou falhas na criação de instâncias.

Para resolver esse problema, o Google limitou a 26 o número máximo de instâncias C4 permitidas por nó de locatário único.

O console serial é somente leitura para instâncias bare metal C4 e C4D

Não é possível ativar o acesso interativo ao console serial para instâncias bare metal C4 ou C4D. O console serial é somente leitura.

Alternativa

Para executar comandos de maneira interativa, conecte-se à instância usando SSH depois que ela for iniciada. Para informações sobre como usar SSH com instâncias do Compute Engine, consulte Sobre conexões SSH.

O cancelamento de jobs em clusters de HPC com 32 nós ou mais excede o tempo limite

Para jobs grandes em clusters de 32 nós ou mais, o tempo necessário para cancelar um job pode exceder o valor padrão de UnkillableStepTimeout, que é de 300 segundos. Exceder esse valor faz com que os nós afetados fiquem inutilizáveis para trabalhos futuros.

Para resolver esse problema, use um dos métodos a seguir:

  • Atualize o Cluster Toolkit para a versão 1.65.0 ou mais recente. Em seguida, reimplante o cluster usando o seguinte comando:

    gcluster deploy -w --force BLUEPRINT_NAME.yaml

  • Se não for possível atualizar o Cluster Toolkit ou reimplantar o cluster, modifique manualmente o parâmetro UnkillableStepTimeout seguindo estas etapas:

    1. Use SSH para se conectar ao nó do controlador principal do cluster.

      gcloud compute ssh --project PROJECT_ID --zone ZONE DEPLOYMENT_NAME-controller

      Para encontrar o nome e o endereço IP exatos do nó do controlador principal, use o console Google Cloud e navegue até a página Instâncias de VM.

    2. Crie um backup do arquivo cloud.conf atual. Esse arquivo geralmente está localizado em /etc/slurm/.

      sudo cp /etc/slurm/cloud.conf /etc/slurm/cloud.conf.backup-$(date +%Y%m%d)

    3. Usando privilégios de sudo, use um editor de texto para abrir o arquivo /etc/slurm/cloud.conf.

    4. Adicione ou modifique a linha que contém UnkillableStepTimeout. Por exemplo, defina o tempo limite como 900 segundos (15 minutos) da seguinte maneira:

      UnkillableStepTimeout=900

    5. Salve o arquivo.

    6. Use o comando sudo scontrol reconfigure para aplicar a nova configuração em todo o cluster sem precisar de uma reinicialização completa.

Verificar a correção

Para verificar se a configuração mudou, execute o seguinte comando:

   scontrol show config | grep UnkillableStepTimeout

A saída precisa refletir o novo valor definido, por exemplo: UnkillableStepTimeout = 900.

Resolvido: modificar as IOPS ou a capacidade de processamento em um disco principal de replicação assíncrona usando o comando gcloud compute disks update causa um erro falso

O problema a seguir foi resolvido em 1º de junho de 2025.

Ao usar o comando gcloud compute disks update para modificar as IOPS e a capacidade de processamento em um 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, confira as propriedades do disco usando a CLI gcloud ou o console do Google Cloud para ver os novos valores de IOPS e taxa de transferência. Para mais informações, consulte Ver as configurações de desempenho provisionadas para o Hyperdisk.

O servidor de metadados pode mostrar metadados de instância de computação physicalHost antigos.

Depois de um erro de host que move uma instância de computação para um novo host, quando você consulta o servidor de metadados, ele pode mostrar os metadados physicalHost do host anterior da instância.

Para resolver esse problema, siga uma destas etapas:

Valores baseInstanceName longos em grupos gerenciados de instâncias (MIGs) podem causar conflitos de nomes de disco

Em um MIG, conflitos de nomes de disco podem ocorrer se o modelo de instância especificar discos a serem criados na criação da instância de computação e o valor baseInstanceName exceder 54 caracteres. Isso acontece porque o Compute Engine gera nomes de disco usando o nome da instância como prefixo.

Ao gerar nomes de disco, se o nome resultante exceder o limite de 63 caracteres do nome do recurso, o Compute Engine vai truncar os caracteres excedentes do final do nome da instância. Esse truncamento pode levar à criação de nomes de disco idênticos para instâncias com padrões de nomenclatura semelhantes. Nesse caso, a nova instância vai tentar anexar o disco atual. Se o disco já estiver anexado a outra instância de computação, a criação da nova instância vai falhar. Se o disco não estiver anexado ou estiver no modo de gravação múltipla, a nova instância vai anexar o disco, o que pode levar à corrupção de dados.

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

Criar reservas ou solicitações futuras de reserva usando um modelo de instância que especifica um tipo de máquina A2, C3 ou G2 causa problemas

Você vai encontrar problemas ao usar um modelo de instância que especifica um tipo de máquina A2, C3 ou G2 para criar uma reserva ou para criar e enviar uma solicitação de reserva adiantada para análise. Especificamente, uma das seguintes situações pode acontecer:

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

    • Se você criou uma reserva consumida automaticamente (padrão), a criação de instâncias de computação com propriedades correspondentes não vai consumir a reserva.

    • Se você criou uma reserva específica, a criação de instâncias de computação para visar especificamente a reserva vai falhar.

  • A criação da solicitação de reserva adiantada foi bem-sucedida. No entanto, se você enviar para análise, o Google Cloud vai recusar sua solicitação.

Não é possível substituir o modelo de instância usado para criar uma reserva ou solicitação de reserva futura nem modificar as propriedades de instância do modelo. Se você quiser reservar recursos para os tipos de máquina A2, C3 ou G2, siga um destes procedimentos:

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

Ao usar a API Kubernetes Engine, o pool de nós provisionado com discos SSD locais precisa ter o mesmo número de discos SSD locais que o tipo de máquina C4, C3 ou C3D selecionado. Por exemplo, se você planeja criar uma instância de computação que usa o tipo de máquina c3-standard-8-lssd, é necessário ter dois discos SSD locais. Se você usar o tipo de máquina c3d-standard-8-lssd, apenas um disco será necessário. Se o número do disco não corresponder, você vai receber um erro de configuração do SSD local do plano de controle do Compute Engine. Consulte Tipos de máquina que anexam automaticamente discos SSD locais para selecionar o número correto de discos SSD locais com base no tipo de máquina lssd.

Se você usar o console do Google Kubernetes Engine Google Cloud para criar um cluster ou pool de nós, a criação do nó vai falhar ou os discos SSD locais não serão detectados como armazenamento temporário ao usar qualquer um dos seguintes tipos de máquina:

  • c4-standard-*-lssd
  • c4-highmem-*-lssd
  • c3-standard-*-lssd
  • c3d-standard-*-lssd

Variabilidade da capacidade de processamento de TCP de fluxo único em instâncias C3D

As instâncias C3D com mais de 30 vCPUs podem apresentar variação de capacidade de processamento de TCP de fluxo único e, às vezes, ser limitadas a 20 a 25 Gbps. Para alcançar taxas mais altas, use vários fluxos de TCP.

A métrica de observabilidade de utilização da CPU está incorreta para instâncias de computação que usam uma linha de execução por núcleo

Se a CPU da instância de computação usar uma linha de execução por núcleo, a métrica de utilização da CPU do Cloud Monitoring na guia Observabilidade* da página Instâncias de VM no console do Compute Engine Google Cloud só será dimensionada para 50%. Duas linhas de execução por núcleo são o padrão para a maioria dos tipos de máquinas. Para mais informações, consulte Definir número de linhas de execução por núcleo.

Para ver o uso de CPU da sua instância de computação normalizado em 100%, confira a utilização de CPU no Metrics Explorer. Para mais informações, consulte Criar gráficos com o Metrics Explorer.

As conexões SSH no navegador do console doGoogle Cloud podem falhar se você usar regras de firewall personalizadas

Se você usa regras de firewall personalizadas para controlar o acesso SSH às instâncias de computação, talvez não seja possível usar o recurso SSH no navegador.

Para resolver esse problema, siga uma destas etapas:

Nomes temporários para discos

Durante as atualizações de instâncias de computação iniciadas usando o comando gcloud compute instances update ou o método da API instances.update, o Compute Engine pode mudar temporariamente o nome dos discos da instância de computação, adicionando um dos seguintes sufixos ao nome original:

  • -temp
  • -old
  • -new

O Compute Engine remove o sufixo e restaura os nomes originais dos discos à 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.

Seus processos automatizados podem falhar se usarem dados de resposta da API sobre suas cotas de compromisso baseadas em recursos

Os processos automatizados que consomem e usam dados de resposta da API sobre suas cotas de compromisso baseadas em recursos do Compute Engine poderão falhar se cada uma das situações a seguir acontecer. Os processos automatizados podem incluir snippets de código, lógica de negócios ou campos de banco de dados que usam ou armazenam as respostas da API.

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

  2. Use int em vez de number para definir o campo do limite de cota de recurso nos corpos de resposta da API. É possível encontrar o campo das seguintes maneiras para cada método:

  3. Você tem uma cota padrão ilimitada disponível para qualquer uma das SKUs confirmadas do Compute Engine.

    Para mais informações sobre cotas de compromissos e SKUs confirmadas, consulte Cotas de compromissos e recursos confirmados.

Causa raiz

Quando você tem uma cota limitada, se definir o campo items[].quotas[].limit ou quotas[].limit como um tipo int, os dados de resposta da API para os limites de cota ainda poderão estar dentro do intervalo do tipo int e o processo automatizado não será interrompido. No entanto, quando o limite de cota padrão é ilimitado, a API Compute Engine retorna um valor para o campo limit que está fora do intervalo definido pelo tipo int. Seu processo automatizado não pode consumir o valor retornado pelo método da API e falha como resultado.

Como contornar esse problema

É possível contornar esse problema e continuar gerando relatórios automatizados das seguintes maneiras:

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

  • Reduza o limite da cota para um valor abaixo de 9.223.372.036.854.775.807. É preciso definir limites de cota para todos os projetos com compromissos baseados em recursos em todas as regiões. É possível fazer isso de uma das seguintes maneiras:

Problemas conhecidos das instâncias de GPU

A seção a seguir descreve os problemas conhecidos das instâncias de GPU do Compute Engine.

Os tipos de máquina com otimização para aceleradores que têm discos SSD locais anexados automaticamente podem levar horas para serem encerrados e reiniciados.

Os tipos de máquina com otimização para aceleradores têm GPUs anexadas automaticamente. A maioria dos tipos de máquina da série A otimizados para aceleradores, com exceção do A2 Standard, tem discos SSD locais anexados automaticamente.

Os tipos de máquina otimizados para aceleradores não são compatíveis com a migração em tempo real, e você precisa definir a política de manutenção do host como TERMINATE. Esses tipos de máquina podem levar até uma hora para serem encerrados após falhas ou erros de host. Para os tipos de máquinas otimizados para aceleradores que têm discos SSD locais anexados automaticamente, o processo de encerramento pode levar várias horas.

Erros de criação e desempenho reduzido ao usar NICs dinâmicas com instâncias de GPU

As NICs dinâmicas não são compatíveis com instâncias de GPU. Se você criar uma instância de GPU com NICs dinâmicas ou adicionar NICs dinâmicas a uma instância de GPU atual, os seguintes problemas poderão ocorrer:

  • A operação falha com um erro como este:

    Internal error. Please try again or contact Google Support. (Code: 'CODE')

  • A operação é concluída, mas a instância tem uma performance reduzida, como uma largura de banda da rede significativamente menor.

Esses problemas ocorrem porque a configuração de NIC dinâmica causa erros quando o Compute Engine tenta distribuir as vNICs da instância em NICs físicas no servidor host.

Problemas conhecidos de instâncias bare metal

Estes são os problemas conhecidos das instâncias bare metal do Compute Engine.

Os tipos de máquina bare metal C4D não são compatíveis com 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.

Alternativa

Use o SLES 15 SP5.

A simulação de manutenção do host não funciona para instâncias bare metal C4

Os tipos de máquina c4-standard-288-metal e c4-highmem-288-metal não são compatíveis com a simulação de eventos de manutenção do host.

Alternativa

Use instâncias de máquina virtual (VM) criadas com outros tipos de máquina C4 para simular eventos de manutenção.

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

    Ao criar a VM, configure a instância C4 para Terminate em vez de usar a migração em tempo real durante eventos de manutenção do host.

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

Durante um evento simulado de manutenção do host, o comportamento das VMs configuradas como Terminate é o mesmo das instâncias bare metal C4.

Performance abaixo do esperado com instâncias bare metal Z3 no RHEL 8

Ao usar o Red Hat Enterprise Linux (RHEL) versão 8 com uma instância bare metal Z3, a performance da rede é menor do que o esperado.

Causa raiz

Há um recurso de pool de páginas ausente na versão 4.18 do kernel do Linux, que é usada pelo RHEL 8.

Alternativa

Use uma versão mais recente do RHEL ou um sistema operacional diferente ao trabalhar com instâncias bare metal Z3.

Problemas relacionados ao uso de interfaces de rede dinâmica

Esta seção descreve problemas conhecidos relacionados ao uso de várias interfaces de rede e interfaces de rede dinâmicas.

Pacotes descartados ao usar NICs dinâmicas com intervalos de IP alias, encaminhamento de protocolo ou balanceadores de carga de rede de passagem

O agente convidado adiciona automaticamente rotas locais nos seguintes cenários para vNICs, mas não para NICs dinâmicas:

  • Quando você configura um intervalo de IP de alias, o agente convidado cria uma rota local para o intervalo de IP de alias.
  • Quando você cria uma instância de destino que faz referência a uma instância de computação para encaminhamento de protocolo, o agente convidado cria uma rota local para o endereço IP da regra de encaminhamento associada.
  • Quando você adiciona um back-end a um balanceador de carga de rede de passagem, o agente convidado cria uma rota local para o endereço IP da regra de encaminhamento associada.

Como as rotas locais não são adicionadas para NICs dinâmicas, a NIC dinâmica pode ter pacotes descartados.

Para resolver esse problema, adicione os endereços IP manualmente da seguinte maneira:

  1. Conecte-se à instância usando SSH.

  2. Se você estiver configurando um intervalo de IP de alias, faça o seguinte. Caso contrário, pule esta etapa.

    1. Em /etc/default/instance_configs.cfg, verifique se a configuração ip_aliases está definida como true.

    2. Se a configuração ip_aliases estiver definida como false, modifique o arquivo para mudar para true e reinicie o agente convidado:

      systemctl restart google-guest-agent

  3. Configure uma rota local para o intervalo de IP de alias ou o endereço IP da regra de encaminhamento usando o seguinte comando:

    ip route add to local IP_ADDRESS dev DYNAMIC_NIC_DEVICE_NAME proto 66

    Substitua:

    • IP_ADDRESS: o intervalo de IP do alias ou o endereço IP da regra de encaminhamento para o qual você quer adicionar uma rota local.
    • DYNAMIC_NIC_DEVICE_NAME: o nome do dispositivo da NIC dinâmica em que você quer adicionar uma rota local. Por exemplo, a-gcp.ens4.3.

Problemas com a instalação e o gerenciamento de NICs dinâmicas nas versões do agente convidado 20250901.00 a 20251120.01

Se você configurar o gerenciamento automático de NICs dinâmicas e sua instância estiver executando o agente convidado em uma versão de 20250901.00 a 20251120.01, poderá encontrar os seguintes problemas:

  • O agente convidado não consegue instalar e gerenciar NICs dinâmicas no SO convidado da instância.

    Você pode receber um erro que inclui Cannot find device ao executar comandos no SO convidado que fazem referência a NICs dinâmicas.

  • A exclusão de várias NICs dinâmicas torna o servidor de metadados inacessível.

Causa raiz

A partir da versão 20250901.00, o agente convidado foi migrado para uma nova arquitetura baseada em plug-ins para melhorar a modularidade. A nova arquitetura não oferecia suporte inicial à instalação e ao gerenciamento automáticos de NICs dinâmicas.

Resolução

Para resolver esses problemas, atualize sua instância para usar a versão do agente convidado 20251205.00 ou mais recente:

  1. Para atualizar o agente convidado para a versão mais recente, consulte Atualizar o ambiente convidado.
  2. Para confirmar a versão do agente convidado que sua instância está executando, consulte Exibir pacotes instalados por versão do sistema operacional.

Se necessário, você pode contornar temporariamente esses problemas em instâncias que estão executando versões do agente convidado de 20250901.00 a 20251120.01 seguindo as instruções em Compatibilidade com versões anteriores para reverter à arquitetura anterior do agente convidado.

A interceptação de pacotes pode resultar em pacotes descartados devido à falta de tags VLAN nos cabeçalhos Ethernet.

A interceptação de pacotes ao usar uma NIC dinâmica pode resultar em perda de pacotes. Isso pode acontecer quando o pipeline é encerrado antes do tempo. O problema afeta os modos com e sem base em sessão.

Causa raiz

Os pacotes descartados ocorrem durante a interceptação de pacotes quando o pipeline é encerrado antes do tempo (interceptação de entrada e reinjeção de saída). O encerramento antecipado faz com que o ID da VLAN fique ausente do cabeçalho Ethernet do pacote de entrada. Como o pacote de saída é derivado do pacote de entrada modificado, ele também não tem o ID da VLAN. Isso leva à seleção incorreta do índice de endpoint e à perda de pacotes subsequente.

Alternativa

Não use recursos Google Cloud que dependem da interceptação de pacotes, como endpoints de firewall.

Problemas conhecidos das instâncias de computação do Linux

Estes são os problemas conhecidos das instâncias de computação do Linux.

Erro de upgrade de pacote no Rocky Linux 9.7

O dnf update falha em imagens do Rocky Linux Otimizado para Aceleradores versão v20251113 ou anterior (por exemplo, rocky-linux-9-optimized-gcp-nvidia-latest-v20251113) devido a um conflito de dependência de pacote. Talvez você veja um erro semelhante a este:

[root@rockylinux9 ~]# dnf update
CIQ SIG/Cloud Next for Rocky Linux 9 37 MB/s | 49 MB 00:01
CIQ SIG/Cloud Next Nonfree for Rocky Linux 9 4.4 MB/s | 1.5 MB 00:00
NVIDIA DOCA 2.10.0 packages for EL 9.5 239 kB/s | 160 kB 00:00
Google Compute Engine 38 kB/s | 8.2 kB 00:00
Google Cloud SDK 59 MB/s | 154 MB 00:02
Rocky Linux 9 - BaseOS 24 MB/s | 6.3 MB 00:00
Rocky Linux 9 - AppStream 36 MB/s | 11 MB 00:00
Rocky Linux 9 - Extras 124 kB/s | 16 kB 00:00
Error:
 Problem 1: package perftest-25.04.0.0.84-1.el9.x86_64 from baseos requires libhns.so.1(HNS_1.0)(64bit), but none of the providers can be installed
  - package perftest-25.04.0.0.84-1.el9.x86_64 from baseos requires libhns.so.1()(64bit), but none of the providers can be installed
  - cannot install both libibverbs-51.0-3.el9_5.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-51.0-5.el9_5.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-54.0-2.el9_6.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-54.0-3.el9_6.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-54.0-4.el9_6.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-54.0-5.el9_6.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-57.0-3.el9_7_ciq.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-57.0-2.el9.x86_64 from baseos and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install the best update candidate for package perftest-25.01.0-0.70.g759a5c5.2501060.x86_64
  - cannot install the best update candidate for package libibverbs-2501mlnx56-1.2501060.x86_64
 Problem 2: package ucx-ib-mlx5-1.18.0-1.2501060.x86_64 from @System requires ucx(x86-64) = 1.18.0-1.2501060, but none of the providers can be installed
  - cannot install both ucx-1.18.1-1.el9.x86_64 from appstream and ucx-1.18.0-1.2501060.x86_64 from @System
  - cannot install both ucx-1.18.1-1.el9.x86_64 from appstream and ucx-1.18.0-1.2501060.x86_64 from doca
  - cannot install the best update candidate for package ucx-ib-mlx5-1.18.0-1.2501060.x86_64
  - cannot install the best update candidate for package ucx-1.18.0-1.2501060.x86_64
...
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

Causa raiz

Há um conflito de versão de pacote do espaço do usuário entre as versões do DOCA OFED anteriores a 3.20 e o Rocky Linux 9.7. Especificamente, o Rocky Linux 9.7 inclui pacotes ucx e perftest que são uma versão mais recente do que os pacotes correspondentes no repositório DOCA OFED. Essa incompatibilidade de versão faz com que dnf update falhe com erros de resolução de dependência.

Resolução

Antes de fazer um upgrade completo do sistema, atualize o pacote do repositório DOCA:

sudo dnf update doca-repo
sudo dnf update

As imagens do Rocky Linux Otimizado para Aceleradores criadas em dezembro de 2025 (por exemplo, rocky-linux-9-optimized-gcp-nvidia-latest-v20251215) já incluem o pacote doca-repo atualizado. Portanto, esse problema de upgrade não está presente nessas versões ou em versões posteriores.

O Login do SO não é compatível com o SLES 16

Um problema de configuração do SSH no SUSE Linux Enterprise Server (SLES) 16 impede o uso do recurso Google Cloud OSLogin. No entanto, as conexões SSH gerenciadas por metadados não são afetadas e continuam funcionando.

Formatos de URL aceitos para script de inicialização

Se a instância de computação usar a versão 20251115.00 do agente convidado, a busca de um script de inicialização usando a chave de metadados startup-script-url vai falhar se o URL usar o formato https://storage.googleapis.com/ documentado na página Usar scripts de inicialização em VMs Linux.

Para contornar esse problema, use um dos seguintes formatos de URL compatíveis:

  • URL autenticado: https://storage.cloud.google.com/BUCKET/FILE
  • URI de armazenamento da CLI gcloud: gs://BUCKET/FILE

As instâncias de VM que usam imagens do Debian 11 anteriores à versão v20250728 não executam apt update.

Em 22 de julho de 2025, a comunidade Debian removeu os backports do Debian 11 (Bullseye) do upstream principal do Debian. Essa atualização faz com que sudo apt update falhe com o seguinte erro:

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

Causa raiz

Como a comunidade Debian removeu os repositórios de retroportabilidade do upstream principal, não há mais referência a bullseye-backports Release.

Resolução

Use a versão debian-11-bullseye-v20250728 ou mais recente da imagem. Essas versões não contêm os repositórios de backports. Como alternativa, atualize 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 excluir o URL do repositório e descartar 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

A instalação do pacote ubuntu-desktop interrompe a conectividade de rede quando a instância é reiniciada.

Ao reiniciar uma instância de computação do Ubuntu depois de instalar o pacote ubuntu-desktop, as interfaces de rede podem não ser configuradas corretamente.

Causa raiz

O pacote ubuntu-deskop extrai ubuntu-settings como uma dependência, o que define o NetworkManager como o "renderizador" padrão para o netplan. Mais especificamente, ele insere uma nova configuração YAML para netplan em /usr/lib/netplan/00-network-manager-all.yaml com o seguinte:

network:
  version: 2
  renderer: NetworkManager

Essa configuração entra em conflito com o provisionamento antecipado baseado em networkd usando cloud-init.

Recuperação

Se a instância de computação tiver sido reiniciada e estiver inacessível, faça o seguinte:

  1. Siga as instruções para resgatar uma instância de computação.

  2. Depois de montar a partição do sistema de arquivos Linux da instância de computação inacessível, execute o seguinte comando (substituindo /rescue pelo ponto de montagem):

    echo -e 'network:\n  version: 2\n  renderer: networkd' | sudo tee /rescue/etc/netplan/99-gce-renderer.yaml

  3. Continue reiniciando a instância de computação inacessível.

As instâncias de computação que usam a versão v20250530 do SO Ubuntu mostram um FQDN incorreto.

Talvez um nome de domínio totalmente qualificado (FQDN) incorreto apareça com a adição do sufixo .local quando você faz uma destas ações:

  • Atualize para a versão 20250328.00 do pacote google-compute-engine.
  • Inicie instâncias de computação com qualquer imagem do Ubuntu oferecida pela Canonical com o sufixo de versão v20250530.

Por exemplo, projects/ubuntu-os-cloud/global/images/ubuntu-2204-jammy-v20250530

Se você tiver esse problema, poderá ver um FQDN semelhante a este:

   [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

Causa raiz

Em todas as imagens do Ubuntu com a versão v20250530, a versão 20250328.00 do pacote guest-config adiciona local ao caminho de pesquisa devido à introdução de um novo arquivo 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 dessa entrada local no caminho de pesquisa do arquivo /etc/resolv.conf resulta em um elemento .local anexado ao nome do host quando um FQDN é solicitado.

A versão 20250501 do guest-configs já corrige o problema, mas a Canonical ainda não incorporou a correção às imagens.

Alternativa

  1. Modifique o arquivo de configuração de resolução de nomes de rede /etc/systemd/resolved.conf.d/gce-resolved.conf mudando Domains=local para Domains=~local
  2. Execute o comando a seguir 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 usando o comando hostname -f

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

mkfs.ext4 ausente em imagens do openSUSE

A versão recente v20250724 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 oferece utilitários para gerenciar sistemas de arquivos. Um sintoma comum desse problema é a exibição de uma mensagem de erro, como command not found, ao tentar usar o comando mkfs.ext4.

Alternativa

Se você encontrar esse problema, instale o pacote ausente manualmente usando o gerenciador de pacotes 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 instâncias de computação do SUSE Enterprise não são inicializadas após a mudança de tipos de máquina

Depois de mudar o tipo de máquina de uma instância de computação que executa o SUSE Enterprise Linux, a instância pode não inicializar com o seguinte erro no console serial:

            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"

Causa raiz

A SUSE cria imagens de nuvem com um initramfs (sistema de arquivos RAM inicial) versátil que oferece suporte a vários tipos de instância. Para isso, use as flags --no-hostonly --no-hostonly-cmdline -o multipath durante a criação inicial da imagem. No entanto, quando um novo kernel é instalado ou o initramfs é regenerado, o que acontece durante as atualizações do sistema, essas flags são omitidas por padrão. Isso resulta em um initramfs menor, adaptado especificamente para o hardware do sistema atual, o que pode excluir drivers necessários para outros tipos de instância.

Por exemplo, as instâncias C3 usam unidades NVMe, que exigem módulos específicos para serem incluídos no initramfs. Se um sistema com um initramfs sem esses módulos NVMe for migrado para uma instância C3, o processo de inicialização vai falhar. Esse problema também pode afetar outros tipos de instância com requisitos de hardware exclusivos.

Alternativa

Antes de mudar o tipo de máquina, gere novamente o initramfs com todos os drivers:

dracut --force --no-hostonly

Se o sistema já estiver afetado pelo problema, crie uma instância de computação de resgate temporário. Use o comando chroot para acessar o disco de inicialização da instância afetada e gere novamente o initramfs usando o seguinte comando:

dracut -f --no-hostonly

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

As instâncias de computação Z3 que usam imagens do SUSE Linux Enterprise Server (SLES) 12 têm uma performance significativamente menor do que o esperado para IOPS em discos SSD locais.

Causa raiz

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

Alternativa

Não há um patch do SUSE para corrigir esse problema. Em vez disso, use o sistema operacional SLES 15.

As instâncias de computação do RHEL 7 e do CentOS perdem o acesso à rede após a reinicialização

Se as instâncias de computação do CentOS ou do RHEL 7 tiverem várias placas de interface de rede (NICs) e uma delas não usar a interface VirtIO, o acesso à rede poderá ser perdido após a reinicialização. Isso acontece porque o RHEL não é compatível com a desativação de nomes de interface de rede previsíveis se pelo menos uma NIC não usar a interface VirtIO.

Resolução

A conectividade de rede pode ser restaurada interrompendo e iniciando a instância de computação até que o problema seja resolvido. Para evitar que a perda de conectividade de rede ocorra novamente, faça o seguinte:

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

  2. Gere novamente a configuração do grub.

  3. Reinicie a instância de computação.

Não foi possível verificar a assinatura do 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, a instância de computação pode estar definida em diferentes arquivos de configuração de repositório ou ferramentas de automação.

Os repositórios do 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

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

Resolução

Ignore a mensagem de erro.

Problemas conhecidos de instâncias do Windows

  • O suporte para NVMe no Windows usando o driver da comunidade NVMe está na versão Beta. O desempenho pode não corresponder ao das instâncias do Linux. O driver NVMe da comunidade foi substituído pelo driver Microsoft StorNVMe nas imagens públicas do Google Cloud . Recomendamos que você substitua o driver NVME nas instâncias de computação criadas antes de maio de 2022 e use o driver Microsoft StorNVMe.
  • 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 de computação 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.
  • O driver vioscsi, usado para discos SCSI, define a flag removable, fazendo com que os discos sejam tratados como armazenamento removível. Isso causa restrições de acesso inesperadas no Windows a discos sujeitos a objetos de política de grupo (GPOs) que têm como destino o armazenamento removível.

Falha ao iniciar o agente convidado

A versão 20251011.00 do agente convidado do Windows não é iniciada em determinadas condições de carga.

Causa raiz O pacote do agente convidado do Windows para a versão 20251011.00 define incorretamente o modo de inicialização do agente convidado do Windows como auto no Gerenciador de serviços do Windows.

Resolução Para resolver esse problema, atualize sua instância para usar a versão 20251120.01 ou mais recente do agente convidado.

Solução alternativa manual Se não for possível instalar a versão 20251120.01, execute o seguinte comando:

  • sc.exe config GCEAgent start=delayed-auto

Os recursos de gerenciamento de credenciais podem falhar em instâncias do Windows que usam nomes de idiomas diferentes do inglês

O agente convidado do Windows identifica contas e grupos de administrador usando correspondência de strings. Portanto, os recursos de gerenciamento de credenciais só funcionam corretamente quando você usa nomes em inglês para contas de usuário e grupos, por exemplo, Administrators. Se você usar nomes em outros idiomas, os recursos de gerenciamento de credenciais, como geração ou redefinição de senhas, talvez não funcionem como esperado.

O Windows Server 2016 não será inicializado em tipos de máquina C3D com 180 ou mais vCPUs.

O Windows Server 2016 não será inicializado em tipos de máquina C3D com 180 ou 360 vCPUs. Para resolver esse problema, escolha uma das seguintes opções:

  • Se você precisar usar o Windows Server 2016, use um tipo de máquina com menos de 180 vCPUs.
  • Se você precisar usar um tipo de máquina C3D com 180 ou 360 vCPUs, use uma versão mais recente do Windows Server.

Windows Server 2025 e Windows 11 24h2/25h2: suporte para suspensão e retomada

O Windows Server 2025, o Windows 11 24h2 e o Windows 11 25h2 não podem ser retomados quando são suspensos. Até que o problema seja resolvido, o recurso de suspensão e retomada não será compatível com o Windows Server 2025, o Windows 11 24h2 e o Windows 11 25h2.

Erros ao medir o deslocamento de tempo NTP usando w32tm em instâncias do Windows

Para instâncias do Windows no Compute Engine que usam uma interface de rede VirtIO, há um bug conhecido em que a medição do deslocamento de NTP produz erros ao usar o seguinte comando:

w32tm /stripchart /computer:metadata.google.internal

Os erros são semelhantes a estes:

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

Esse bug afeta apenas as instâncias do Compute Engine com NICs VirtIO. As instâncias do Compute que usam interfaces de rede gVNIC não encontram esse problema.

Para evitar esse problema, o Google recomenda o uso de outras ferramentas de medição de deslocamento do NTP, como o Monitor de servidor de tempo Meinberg.

Dispositivo de inicialização inacessível após atualizar uma instância de computação da 1ª ou 2ª geração para uma instância da 3ª geração ou mais recente

O Windows Server vincula a unidade de inicialização ao tipo de interface de disco inicial na primeira inicialização. Para mudar uma instância de computação de uma série de máquinas mais antiga (Geração 1 ou 2) que usa uma interface de disco SCSI para uma série de máquinas mais recente (Geração 3 ou posterior) que usa uma interface de disco NVMe, execute um sysprep de driver PnP do Windows antes de desligar a instância de computação. Esse sysprep prepara apenas drivers de dispositivo e verifica se todos os tipos de interface de disco são verificados para a unidade de inicialização na próxima inicialização.

Em um prompt do PowerShell como Administrator, execute:

PS C:\> start rundll32.exe sppnp.dll,Sysprep_Generalize_Pnp -wait

Para mudar a série de máquinas de uma instância de computação, faça o seguinte:

  1. Interrompa a instância de computação.
  2. Edite a instância de computação para usar o novo tipo de máquina.
  3. Inicie a instância de computação.

Se a nova instância de computação não iniciar corretamente, edite-a para usar o tipo de máquina original e reinicie a instância. Essa sequência de etapas deve fazer com que sua instância de computação seja executada corretamente. Confira os requisitos de migração para verificar se você os atende. Em seguida, tente seguir as instruções novamente.

A quantidade de discos anexados é limitada para séries de máquinas que usam discos NVMe

As instâncias de computação que usam a interface de disco NVMe e uma imagem do SO Microsoft Windows têm um limite de conexão de disco de 16 discos. Esse limite se aplica a instâncias T2A, a todas as instâncias de computação de terceira geração e às instâncias de computação de quarta geração da série N (N4, N4D, N4A). Para evitar erros, consolide o armazenamento do Persistent Disk e do Hyperdisk em um máximo de 16 discos por instância de computação. O armazenamento SSD local não é afetado por esse problema.

Substitua o driver NVME nas instâncias de computação criadas antes de maio de 2022

Se você quiser usar o NVMe em uma instância de computação que usa o Microsoft Windows e ela tiver sido criada antes de 1º de maio de 2022, atualize o driver NVMe atual no SO convidado para usar o Driver Microsoft StorNVMe.

Atualize o driver NVMe na instância de computação antes de mudar o tipo de máquina para uma série de máquinas de terceira geração ou posterior ou antes de criar um snapshot do disco de inicialização que será usado para criar novas instâncias de computação que usam uma série de máquinas de terceira geração ou posterior.

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

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

Desempenho mais baixo para discos SSD locais em instâncias C3 e C3D que executam o Microsoft Windows

O desempenho do SSD local é limitado para instâncias C3 e C3D que executam o Microsoft Windows.

As melhorias no desempenho estão em andamento.

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

As instâncias de computação baseadas no tipo de máquina n2-standard-80 que executam o Microsoft Windows podem atingir no máximo 80.000 IOPS em todos os volumes do Hyperdisk Extreme anexados à instância.

Resolução

Para atingir até 160.000 IOPS com instâncias N2 executando o Windows, escolha um dos seguintes tipos de máquina:

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

Baixa capacidade de rede ao usar o gVNIC

As instâncias de computação do Windows Server 2022 e do Windows 11 que usam o driver gVNIC versão do pacote GooGet 1.0.0@44 ou anterior podem ter uma capacidade de rede ruim ao usar a NIC virtual do Google (gVNIC).

Para resolver esse problema, atualize o pacote GooGet do driver da gVNIC para a versão 1.0.0@45 ou mais recente fazendo o seguinte:

  1. Verifique qual versão do driver está instalada na instância de computação. Para isso, execute o comando a seguir em um prompt de comando ou sessão do PowerShell como administrador:

    googet installed

    A saída será assim:

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

  2. Se a versão do driver google-compute-engine-driver-gvnic.x86_64 for 1.0.0@44 ou anterior, atualize o repositório de pacotes GooGet executando o seguinte comando em um prompt de comando ou sessão do PowerShell como administrador:

    googet update

Os tipos de máquina de vCPU C4, C4D e C3D grandes não são compatíveis com imagens do SO Windows.

Os tipos de máquina C4 com mais de 144 vCPUs e os tipos de máquina C4D e C3D com mais de 180 vCPUs não são compatíveis com imagens do SO Windows Server 2012 e 2016. Os tipos de máquina C4, C4D e C3D maiores que usam imagens do SO Windows Server 2012 e 2016 não serão inicializados. Para contornar esse problema, selecione um tipo de máquina menor ou use outra imagem do SO.

As instâncias C3D criadas com 360 vCPUs e imagens do SO Windows não serão inicializadas. Para contornar esse problema, selecione um tipo de máquina menor ou use outra imagem do SO.

As instâncias C4D criadas com mais de 255 vCPUs e imagens do Windows 2025 não serão inicializadas. Para contornar esse problema, selecione um tipo de máquina menor ou use outra imagem do SO.

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

No momento, a capacidade de adicionar ou redimensionar um Hyperdisk ou Persistent Disk em uma instância do M3, C3, C3D ou C4D em execução não funciona como esperado em convidados específicos do Windows. O Windows Server 2012 R2 e o Windows Server 2016, e as imagens de cliente do Windows correspondentes, não respondem corretamente aos comandos de anexação e redimensionamento de disco.

Por exemplo, se você remover um disco de uma instância M3 em execução, ele será desconectado, mas o sistema operacional Windows não vai reconhecer que ele não está mais disponível. As gravações subsequentes no disco retornarão um erro genérico.

Resolução

Se você usa instâncias M3, C3, C3D ou C4D que executam o sistema operacional Windows e modifica um volume do Hyperdisk ou Persistent Disk, é necessário reiniciar a instância de computação para que as modificações no disco sejam reconhecidas.