Problemi noti

Questa pagina descrive i problemi noti che potresti riscontrare durante l'utilizzo di Compute Engine. Per i problemi che interessano specificamente le Confidential VM, consulta le limitazioni delle Confidential VM.

Problemi generici

I seguenti argmenti forniscono indicazioni per la risoluzione dei problemi o informazioni generali.

Risolto: la modifica delle IOPS o del throughput su un disco principale con replica asincrona utilizzando il comando gcloud compute disks update causa un falso errore

Il seguente problema è stato risolto il 1° giugno 2025.

Quando utilizzi il comando gcloud compute disks update per modificare le IOPS e il throughput su un disco principale con replica asincrona, gcloud CLI mostra un messaggio di errore anche se l'aggiornamento è andato a buon fine.

Per verificare con precisione che un aggiornamento sia andato a buon fine, utilizza la gcloud CLI o la console Google Cloud per verificare se le proprietà del disco mostrano i nuovi valori di IOPS e throughput. Per ulteriori informazioni, consulta Visualizza le impostazioni delle prestazioni di cui è stato eseguito il provisioning per HyperDisk.

Il server di metadati potrebbe mostrare i vecchi metadati della VM physicalHost

Dopo aver riscontrato un errore relativo all'host che sposta un'istanza in un nuovo host, quando esegui una query sul server dei metadati, potrebbero essere visualizzati i metadati physicalHost dell'host precedente dell'istanza.

Per risolvere il problema, esegui una delle seguenti operazioni:

Valori baseInstanceName lunghi nei gruppi di istanze gestite (MIG) possono causare conflitti nei nomi dei dischi

In un MIG, possono verificarsi conflitti nei nomi dei dischi se il template di istanza specifica i dischi da creare al momento della creazione della VM e il valore baseInstanceName supera i 54 caratteri. Questo accade perché Compute Engine genera i nomi dei dischi utilizzando il nome dell'istanza come prefisso.

Quando generi i nomi dei dischi, se il nome risultante supera il limite di 63 caratteri per i nomi delle risorse, Compute Engine tronca i caratteri in eccesso dalla fine del nome dell'istanza. Questo troncamento può portare alla creazione di nomi di dischi identici per istanze che hanno schemi di denominazione simili. In questo caso, la nuova istanza tenterà di collegare il disco esistente. Se il disco è già collegato a un'altra istanza, la creazione della nuova istanza non va a buon fine. Se il disco non è collegato o è in modalità multi-writer, la nuova istanza lo collegherà, con un potenziale rischio di danneggiamento dei dati.

Per evitare conflitti nei nomi dei dischi, mantieni il valore baseInstanceName con una lunghezza massima di 54 caratteri.

La creazione di prenotazioni o richieste di prenotazione futura utilizzando un template di istanza che specifica un tipo di macchina A2, C3 o G2 causa problemi

Se utilizzi un template di istanza che specifica un tipo di macchina A2, C3 o G2 per creare una prenotazione o per creare e inviare una richiesta di prenotazione futura per la revisione, riscontri problemi. In particolare:

  • La creazione della prenotazione potrebbe non riuscire. Se l'operazione va a buon fine, si applica una delle seguenti condizioni:

    • Se hai creato una prenotazione utilizzata automaticamente (valore predefinito), la creazione di VM con proprietà corrispondenti non utilizzerà la prenotazione.

    • Se hai creato una prenotazione specifica, la creazione di VM che hanno come target specifico la prenotazione non va a buon fine.

  • La creazione della richiesta di prenotazione futura va a buon fine. Tuttavia, se la invii per la revisione, Google Cloud rifiuta la tua richiesta.

Non puoi sostituire il template di istanza utilizzato per creare una prenotazione o una richiesta di prenotazione futura né eseguire l'override delle proprietà della VM del template. Se vuoi prenotare risorse per tipi di macchine A2, C3 o G2, procedi in uno dei seguenti modi:

Limitazioni relative all'utilizzo dei tipi di macchine -lssd con Google Kubernetes Engine

