Problemi noti

Questa pagina descrive i problemi noti che potresti riscontrare durante l'utilizzo di Compute Engine. Per i problemi che interessano in modo specifico le VM Confidential VM, consulta Problemi noti di Confidential VM.

Problemi generici

I problemi riportati di seguito forniscono indicazioni per la risoluzione dei problemi o informazioni generali.

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

Se utilizzi un modello 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, si verificano problemi. In particolare:

  • La creazione della prenotazione potrebbe non riuscire. Se l'operazione riesce, si applica una delle seguenti situazioni:

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

    • Se hai creato una prenotazione specifica, la creazione di VM per il targeting specifico della prenotazione non va a buon fine.

  • Creazione della richiesta di prenotazione futura riuscita. Se invece la invii per la revisione, Google Cloud la rifiuta.

Non puoi sostituire il modello di istanza utilizzato per creare una prenotazione o una richiesta di prenotazione futura, né sostituire le proprietà VM del modello. Se vuoi prenotare risorse per i tipi di macchine A2, C3 o G2, esegui una delle seguenti operazioni:

  • Crea un nuovo single-project o una prenotazione condivisa specificando direttamente le proprietà.

  • Per creare una nuova richiesta di prenotazione futura:

    1. Se vuoi impedire a una richiesta di prenotazione futura esistente di limitare le proprietà delle richieste di prenotazione future che puoi creare nel progetto attuale o nei progetti con cui è condivisa la richiesta di prenotazione futura, elimina la richiesta di prenotazione futura.

    2. Crea una single-project o condivisa le proprietà specificando le proprietà direttamente e inviala per la revisione.

Limitazioni quando si utilizzano i tipi di macchine c3-standard-*-lssd e c3d-standard-*-lssd con Google Kubernetes Engine

Quando utilizzi l'API Google Kubernetes Engine, il pool di nodi con l'SSD locale collegato di cui esegui il provisioning deve avere lo stesso numero di dischi SSD del tipo di macchina C3 e C3D selezionato. Ad esempio, se prevedi di creare una VM che utilizza c3-standard-8-lssd, ci devono essere 2 dischi SSD, mentre per c3d-standard-8-lssd è richiesto un solo disco SSD. Se il numero del disco non corrisponde, riceverai un errore di configurazione degli SSD locali dal piano di controllo di Compute Engine. Consulta il documento sulla famiglia di macchine per uso generico per selezionare il numero corretto di dischi SSD locali in base al tipo di macchina C3 o C3Dlssd.

L'utilizzo della console Google Cloud di Google Kubernetes Engine per creare un cluster o un pool di nodi con VM c3-standard-*-lssd e c3d-standard-*-lssd provoca un errore di creazione dei nodi o il rilevamento delle unità SSD locali come archiviazione temporanea.

Variabilità della velocità effettiva TCP a flusso singolo sulle VM C3D

Le VM C3D con dimensioni superiori a 30 vCPU potrebbero presentare una variabilità della velocità effettiva TCP a flusso singolo e occasionalmente essere limitate a 20-25 Gbps. Per ottenere velocità più elevate, utilizza più flussi TCP.

Il gruppo di istanze gestite con serie di macchine T2D non applica la scalabilità automatica come previsto

I gruppi di istanze gestite con VM della serie di macchine T2D nei progetti creati prima del 18 giugno 2023 non rilevano correttamente il carico della CPU sulle VM nel gruppo di istanze gestite. In questi progetti, la scalabilità automatica basata sull'utilizzo della CPU in un gruppo di istanze gestite con VM della serie di macchine T2D potrebbe non essere corretta.

Per applicare una correzione al progetto, contatta l'assistenza clienti Google Cloud.

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

Se la CPU della tua VM utilizza un thread per core, la metrica di osservabilità di Cloud Monitoring sull'utilizzo della CPU nella scheda Istanze VM di Compute Engine > > Osservabilità scala solo al 50%. Due thread per core sono l'impostazione predefinita per tutti i tipi di macchine, tranne Tau T2D. Per maggiori informazioni, consulta Impostare il numero di thread per core.

