Problemi noti

In questa pagina vengono descritti i problemi noti che potresti riscontrare durante l'utilizzo in Compute Engine. Per problemi che riguardano in modo specifico per le Confidential VM, vedi 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 e la revisione, si verificano problemi. In particolare:

  • La creazione della prenotazione potrebbe non riuscire. Se l'operazione riesce, uno dei si applica quanto segue:

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

    • Se hai creato una prenotazione specifica, creando VM per un target specifico la prenotazione non va a buon fine.

  • Creazione della richiesta di prenotazione futura riuscita. Tuttavia, se invii per la revisione, Google Cloud rifiuta la tua richiesta.

Non puoi sostituire il modello di istanza utilizzato per creare una prenotazione o un futuro una richiesta di prenotazione o eseguire l'override delle proprietà VM del modello. Se vuoi riserva risorse per i tipi di macchina A2, C3 o G2, effettua una delle seguenti operazioni anziché:

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 SSD locale collegato di cui esegui il provisioning deve avere lo stesso numero di Dischi SSD come tipo di macchina C3 e C3D selezionato. Ad esempio, se prevedi Per creare una VM che utilizza c3-standard-8-lssd, devono essere presenti 2 dischi SSD, mentre per c3d-standard-8-lssd è sufficiente un solo disco SSD. Se il numero del disco non corrisponde, riceverai un errore di configurazione dell'SSD locale dal piano di controllo di Compute Engine. Consulta le Famiglia di macchine per uso generico documento per selezionare il numero corretto di dischi SSD locali in base ai modelli C3 o C3D tipo di macchina lssd.

Utilizzo della console Google Cloud di Google Kubernetes Engine per creare un cluster o un pool di nodi con c3-standard-*-lssd e c3d-standard-*-lssd VM comporta la creazione del nodo o errore nel rilevamento degli SSD locali come spazio di archiviazione temporaneo.

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

Le VM C3D con più di 30 vCPU potrebbero registrare una velocità effettiva TCP a flusso singolo e, occasionalmente, essere limitati 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

Gruppi di istanze gestite che hanno VM della serie di macchine T2D in progetti che create prima del 18 giugno 2023, non rilevano correttamente il carico della CPU sulle VM gruppo di istanze gestite In questi progetti, la scalabilità automatica basata sull'utilizzo della CPU in un gruppo di istanze gestite con Le VM della serie di macchine T2D potrebbero non essere corrette.

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, l'utilizzo della CPU la metrica di osservabilità di Cloud Monitoring Compute Engine > Istanze VM > Osservabilità viene ridimensionato solo al 50%. Due thread per core è l'impostazione predefinita per tutte le macchine tranne Tau T2D. Per ulteriori informazioni, vedi Imposta 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 ulteriori informazioni, vedi Crea 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, potrebbe non essere in grado di utilizzare il protocollo SSH nel browser funzionalità.

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 ridimensioni o elimini un prenotazione specifica utilizzata da una o più VM, le VM orfane non possono consumare nessuna prenotazione.

Scopri di più su eliminare le prenotazioni e sul ridimensionamento delle prenotazioni.

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

Spostamento delle istanze di macchine virtuali (VM) mediante gcloud compute instances move o il comando Metodo project.moveInstance potrebbe causare la perdita di dati, l'eliminazione delle 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 n2d-standard-64 tipi di macchina non a raggiungere regolarmente il limite di prestazioni massimo di 100.000 IOPS. Questo è il per le IOPS di lettura e scrittura.

Nomi temporanei dei dischi

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

  • -temp
  • -old
  • -new

Compute Engine rimuove il suffisso e ripristina i nomi dei dischi originali come aggiornamento completato.

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ù) che disturbano le prestazioni di I/O del disco. Se questa situazione ti riguarda i tuoi dischi permanenti potrebbero riscontrare una maggiore latenza durante dell'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.

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 utilizzando Google Cloud CLI o l'API Compute Engine. Tuttavia, pd-standard dischi non sono supportate sulle VM C3 e M3. Inoltre, le VM C3 non supportano pd-extreme i dischi permanenti.

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 è creato, a meno che non specifichi un tipo di disco di avvio supportato diverso, come pd-balanced o pd-ssd.
  • Prima della disponibilità generale di C3, potresti 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 di dati in un nuovo tipo di disco supportato, come descritto in Modifica il tipo di disco permanente. Se non modifichi il tipo di disco, le VM continueranno a funzionare, ma operazioni come scollegamento e ricollegamento del disco non andranno a buon fine.

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 pd-balanced dischi di avvio e non consente collegare tipi di disco non supportati alle VM.
  • Se utilizzi Google Cloud CLI o l'API Compute Engine, configura esplicitamente un disco di avvio digita pd-balanced o pd-ssd durante la creazione di una VM.

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

I tuoi processi automatizzati che consumano e utilizzano i dati di risposta delle API su le quote di impegno basate sulle risorse di Compute Engine potrebbero non andare a buon fine se si verifica una delle seguenti condizioni. I tuoi processi automatizzati possono includere snippet di codice, logica di business o campi di database che utilizzano o archiviare 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 di risorse nei corpi di risposta dell'API. Puoi trovare il campo nei seguenti modi per ciascun metodo:

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

    Per saperne di più sulle quote per impegni e SKU impegnati, consulta Quote per impegni e risorse impegnate.

Causa principale