Quando utilizzi l'API Google Kubernetes Engine, il pool di nodi con SSD locale collegato di cui viene eseguito il provisioning deve avere lo stesso numero di dischi SSD del tipo di macchina C4, C3 o C3D selezionato. Ad esempio, se prevedi di creare una VM che utilizza c3-standard-8-lssd, devono essere presenti 2 dischi SSD, mentre per c3d-standard-8-lssd è richiesto un solo disco SSD. Se il numero di dischi non corrisponde, verrà visualizzato un errore di configurazione errata dell'SSD locale dal control plane di Compute Engine. Consulta la sezione Tipi di macchine che si collegano automaticamente ai dischi SSD locali per selezionare il numero corretto di dischi SSD locali in base al tipo di macchina lssd.

L'utilizzo della console Google Cloud Google Kubernetes Engine per creare un cluster o pool di nodi con VM c4-standard-*-lssd, c4-highmem-*-lssd, c3-standard-*-lssd e c3d-standard-*-lssd comporta un errore di creazione dei nodi o un errore di rilevamento degli SSD locali come archiviazione temporanea.

Variabilità del throughput TCP a flusso singolo sulle VM C3D

Le VM C3D con più di 30 vCPU potrebbero presentare una variabilità del throughput TCP a flusso singolo e occasionalmente essere limitate a 20-25 Gbps. Per ottenere tassi più elevati, utilizza più flussi TCP.

La metrica di osservabilità dell'utilizzo della CPU non è corretta per le VM che utilizzano un thread per core

Se la CPU della VM utilizza un thread per core, la metrica di osservabilità dell'utilizzo della CPU di Cloud Monitoring nella scheda Compute Engine > Istanze VM > Osservabilità scala solo al 50%. Due thread per core è il valore predefinito per tutti i tipi di macchina, ad eccezione di Tau T2D. Per ulteriori informazioni, consulta Imposta il numero di thread per core.

Per visualizzare l'utilizzo della CPU della VM normalizzato al 100%, visualizza l'utilizzo della CPU in Esplora metriche. Per ulteriori informazioni, consulta Crea grafici con Esplora metriche.

Le connessioni SSH nel browser della consoleGoogle Cloud potrebbero non riuscire se utilizzi regole firewall personalizzate

Se utilizzi regole firewall personalizzate per controllare l'accesso SSH alle tue istanze VM, potresti non essere in grado di utilizzare la funzionalità SSH nel browser.

Per risolvere il problema, esegui una delle seguenti operazioni:

Nomi temporanei per i dischi

Durante gli aggiornamenti delle istanze di macchine virtuali (VM) avviati utilizzando il comando gcloud compute instances update o il metodo API instances.update, Compute Engine potrebbe modificare temporaneamente il nome dei dischi della VM aggiungendo uno dei seguenti suffissi al nome originale:

  • -temp
  • -old
  • -new

Compute Engine rimuove il suffisso e ripristina i nomi originali dei dischi al termine dell'aggiornamento.

Aumento della latenza per alcuni Persistent Disk causato dal ridimensionamento dei dischi

In alcuni casi, il ridimensionamento di Persistent Disk di grandi dimensioni (~3 TB o più) potrebbe influire negativamente sulle prestazioni I/O del disco. Se il problema ti riguarda, i tuoi Persistent Disk potrebbero registrare una maggiore latenza durante l'operazione di ridimensionamento. Questo problema può interessare i Persistent Disk di qualsiasi tipo.

I processi automatizzati potrebbero non riuscire se utilizzano i dati di risposta dell'API relativi alle quote di impegno basate sulle risorse

I processi automatizzati che consumano e utilizzano i dati di risposta dell'API relativi alle quote di impegno basate sulle risorse di Compute Engine potrebbero non riuscire se si verifica una delle seguenti condizioni. I processi automatizzati possono includere snippet di codice, logica di business o campi di database che utilizzano o memorizzano le risposte dell'API.

  1. I dati di risposta provengono da uno dei seguenti metodi dell'API Compute Engine:

  2. Utilizzi un int anziché un number per definire il campo per il limite di quota per le risorse nei campi di risposta dell'API. Puoi trovare il campo nei seguenti modi per ciascun metodo:

  3. Hai a disposizione una quota predefinita illimitata per qualsiasi SKU impegnato di Compute Engine.

    Per ulteriori informazioni sulle quote per gli impegni e gli SKU impegnati, consulta Quote per gli impegni e le risorse impegnate.