Per visualizzare l'utilizzo della CPU della VM normalizzato al 100%, visualizza l'utilizzo della CPU in Metrics Explorer. Per saperne di più, consulta Creare grafici con Esplora metriche.

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

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

Per risolvere il problema, procedi in uno dei seguenti modi:

Il ridimensionamento o l'eliminazione di prenotazioni specifiche impedisce alle VM di utilizzare altre prenotazioni

Se ridimensiona o elimini una prenotazione specifica utilizzata da una o più VM, le VM orfane non possono consumare nessuna prenotazione.

Scopri di più sull'eliminazione delle prenotazioni e sul ridimensionamento delle prenotazioni.

Lo spostamento di VM o dischi utilizzando l'API moveInstance o gcloud CLI causa un comportamento imprevisto

Lo spostamento delle istanze di macchine virtuali (VM) mediante il comando gcloud compute instances move o il metodo project.moveInstance potrebbe causare la perdita di dati, l'eliminazione della VM o altri comportamenti imprevisti.

Per spostare le VM, ti consigliamo di seguire le istruzioni in Spostare un'istanza VM tra zone o regioni.

I dischi collegati alle VM con n2d-standard-64 tipi di macchina non raggiungono costantemente i limiti di prestazioni

I dischi permanenti collegati a VM con tipi di macchine n2d-standard-64 non raggiungono in modo coerente il limite massimo di prestazioni di 100.000 IOPS. È il caso delle IOPS di lettura e scrittura.

Nomi temporanei dei 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 i seguenti suffissi al nome originale:

  • -temp
  • -old
  • -new

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

Aumento della latenza per alcuni dischi permanenti causato dal ridimensionamento del disco

In alcuni casi, il ridimensionamento di dischi permanenti di grandi dimensioni (~3 TB o più) potrebbe compromettere le prestazioni di I/O del disco. Se hai riscontrato questo problema, i tuoi dischi permanenti potrebbero riscontrare una maggiore latenza durante l'operazione di ridimensionamento. Questo problema può interessare i dischi permanenti di qualsiasi tipo.

Utilizzo di immagini MBR con VM C3 con SSD locale

Una VM C3 creata utilizzando c3-standard-44-lssd e tipi di macchine più grandi non si avvia correttamente con le immagini MBR.

Possibilità di collegare dischi DP-Standard e DP-Extreme non supportati alle VM C3 e M3

I dischi permanenti standard (pd-standard) sono il tipo di disco di avvio predefinito quando si utilizza Google Cloud CLI o l'API Compute Engine. Tuttavia, i dischi pd-standard non sono supportati sulle VM C3 e M3. Inoltre, le VM C3 non supportano i dischi pd-extreme.

Quando si utilizza Google Cloud CLI o l'API Compute Engine, possono verificarsi i seguenti problemi:

  • pd-standard è configurato come tipo di disco di avvio predefinito e il disco viene creato, a meno che non specifichi un tipo di disco di avvio diverso e supportato, ad esempio pd-balanced o pd-ssd.
  • Prima della disponibilità generale di C3, potevi collegare pd-extreme dischi alle VM C3 e pd-standard dischi alle VM C3 e M3.

Se hai creato una VM C3 o M3 con un tipo di disco non supportato, sposta i dati in un nuovo tipo di disco supportato, come descritto in Cambiare il tipo di disco permanente. Se non modifichi il tipo di disco, le VM continueranno a funzionare, ma alcune operazioni come lo scollegamento e il ricollegamento del disco non riusciranno.

Soluzione alternativa

Per risolvere il problema, procedi in uno dei seguenti modi:

  • Utilizza la console Google Cloud per creare VM C3 o M3 e collegare i dischi. La console crea VM C3 e M3 con dischi di avvio pd-balanced e non consente di collegare tipi di disco non supportati alle VM.
  • Se utilizzi Google Cloud CLI o l'API Compute Engine, configura esplicitamente un disco di avvio di tipo pd-balanced o pd-ssd quando crei una VM.

I processi automatizzati potrebbero non riuscire se utilizzano dati di risposta API per le quote di impegno basate sulle risorse