Se hai una quota limitata, se definisci items[].quotas[].limit o campo quotas[].limit come tipo int, i dati di risposta API per la quota potrebbero comunque rientrare nell'intervallo per il tipo int e i limiti processo potrebbe non essere interrotto. Ma quando il limite 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 tuo processo automatizzato non può utilizzerà il valore restituito dal metodo API e, di conseguenza, avrà esito negativo.

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 un numero 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, la rete l'accesso potrebbe andare perso al riavvio. Questo accade perché RHEL non supporta disabilitazione 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 arresto e avvio della VM finché il problema non viene risolto. È possibile evitare la perdita della connettività di rete ricorrente seguendo 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.

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, vedi Link simbolici non creati C3 e C3D con SSD locale.

Impossibile verificare la firma repomd.xml

Sui sistemi Red Hat Enterprise Linux (RHEL) o CentOS 7, potresti vedere il seguente errore quando provi a installare o aggiornare il software utilizzando yum. Questo 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, disponibile nel file /etc/yum.repos.d/google-cloud.repo. Tuttavia, la VM può avere questo set in diversi file di configurazione del repository o strumenti di automazione.

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 utilizza OS Login, potresti ricevere il seguente messaggio di errore dopo connessione attiva:

/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. Usa Windows 11 versione 21H2 finché il problema non verrà risolto.
  • Supporto per NVMe su Windows con il driver Community NVMe attivo Beta, il rendimento potrebbe non corrispondere delle istanze Linux. Il driver NVMe della community è stato sostituito con il driver Microsoft StorNVMe in immagini pubbliche di Google Cloud. Ti consigliamo di sostituisci il driver NVME sulle VM create prima di maggio 2022 e usare il driver Microsoft StorNVMe.
  • Dopo aver creato un'istanza, non puoi connetterti immediatamente. Tutti le nuove istanze Windows utilizzano Preparazione del sistema (sysprep) per configurare l'istanza, operazione che può richiedere 5-10 minuti.
  • Impossibile attivare le immagini Windows Server senza una connessione di rete a kms.windows.googlecloud.com e smettono di funzionare in caso contrario. per la prima volta entro 30 giorni. Software attivato dal KMS deve riattivare ogni 180 giorni, ma il KMS tenta di riattivarla ogni 7 giorni. Assicurati di configura le tue istanze Windows in modo che rimangano attivi.
  • Software kernel che accede a dati non emulati registri specifici del modello 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 in cui la misurazione della deviazione NTP produce 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 di Compute Engine con NIC VirtIO. VM che utilizzano gVNIC non riscontrerai questo problema.

Per evitare questo problema, Google consiglia di usare altri strumenti di misurazione della deviazione NTP, come Monitor di meinberg time Server.

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

Windows Server associa l'unità di avvio al tipo di interfaccia del disco iniziale su alla prima avvio. Per modificare una VM esistente da una serie di macchine meno recente. che utilizza un'interfaccia di un disco SCSI per una serie di macchine più recente che utilizza 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 tutti i tipi di interfaccia del disco 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, reimpostala sulla tipo di macchina originale per eseguire di nuovo la VM. Dovrebbe iniziare correttamente. Consulta i requisiti per la migrazione per assicurarti di soddisfarli. Quindi, prova a eseguire di nuovo instructions.

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

Sui sistemi operativi Windows, il driver gVNIC non raggiunge la documentazione limiti di larghezza di banda. Il driver gVNIC può raggiungere fino a 85 Gbps di larghezza di banda della rete sulle VM C3 e C3D che eseguono Microsoft Windows, la rete predefinita e 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 creato prima del 1° maggio 2022, devi aggiornare il driver NVMe esistente nella il sistema operativo guest per utilizzare Driver di Microsoft StorNVMe.

Prima di modificare il tipo di macchina, devi aggiornare il driver NVMe sulla VM a 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 usano una macchina di terza generazione Google Cloud.

Usa i comandi seguenti per installare il pacchetto del driver StorNVME e rimuoverlo 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

VM Windows Server 2022 e Windows 11 che utilizzano il pacchetto GooGet del driver gVNIC la versione 1.0.0@44 o precedente potrebbe riscontrare una scarsa velocità effettiva di rete quando utilizzando il NIC virtuale Google (gVNIC).

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

  1. Verifica quale versione del driver è installata sulla VM eseguendo questo comando da un prompt dei comandi o una sessione di PowerShell dell'amministratore:

    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 prima, aggiorna Repository di pacchetti GooGet eseguendo questo comando dal prompt dei comandi dell'amministratore Sessione 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 le immagini dei sistemi operativi Windows Server 2012 e 2016 non si avviano correttamente. Per aggirare 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 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

La possibilità di aggiungere o ridimensionare un Hyperdisk o un Persistent Disk per un o una VM C3D non funziona come previsto su guest Windows specifici. Windows Server 2012 R2 e Windows Server 2016 e le rispettive applicazioni non server Varianti Windows, non rispondono correttamente al collegamento e al ridimensionamento del disco tramite comandi SQL.

Ad esempio, se rimuovi un disco da una VM M3 in esecuzione, il disco viene disconnesso da una su un'istanza Windows Server senza che il sistema operativo Windows riconosca che quando il disco è stato cancellato. Le scritture successive sul disco restituiscono un errore generico.

Risoluzione

Devi riavviare la VM M3, C3 o C3D in esecuzione su Windows dopo la modifica un Hyperdisk o Persistent Disk per far riconoscere le modifiche del disco ospiti.