Causa principale

Quando hai una quota limitata, se definisci il campo items[].quotas[].limit o quotas[].limit come tipo int, i dati di risposta dell'API per i limiti di quota potrebbero comunque rientrare nell'intervallo per il tipo int e il processo automatizzato potrebbe non essere interrotto. Tuttavia, quando il limite di quota predefinito è illimitato, l'API Compute Engine restituisce un valore per il campo limit che rientra al di fuori dell'intervallo definito dal tipo int. Il processo automatizzato non può utilizzare il valore restituito dal metodo dell'API e di conseguenza non va a buon fine.

Come risolvere il problema

Puoi risolvere il problema e continuare a generare i report automatizzati nei seguenti modi:

  • Azione consigliata: segui la documentazione di riferimento dell'API Compute Engine e utilizza i tipi di dati corretti per le definizioni dei metodi dell'API. Nello specifico, utilizza il tipo number per definire i campi items[].quotas[].limit e quotas[].limit per i metodi dell'API.

  • Riduci il limite di quota a un valore inferiore a 9.223.372.036.854.775.807. Devi impostare limiti di quota per tutti i progetti con impegni basati su risorse in tutte le regioni. Puoi farlo in uno dei seguenti modi:

Problemi noti per le istanze bare metal

Questi sono i problemi noti per le istanze Bare Metal di Compute Engine.

Bare metal C4D non supporta le immagini SUSE Linux 15 SP6

Le istanze bare metal C4D non possono eseguire il sistema operativo SUSE Linux Enterprise Server (SLES) versione 15 SP6.

Soluzione temporanea

Utilizza invece SLES 15 SP5.

La simulazione della manutenzione dell'host non funziona per le istanze bare metal C4

I tipi di macchine c4-standard-288-metal e c4-highmem-288-metal non supportano la simulazione degli eventi di manutenzione dell'host.

Soluzione alternativa

Puoi utilizzare le istanze VM create utilizzando altri tipi di macchine C4 per simulare eventi di manutenzione.

  1. Crea un'istanza VM utilizzando un tipo di macchina C4 che non termina con -metal.

    Quando crei l'istanza VM, configura la VM C4 per Terminate anziché utilizzare la migrazione live durante gli eventi di manutenzione dell'host.

  2. Simula un evento di manutenzione dell'host per questa VM.

Durante un evento di manutenzione dell'host simulato, il comportamento delle VM configurate per l'interruzione è lo stesso delle istanze bare metal C4.

Prestazioni inferiori alle aspettative con le istanze bare metal Z3 su RHEL 8

Quando utilizzi Red Hat Enterprise Linux (RHEL) versione 8 con un'istanza Z3 Bare Metal, le prestazioni di rete sono inferiori al previsto.

Causa principale

Nella versione del kernel Linux (4.18) utilizzata da RHEL 8 manca una funzionalità Page Pool.

Soluzione alternativa

Utilizza una versione più recente di RHEL o un sistema operativo diverso quando lavori con le istanze bare metal Z3.

Problemi relativi all'utilizzo delle interfacce di rete dinamiche

Questa sezione descrive i problemi noti relativi all'utilizzo di più interfacce di rete e interfacce di rete dinamiche.

Perdita di pacchetti con dimensioni MTU personalizzate

Una NIC dinamica con una vNIC padre potrebbe riscontrare una perdita di pacchetti con dimensioni MTU personalizzate.

Soluzione alternativa

Per evitare la perdita di pacchetti, utilizza una delle seguenti dimensioni MTU:

  • 1460 byte (il valore predefinito per le reti VPC)
  • 1500 byte (Ethernet standard)
  • 8896 byte (il valore massimo possibile)

Interazioni firewall quando si riutilizza un ID VLAN con NIC dinamiche