I processi automatizzati che consumano e utilizzano i dati delle risposte delle API relative alle quote di impegno basate sulle risorse di Compute Engine potrebbero non riuscire se si verifica quanto segue. I processi automatizzati possono includere qualsiasi snippet di codice, logica di business o campo di database che utilizza o archivia le risposte dell'API.

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

  2. Utilizza un int anziché un number per definire il campo per il limite di quota delle risorse nei corpo della risposta dell'API. Puoi trovare il campo nei seguenti modi per ogni metodo:

  3. Hai a disposizione una quota predefinita illimitata per tutti gli SKU impegnati di Compute Engine.

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

Causa principale

Se hai una quota limitata, se definisci il campo items[].quotas[].limit o quotas[].limit come tipo int, i dati delle risposte dell'API per i limiti di quota potrebbero comunque rientrare nell'intervallo per il tipo int e il processo automatizzato potrebbe non essere interrotto. Ma quando il limite di quota predefinito è illimitato, l'API Compute Engine restituisce un valore per il campo limit che non rientra nell'intervallo definito dal tipo int. Il tuo processo automatizzato non può consumare il valore restituito dal metodo API e, di conseguenza, non riesce.

Come aggirare questo problema

Puoi aggirare il problema e continuare a generare report automatici nei seguenti modi:

Problemi noti per le istanze Bare Metal

Questi sono i problemi noti relativi alle istanze bare metal di Compute Engine.

La statistica dei pacchetti persi non è corretta

Il numero di pacchetti eliminati segnalati da VIRTCHNL2_OP_GET_STATS è molto elevato.

La causa principale è che IDPF segnala EthStats::rx_discards al sistema operativo come rtnl_link_stats64::rx_dropped. Questo viene visualizzato come RX dropped quando esegui ifconfig.

Problemi noti per le istanze VM Linux

Questi sono i problemi noti delle VM Linux.

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 un NIC non utilizza l'interfaccia di VirtIO.

Risoluzione

La connettività di rete può essere ripristinata arrestando e avviando la VM fino alla risoluzione del problema. Per evitare che la perdita della connettività di rete si ripeta, procedi come segue: 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.

Le immagini SUSE pubbliche di Google Cloud non includono la configurazione udev richiesta per creare collegamenti simbolici per i dispositivi SSD locali C3 e C3D.

Risoluzione

Per aggiungere regole udev per SUSE e immagini personalizzate, consulta Link simbolici non creati C3 e C3D con SSD locale.

Impossibile verificare la firma 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 mostra 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, disabilita il controllo delle chiavi GPG del repository nella configurazione del repository yum impostando repo_gpgcheck=0. Nelle immagini di base di Compute Engine supportate, questa impostazione potrebbe essere trovata nel file /etc/yum.repos.d/google-cloud.repo. Tuttavia, la tua VM può avere questo set in diversi file di configurazione o strumenti di automazione del repository.

I repository Yum di solito non utilizzano chiavi GPG per la convalida dei repository. Invece, l'endpoint https è attendibile.

Per individuare e aggiornare questa impostazione:

  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 indicano 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 aver stabilito la connessione:

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

Risoluzione

Ignora il messaggio di errore.

Problemi noti per le istanze VM Windows

  • Le istanze che eseguono Windows 11, versione 22H2 non si avviano. Utilizza Windows 11 versione 21H2 finché il problema non verrà risolto.
  • Il supporto per NVMe su Windows con il driver Community NVMe è in versione beta, pertanto le prestazioni potrebbero non corrispondere a quelle delle istanze Linux. Il driver NVMe della community è stato sostituito con il driver Microsoft StorNVMe nelle immagini pubbliche di Google Cloud. Ti consigliamo di sostituire il driver NVME sulle 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 Preparazione del sistema (sysprep) per configurare l'istanza, operazione che può richiedere 5-10 minuti.
  • Le immagini Windows Server non possono essere attivate senza una connessione di rete a kms.windows.googlecloud.com e non funzionano più se non vengono autenticate entro 30 giorni. Il software attivato dal KMS deve riattivarsi ogni 180 giorni, ma il 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 del modello non emulati genererà errori di protezione generali, che possono causare un arresto anomalo del sistema a seconda del sistema operativo guest.

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 per cui la misurazione della deviazione NTP genera errori quando viene utilizzato 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 di Compute Engine con NIC VirtIO. Le VM che usano gVNIC non riscontrano questo problema.

