Problemi noti

In questa pagina vengono descritti i problemi noti che potresti riscontrare durante l'utilizzo di Compute Engine. Per problemi che interessano in modo specifico Confidential VM, consulta Problemi noti di Confidential VM.

Problemi generici

I seguenti problemi 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, 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 (impostazione predefinita), la creazione di VM con proprietà corrispondenti non consumerà la prenotazione.

    • Se hai creato una prenotazione specifica, la creazione di VM per scegliere come target in modo specifico la prenotazione non va a buon fine.

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

Non puoi sostituire il modello di istanza utilizzato per creare una prenotazione o una richiesta di prenotazione futura oppure eseguire l'override delle proprietà della VM del modello. Se vuoi prenotare risorse per i tipi di macchina A2, C3 o G2, esegui invece una delle seguenti operazioni:

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

Quando utilizzi l'API Google Kubernetes Engine, il pool di nodi con SSD locale collegato di cui esegui il provisioning deve avere lo stesso numero di dischi SSD dei tipo di macchina C3 e C3D selezionati. Ad esempio, se prevedi di creare una VM che utilizza c3-standard-8-lssd, è necessario avere 2 dischi SSD, mentre per una c3d-standard-8-lssd è necessario solo un disco SSD. Se il numero del disco non corrisponde, verrà visualizzato un errore di configurazione errata dell'SSD locale 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 C3D lssd.

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 comporta un errore di creazione dei nodi o un errore nel rilevare gli SSD locali come spazio di archiviazione temporaneo.

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

Le VM C3D più grandi di 30 vCPU potrebbero riscontrare variabilità della velocità effettiva TCP a flusso singolo e talvolta essere limitate a 20-25 Gbps. Per ottenere tariffe più elevate, utilizza più flussi TCP.

Il gruppo di istanze gestite con serie di macchine T2D non scala automaticamente come previsto

I gruppi di istanze gestite con VM delle 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 delle 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 VM utilizza un thread per core, la metrica di osservabilità di Cloud Monitoring relativa all'utilizzo della CPU nella scheda Compute Engine > Istanze VM > Osservabilità scala solo al 50%. Due thread per core sono l'impostazione predefinita per tutti i tipi di macchina, ad eccezione di 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 maggiori informazioni, consulta Creare grafici con Metrics Explorer.

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 nel browser.

Per risolvere il problema, esegui una delle seguenti operazioni:

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

Se riduci le dimensioni o elimini una prenotazione specifica consumata da una o più VM, le VM orfane non possono utilizzare alcuna 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 provoca comportamenti imprevisti

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

Per spostare le VM, ti consigliamo di seguire le istruzioni riportate 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 delle prestazioni

I dischi permanenti collegati a VM con tipi di macchina n2d-standard-64 non raggiungono in modo coerente il limite massimo delle prestazioni di 100.000 IOPS. Questo è 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 dell'API instances.update, Compute Engine potrebbe modificare temporaneamente il nome dei dischi della tua VM, aggiungendo i seguenti suffissi al nome originale:

  • -temp
  • -old
  • -new

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

Aumento della latenza per alcuni dischi permanenti a causa del ridimensionamento del disco

In alcuni casi, il ridimensionamento dei dischi permanenti di grandi dimensioni (circa 3 TB o più) potrebbe compromettere le prestazioni di I/O del disco. Se ti interessa questo problema, i tuoi dischi permanenti potrebbero riscontrare una latenza maggiore 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 macchina più grandi non si avvia correttamente con le immagini MBR.

In grado di collegare dischi DP-Standard e DP-Extreme non supportati a 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 utilizzi 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, come pd-balanced o pd-ssd.
  • Prima della disponibilità generale (GA) di C3, potevi collegare pd-extreme dischi alle VM C3 e pd-standard 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 andranno a buon fine.

Soluzione

Per risolvere il problema, esegui una delle seguenti operazioni:

  • 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 in modo esplicito un disco di avvio di tipo pd-balanced o pd-ssd durante la creazione di una VM.

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

I processi automatizzati che utilizzano 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 uno dei seguenti casi. I processi automatizzati possono includere snippet di codice, logica di business o campi di database che utilizzano o archiviano le risposte dell'API.

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

  2. Utilizza int anziché number per definire il campo per il limite della quota delle risorse nei corpi delle risposte dell'API. Puoi trovare il campo nei seguenti modi per ogni 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 impegni e 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 automatico potrebbe non essere interrotto. Tuttavia, 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ò utilizzare il valore restituito dal metodo API e di conseguenza ha esito negativo.

Come risolvere questo problema

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

Problemi noti relativi alle 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

Per le immagini di CentOS e Red Hat Enterprise Linux (RHEL) 7 OS fornite da Google, i nomi delle interfacce di rete prevedibili sono disabilitati per impostazione predefinita.