Su un'istanza, il riutilizzo di un ID VLAN per una nuova NIC dinamica ha implicazioni per il monitoraggio della connessione firewall. Se elimini una NIC dinamica e crei una NIC dinamica sostitutiva che utilizza lo stesso ID VLAN, le voci della tabella di monitoraggio delle connessioni firewall non vengono cancellate automaticamente. L'esempio seguente mostra le considerazioni di sicurezza pertinenti:

  1. Un'istanza di calcolo ha una NIC dinamica di esempio con ID VLAN 4 connessa a una subnet nella rete VPC network-1.
  2. L'istanza invia pacchetti all'indirizzo IP di destinazione 192.0.2.7:443 e alla porta di destinazione. Le regole firewall in uscita applicabili consentono la connessione in uscita.
  3. Poiché le regole Cloud NGFW sono stateful, la connessione in uscita consentita crea una voce nella tabella di monitoraggio delle connessioni firewall che consente i pacchetti in entrata dall'indirizzo IP di origine e dalla porta di origine 192.0.2.7:443.
  4. Elimini la NIC dinamica di esempio e crei una NIC dinamica sostitutiva. La NIC dinamica sostitutiva utilizza anche l'ID VLAN 4, ma si connette a una subnet in una rete VPC diversa, network-2.
  5. Tutte le voci della tabella di monitoraggio delle connessioni firewall non scadute applicabili alla NIC dinamica originale sono applicabili alla NIC dinamica sostitutiva. Ciò significa che una risorsa nella rete VPC network-2 può inviare pacchetti le cui origini corrispondono a 192.0.2.7:443 e l'istanza di computing li accetta senza dover valutare le regole firewall in entrata.

Per ulteriori informazioni sul monitoraggio delle connessioni e sulle regole firewall, consulta Specifiche nella documentazione di Cloud Next Generation Firewall.

Soluzione

Per ogni istanza, se devi creare una NIC dinamica che utilizza lo stesso ID VLAN di una NIC dinamica rimossa dall'istanza:

  • Attendi almeno 10 minuti tra l'eliminazione della NIC dinamica originale e la creazione della NIC dinamica sostitutiva.
  • Arresta l'istanza, elimina la NIC dinamica originale e crea la NIC dinamica sostitutiva, quindi avvia l'istanza.

L'intercettazione dei pacchetti può comportare la perdita di pacchetti a causa della mancanza di tag VLAN nelle intestazioni Ethernet

L'intercettazione dei pacchetti quando si utilizza la NIC dinamica può comportare la perdita di pacchetti. I pacchetti eliminati possono verificarsi quando la pipeline viene terminata in anticipo. Il problema riguarda sia le modalità basate sulla sessione sia quelle non basate sulla sessione.

Causa principale

I pacchetti eliminati si verificano durante l'intercettazione dei pacchetti quando la pipeline viene terminata in anticipo (intercettazione in entrata e reiniezione in uscita). L'interruzione anticipata fa sì che l'ID VLAN non sia presente nell'intestazione Ethernet del pacchetto in entrata. Poiché il pacchetto di uscita deriva dal pacchetto di ingresso modificato, anche il pacchetto di uscita non ha l'ID VLAN. Ciò comporta una selezione errata dell'indice dell'endpoint e successive perdite di pacchetti.

Soluzione alternativa

Non utilizzare Google Cloud funzionalità che si basano sull'intercettazione dei pacchetti, come gli endpoint firewall.

Problemi noti per le istanze VM Linux

Questi sono i problemi noti per le VM Linux.

Le VM Debian 11 che utilizzano la versione dell'immagine del sistema operativo precedente alla v20250728 non riescono a eseguire apt update

Il 22 luglio 2025, la community Debian ha rimosso i backport di Debian 11 (Bullseye) dal repository Debian principale. Questo aggiornamento causa l'errore di sudo apt update con il seguente messaggio:

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

Causa principale

Poiché la community Debian ha rimosso i repository backport dal principale upstream, non esiste più alcun riferimento a bullseye-backports Release.

Risoluzione

Utilizza la versione debian-11-bullseye-v20250728 o successive dell'immagine. Queste versioni non contengono i repository di backport. In alternativa, puoi aggiornare le istanze correnti modificando /etc/apt/sources.list:

  • Per aggiornare l'URL del repository e utilizzare l'archivio per 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

  • Per eliminare l'URL del repository e ignorare 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

L'installazione del pacchetto ubuntu-desktop interrompe la rete della VM al riavvio