Per evitare questo problema, Google consiglia di utilizzare altri strumenti di misurazione della deviazione NTP, ad esempio il monitoraggio del server temporale di Meinberg.

Dispositivo di avvio inaccessibile dopo l'aggiornamento di una VM da 1a o 2a generazione a una VM di terza generazione o successive

Al primo avvio, Windows Server associa l'unità di avvio al tipo di interfaccia del disco iniziale. Per cambiare una VM esistente da una serie di macchine meno recente che utilizza un'interfaccia di un disco SCSI a una serie di macchine più recente che utilizza un'interfaccia di un disco NVMe, esegui un sysprep del driver Windows PnP prima di arrestare la VM. Questo sysprep prepara solo i driver di dispositivo e garantisce che tutti i tipi di interfaccia del disco vengano analizzati per rilevare l'unità di avvio all'avvio successivo.

Per aggiornare la serie di macchine di una VM, segui questi passaggi:

Da un prompt di PowerShell mentre Administrator esegue:

PS C:\> start rundll32.exe sppnp.dll,Sysprep_Generalize_Pnp -wait
  1. Arresta la VM.
  2. Cambiare la VM nel nuovo tipo di macchina.
  3. Avviare la VM.

Se la nuova VM non si avvia correttamente, ripristina il tipo di macchina originale per riavviarla. L'avvio dovrebbe essere corretto. Consulta i requisiti per la migrazione per assicurarti di soddisfarli. quindi riprova a seguire le istruzioni.

Larghezza di banda limitata con gVNIC su Microsoft Windows con VM C3 e C3D

Sui sistemi operativi Windows, il driver gVNIC non raggiunge i limiti di larghezza di banda documentati. Il driver gVNIC può raggiungere fino a 85 Gbps di larghezza di banda di rete sulle VM C3 e C3D che eseguono Microsoft Windows, sia per la rete predefinita che per le prestazioni di rete Tier_1 per VM.

Sostituisci il driver NVME sulle 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 in modo da utilizzare il driver Microsoft StorNVMe.

Devi aggiornare il driver NVMe sulla VM prima di modificare 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 comandi seguenti per installare il pacchetto del 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 gli SSD locali 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.

Sono in corso miglioramenti delle prestazioni.

Prestazioni IOPS inferiori per Hyperdisk Extreme su Microsoft Windows con VM C3 e M3

Le prestazioni di Hyperdisk Extreme sono limitate sulle VM Microsoft Windows.

Sono in corso miglioramenti delle prestazioni.

Velocità effettiva di rete scarsa quando si utilizza gVNIC

Le VM Windows Server 2022 e Windows 11 che utilizzano il driver gVNIC del pacchetto GooGet versione 1.0.0@44 o precedenti potrebbero riscontrare una scarsa velocità effettiva di rete quando si utilizza il NIC virtuale Google (gVNIC).

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

  1. Verifica quale versione del driver è installata sulla VM eseguendo questo comando dal prompt dei comandi di un amministratore 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 repository pacchetti GooGet eseguendo il comando seguente da un prompt dei comandi dell'amministratore o da una sessione di PowerShell:

    googet update

I tipi di macchine C3D 180 e 360 vCPU non supportano le immagini del sistema operativo Windows

I tipi di macchine vCPU C3D da 180 vCPU non supportano le immagini sistema operativo Windows Server 2012 e 2016. Le VM C3D create con 180 vCPU e immagini dei sistemi operativi Windows Server 2012 e 2016 non si avviano. Per aggirare questo 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 si avviano. Per aggirare 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 VM M3, C3 e C3D

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

Ad esempio, la rimozione di un disco da una VM M3 in esecuzione disconnette il disco da un'istanza di Windows Server senza che il sistema operativo Windows riconosca la sua scomparsa. Le scritture successive sul disco restituiscono un errore generico.

Risoluzione

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