Tuttavia, 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 delle interfacce 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. È possibile impedire che la perdita di connettività di rete si ripeta procedendo nel seguente modo: 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 pubbliche SUSE 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 la sezione Link simboli C3 e C3D non creati con SSD locale.

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 cerchi di installare o aggiornare il software utilizzando yum. Questo errore indica che hai una chiave GPG di repository scaduta o errata.

Esempio di log:

[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 presente nel file /etc/yum.repos.d/google-cloud.repo. Tuttavia, la tua VM può avere questo valore in file di configurazione del repository o in strumenti di automazione diversi.

I repository Yum di solito non utilizzano chiavi GPG per la convalida del repository. L'endpoint https è invece considerato attendibile.

Per individuare e aggiornare questa impostazione, svolgi i seguenti 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. Cambia in repo_gpgcheck=0 tutte le righe che indicano repo_gpgcheck=1.

    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 relativi alle istanze VM Windows

  • Le istanze che eseguono Windows 11, versione 22H2 non si avviano. Utilizza Windows 11 versione 21H2 finché il problema non viene risolto.
  • Il supporto di NVMe su Windows utilizzando il driver Community NVMe è in beta e le prestazioni potrebbero non corrispondere a quelle delle istanze Linux. Il driver Community NVMe è stato sostituito con il driver Microsoft StorNVMe nelle immagini pubbliche di Google Cloud. Ti consigliamo di sostituire il driver NVME nelle VM create prima di maggio 2022 e di utilizzare invece il driver Microsoft StorNVMe.
  • Dopo aver creato un'istanza, non puoi connetterti istantaneamente. Tutte le nuove istanze Windows utilizzano lo strumento Preparazione del sistema (sysprep) per configurare l'istanza. Il completamento dell'operazione può richiedere 5-10 minuti.
  • Le immagini Windows Server non possono essere attivate senza una connessione di rete a kms.windows.googlecloud.com e smettere di funzionare se non vengono autenticate inizialmente entro 30 giorni. Il software attivato dal KMS deve riattivare 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 dei modelli non emulati genererà errori di protezione generale, che possono causare un arresto anomalo del sistema a seconda del sistema operativo guest.

Errori durante la misurazione della deviazione temporale 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 delle deviazioni NTP genera errori quando si utilizza il comando seguente:

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 delle deviazioni NTP, come il monitoraggio dei server temporali di Meinberg.

Lo spostamento di una VM Windows su una serie di macchine di terza generazione causa problemi di avvio

Se sposti una VM Windows su una serie di macchine di terza generazione (ad esempio, C3 o H3) da una serie di macchine di prima o seconda generazione (ad esempio N1 o N2), la VM non verrà avviata quando la riavvii.

Per risolvere questo problema, procedi nel seguente modo:

  1. Conferma che il disco di avvio della VM di cui vuoi eseguire l'upgrade sia compatibile con i tipi di macchine di terza generazione eseguendo il comando gcloud compute disks describe:

    gcloud compute disks describe DISK_NAME --zone=ZONE

    Sostituisci quanto segue:

    • DISK_NAME: con il nome del disco di avvio
    • ZONE: la zona del disco

    L'output deve contenere quanto segue per utilizzare il disco di avvio con una serie di macchine di terza generazione:

    guestOsFeatures:
...
- type: GVNIC
- type: WINDOWS

  2. Arresta la VM di cui vuoi eseguire l'upgrade.

  3. Scollega il disco di avvio della VM.

  4. Utilizza la console Google Cloud per creare una VM Windows con le seguenti proprietà:

    • Zona: la stessa zona della VM originale
    • Disco di avvio: il disco di avvio della VM originale
    • Serie di macchine: una serie di macchine di terza generazione

Velocità effettiva di rete scadente durante l'utilizzo di gVNIC

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

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

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

    googet update

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 usa 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 tua 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 da utilizzare per creare nuove VM che usano 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 SSD locali su Microsoft Windows con VM C3 e C3D

Le prestazioni degli SSD locali sono limitate per le VM C3 e C3D che eseguono Microsoft Windows.

Stiamo apportando dei 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.

Stiamo apportando dei miglioramenti delle prestazioni.

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

I tipi di macchine C3D con 180 vCPU non supportano le immagini del sistema operativo Windows Server 2012 e 2016. Non sarà possibile avviare le VM C3D create con 180 vCPU e immagini sistema operativo Windows Server 2012 e 2016. Per risolvere il problema, seleziona un tipo di macchina più piccolo o utilizza un'altra immagine del sistema operativo.

Non sarà possibile avviare le VM C3D create con 360 vCPU e immagini del sistema operativo Windows. Per risolvere il problema, seleziona un tipo di macchina più piccolo o utilizza un'altra immagine del sistema operativo.

Errore generico del disco in 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 di collegamento e ridimensionamento del disco.

Ad esempio, se rimuovi un disco da una VM M3 in esecuzione, il disco viene disconnesso da un'istanza di Windows Server senza che il sistema operativo Windows riconosca che il disco è esaurito. 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 Persistent Disk affinché le modifiche al disco vengano riconosciute da questi guest.