Dopo aver installato il pacchetto ubuntu-desktop su una VM Ubuntu, deve essere eseguita la seguente soluzione alternativa prima di riavviare la VM:

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

In caso contrario, le interfacce di rete potrebbero non essere configurate correttamente al riavvio.

Causa principale

Il pacchetto ubuntu-deskop estrae ubuntu-settings come dipendenza, che imposta NetworkManager come "renderer" predefinito per netplan. Più nello specifico, inserisce una nuova configurazione YAML per netplan in /usr/lib/netplan/00-network-manager-all.yaml contenente quanto segue:

network:
  version: 2
  renderer: NetworkManager

Questa configurazione è in conflitto con il provisioning anticipato basato su networkd che utilizza cloud-init.

Recupero

Se la VM è stata riavviata ed è inaccessibile, segui questi passaggi:

  1. Segui le istruzioni per il recupero di una VM.

  2. Dopo aver montato la partizione del file system Linux della VM inaccessibile, esegui il seguente comando (sostituendo /rescue con il punto di montaggio):

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

  3. Continua con le istruzioni per riavviare la VM inaccessibile

Le VM Ubuntu che utilizzano la versione dell'immagine del sistema operativo v20250530 mostrano un FQDN errato

Potresti visualizzare un nome di dominio completo (FQDN) errato con l'aggiunta del suffisso .local quando esegui una delle seguenti operazioni:

  • Esegui l'aggiornamento alla versione 20250328.00 del pacchetto google-compute-engine.
  • Avvia istanze da qualsiasi immagine Ubuntu offerta da Canonical con il suffisso della versione v20250530. Ad esempio, projects/ubuntu-os-cloud/global/images/ubuntu-2204-jammy-v20250530.

Se riscontri questo problema, potresti visualizzare un FQDN simile al seguente:

   [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 principale

In tutte le immagini Ubuntu con versione v20250530, la versione 20250328.00 del pacchetto guest-config aggiunge local al percorso di ricerca a causa dell'introduzione di un nuovo file di configurazione: 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

La presenza di questa voce local all'interno del percorso di ricerca nel file /etc/resolv.conf comporta l'aggiunta di un elemento .local al nome host quando viene richiesto un nome di dominio completo.

Tieni presente che la versione 20250501 di guest-configs risolve già il problema, ma Canonical non ha ancora incorporato la correzione nelle sue immagini.

Soluzione alternativa

  1. Modifica il file di configurazione della risoluzione dei nomi di rete /etc/systemd/resolved.conf.d/gce-resolved.conf modificando Domains=local in Domains=~local
  2. Esegui questo comando per riavviare il servizio systemd-resolved: systemctl restart systemd-resolved
  3. Verifica che local sia stato rimosso dal percorso di ricerca in /etc/resolv.conf

  4. Conferma l'FQDN utilizzando il comando hostname -f.

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

mkfs.ext4 mancante nelle immagini openSUSE

Nella recente release v20250724 delle immagini openSUSE (a partire da opensuse-leap-15-6-v20250724-x86-64) di agosto 2025 manca il pacchetto e2fsprogs, che fornisce utilità per la gestione dei file system. Un sintomo comune di questo problema è la visualizzazione di un messaggio di errore come command not found quando tenti di utilizzare il comando mkfs.ext4.

Soluzione alternativa

Se si verifica questo problema, installa manualmente il pacchetto mancante utilizzando il gestore dei pacchetti 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

Le VM SUSE Enterprise non riescono ad avviarsi dopo la modifica dei tipi di istanze

Dopo aver modificato il tipo di istanza di una VM SUSE Linux Enterprise, l'avvio potrebbe non riuscire con il seguente errore che si ripete nella console seriale:

            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 principale

SUSE crea le proprie immagini cloud con un initramfs versatile (filesystem RAM iniziale) che supporta vari tipi di istanze. Ciò si ottiene utilizzando i flag --no-hostonly --no-hostonly-cmdline -o multipath durante la creazione iniziale dell'immagine. Tuttavia, quando viene installato un nuovo kernel o viene rigenerato initramfs, come accade durante gli aggiornamenti di sistema, questi flag vengono omessi per impostazione predefinita. Il risultato è un initramfs più piccolo, personalizzato specificamente per l'hardware del sistema corrente, potenzialmente escludendo i driver necessari per altri tipi di istanze.

Ad esempio, le istanze C3 utilizzano driver NVMe, che richiedono moduli specifici da includere in initramfs. Se viene eseguita la migrazione di un sistema con un initramfs privo di questi moduli NVMe a un'istanza C3, il processo di avvio non va a buon fine. Questo problema può interessare anche altri tipi di istanze con requisiti hardware specifici.

Soluzione temporanea

Prima di cambiare il tipo di macchina, rigenera initramfs con tutti i driver:

dracut --force --no-hostonly

Se il sistema è già interessato dal problema, crea una VM di recupero temporanea. Utilizza il comando chroot per accedere al disco di avvio della VM interessata, quindi rigenera initramfs utilizzando il seguente comando:

dracut -f --no-hostonly

Prestazioni IOPS inferiori per l'SSD locale su Z3 con immagini SUSE 12

Le VM Z3 sulle immagini SUSE Linux Enterprise Server (SLES) 12 hanno prestazioni molto inferiori alle aspettative per le IOPS sui dischi SSD locali.

Causa principale

Si tratta di un problema all'interno del codebase di SLES 12.

Soluzione temporanea

Non è disponibile o pianificata una patch di SUSE per risolvere il problema. Dovresti invece utilizzare il sistema operativo SLES 15.

Le VM RHEL 7 e CentOS perdono l'accesso alla rete dopo il riavvio

Se le VM CentOS o RHEL 7 hanno più schede di interfaccia di rete (NIC) e una di queste NIC non utilizza l'interfaccia VirtIO, l'accesso alla rete potrebbe andare perso al riavvio. Questo accade perché RHEL non supporta la disattivazione dei nomi di interfaccia di rete prevedibili se almeno una NIC non utilizza l'interfaccia VirtIO.

Risoluzione

La connettività di rete può essere ripristinata arrestando e avviando la VM finché il problema non viene risolto. Per evitare che la perdita di connettività di rete si ripeta, segui questi passaggi:

  1. Modifica il file /etc/default/grub e rimuovi i parametri del kernel net.ifnames=0 e biosdevname=0.

  2. Rigenera la configurazione grub.

  3. Riavvia la VM.

Impossibile verificare la firma del file repomd.xml

Sui sistemi basati su Red Hat Enterprise Linux (RHEL) o CentOS 7, potresti visualizzare il seguente errore quando provi a installare o aggiornare il software utilizzando yum. Questo errore indica che hai una chiave GPG del repository scaduta o errata.

Log di esempio:

[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

Risoluzione

Per risolvere il problema, disattiva il controllo della chiave GPG del repository nella configurazione del repository yum impostando repo_gpgcheck=0. Nelle immagini di base di Compute Engine supportate, questa impostazione potrebbe trovarsi nel file /etc/yum.repos.d/google-cloud.repo. Tuttavia, la tua VM può avere questo valore impostato in diversi file di configurazione del repository o strumenti di automazione.

I repository Yum in genere non utilizzano le chiavi GPG per la convalida del repository. Invece, l'endpoint https è attendibile.

Per individuare e aggiornare questa impostazione, segui questi passaggi:

  1. Cerca l'impostazione nel file /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. Modifica tutte le righe che contengono repo_gpgcheck=1 in repo_gpgcheck=0.

    sudo sed -i 's/repo_gpgcheck=1/repo_gpgcheck=0/g' /etc/yum.repos.d/google-cloud.repo

  3. Verifica che l'impostazione sia aggiornata.

    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

Le istanze che utilizzano OS Login restituiscono un messaggio di accesso dopo la connessione

In alcune istanze che utilizzano OS Login, potresti ricevere il seguente messaggio di errore dopo che la connessione è stata stabilita:

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

Risoluzione

Ignora il messaggio di errore.

Problemi noti per le istanze VM Windows

  • Il supporto di NVMe su Windows che utilizza il driver NVMe della community è in versione beta, pertanto le prestazioni potrebbero non corrispondere a quelle delle istanze Linux. Il driver NVMe della community è stato sostituito dal driver Microsoft StorNVMe nelle immagini pubbliche Google Cloud . Ti consigliamo di sostituire il driver NVME nelle VM create prima di maggio 2022 e di utilizzare il driver Microsoft StorNVMe.
  • Dopo aver creato un'istanza, non puoi connetterti immediatamente. Tutte le nuove istanze Windows utilizzano lo strumento di preparazione del sistema (sysprep) per configurare l'istanza, che può richiedere 5-10 minuti.
  • Le immagini di Windows Server non possono essere attivate senza una connessione di rete a kms.windows.googlecloud.com e smettono di funzionare se non vengono autenticate inizialmente entro 30 giorni. Il software attivato da KMS deve essere riattivato ogni 180 giorni, ma KMS tenta di riattivarlo ogni 7 giorni. Assicurati di configurare le istanze Windows in modo che rimangano attive.
  • Il software del kernel che accede a registri specifici per il modello non emulati genererà errori di protezione generali, che possono causare un arresto anomalo del sistema a seconda del sistema operativo guest.

Windows Server 2025 e Windows 11 24h2 - Assistenza per sospensione e ripresa

Windows Server 2025 e Windows 11 24h2 non riescono a riprendere quando sono sospesi. Finché il problema non viene risolto, la funzionalità di sospensione e ripresa non sarà supportata per Windows Server 2025 e Windows 11 24h2.

Errori durante la misurazione della deviazione del tempo NTP utilizzando w32tm sulle VM Windows

Per le VM Windows su Compute Engine che eseguono NIC VirtIO, esiste un bug noto in cui la misurazione della deviazione NTP genera errori quando si utilizza il seguente comando:

w32tm /stripchart /computer:metadata.google.internal

Gli errori sono simili ai seguenti:

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

Questo bug interessa solo le VM Compute Engine con NIC VirtIO. Le VM che utilizzano gVNIC non riscontrano questo problema.

Per evitare questo problema, Google consiglia di utilizzare altri strumenti di misurazione della deviazione NTP, come Meinberg Time Server Monitor.

Dispositivo di avvio inaccessibile dopo l'aggiornamento di una VM di 1ª o 2ª generazione a una VM di 3ª generazione e oltre

Windows Server esegue il binding dell'unità di avvio al tipo di interfaccia del disco iniziale al primo avvio. Per spostare una VM esistente da una serie di macchine meno recente che utilizza un'interfaccia disco SCSI a una serie di macchine più recente che utilizza un'interfaccia di disco NVMe, esegui un sysprep del driver PnP di Windows prima di arrestare la VM. Questo sysprep prepara solo i driver del dispositivo e verifica che tutti i tipi di interfaccia disco vengano scansionati per la ricerca dell'unità di avvio al successivo avvio.

Per aggiornare la serie di macchine di una VM:

Da un prompt di PowerShell come Administrator, esegui:

PS C:\> start rundll32.exe sppnp.dll,Sysprep_Generalize_Pnp -wait
  1. Arresta la VM.
  2. Modifica la VM in base al nuovo tipo di macchina VM.
  3. Avvia la VM.

Se la nuova VM non si avvia correttamente, ripristina il tipo di macchina originale per far funzionare nuovamente la VM. Dovrebbe avviarsi correttamente. Esamina i requisiti per la migrazione per verificare di soddisfarli. Quindi, riprova a seguire le istruzioni.

Collegamento con un numero limitato di dischi per le serie di macchine VM più recenti

Le VM in esecuzione su Microsoft Windows con l'interfaccia disco NVMe, che include T2A e tutte le VM di terza generazione, hanno un limite di collegamento di 16 dischi. Questa limitazione non si applica alle VM di quarta generazione (C4, M4). Per evitare errori, consolida l'archiviazione Persistent Disk e Hyperdisk in un massimo di 16 dischi per VM. Lo spazio di archiviazione SSD locale è escluso da questo problema.

Sostituisci il driver NVME nelle VM create prima di maggio 2022

Se vuoi utilizzare NVMe su una VM che utilizza Microsoft Windows e la VM è stata creata prima del 1° maggio 2022, devi aggiornare il driver NVMe esistente nel sistema operativo guest per utilizzare il driver Microsoft StorNVMe.

Devi aggiornare il driver NVMe sulla VM prima di cambiare il tipo di macchina in una serie di macchine di terza generazione o prima di creare uno snapshot del disco di avvio che verrà utilizzato per creare nuove VM che utilizzano una serie di macchine di terza generazione.

Utilizza i seguenti comandi per installare il pacchetto di driver StorNVME e rimuovere il driver della community, se presente nel sistema operativo guest.

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

Prestazioni inferiori per l'SSD locale su Microsoft Windows con VM C3 e C3D

Le prestazioni dell'SSD locale sono limitate per le VM C3 e C3D che eseguono Microsoft Windows.

Stiamo apportando dei miglioramenti alle prestazioni.

Prestazioni inferiori per i volumi Hyperdisk Extreme collegati alle istanze n2-standard-80 che eseguono Microsoft Windows

Le istanze Microsoft Windows in esecuzione su tipi di macchine n2-standard-80 possono raggiungere al massimo 80.000 IOPS su tutti i volumi Hyperdisk Extreme collegati all'istanza.

Risoluzione

Per raggiungere fino a 160.000 IOPS con le istanze N2 che eseguono Windows, scegli uno dei seguenti tipi di macchina:

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

Basso throughput di rete quando si utilizza gVNIC

Le VM Windows Server 2022 e Windows 11 che utilizzano il pacchetto GooGet del driver gVNIC nella versione 1.0.0@44 o precedente potrebbero riscontrare un basso throughput di rete quando utilizzano Google Virtual NIC (gVNIC).

Per risolvere il problema, aggiorna il pacchetto GooGet del driver gVNIC alla versione 1.0.0@45 o successiva nel seguente modo:

  1. Controlla la versione del driver installata sulla VM eseguendo il seguente comando come amministratore dal prompt dei comandi o da una sessione di Powershell:

    googet installed

    L'output è simile al seguente:

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

  2. Se la versione del driver google-compute-engine-driver-gvnic.x86_64 è 1.0.0@44 o precedente, aggiorna il Package Repository GooGet eseguendo il seguente comando come amministratore dal prompt dei comandi o da una sessione di PowerShell:

    googet update

I tipi di macchine con vCPU C4, C4D e C3D di grandi dimensioni non supportano le immagini del sistema operativo Windows

I tipi di macchine C4 con più di 144 vCPU e i tipi di macchine C4D e C3D con più di 180 vCPU non supportano le immagini sistema operativo di Windows Server 2012 e 2016. I tipi di macchine C4, C4D e C3D più grandi che utilizzano immagini sistema operativo di Windows Server 2012 e 2016 non riusciranno ad avviarsi. Per risolvere il problema, seleziona un tipo di macchina più piccolo o utilizza un'altra immagine sistema operativo.

Le VM C3D create con 360 vCPU e immagini del sistema operativo Windows non riusciranno ad avviarsi. Per risolvere il problema, seleziona un tipo di macchina più piccolo o utilizza un'altra immagine sistema operativo.

Le VM C4D create con più di 255 vCPU e Windows 2025 non riusciranno ad avviarsi. Per risolvere il problema, seleziona un tipo di macchina più piccolo o utilizza un'altra immagine sistema operativo.

Errore generico del disco su Windows Server 2016 e 2012 R2 per le VM M3, C3, C3D e C4D

Al momento, la possibilità di aggiungere o ridimensionare un Hyperdisk o un Persistent Disk per una VM M3, C3, C3D o C4D in esecuzione non funziona come previsto su guest Windows specifici. Windows Server 2012 R2, Windows Server 2016 e le relative varianti Windows non server non rispondono correttamente ai comandi di collegamento e ridimensionamento del disco.

Ad esempio, la rimozione di un disco da una VM M3 in esecuzione lo scollega da un'istanza Windows Server senza che il sistema operativo Windows riconosca che il disco non è più presente. Le scritture successive sul disco restituiscono un errore generico.

Risoluzione

Devi riavviare la VM M3, C3, C3D o C4D in esecuzione su Windows dopo aver modificato un Hyperdisk o un Persistent Disk affinché le modifiche al disco vengano riconosciute da questi guest.