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 Confidential VM, consulta Limitazioni delle Confidential VM.

Problemi generici

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

Non puoi utilizzare la console Google Cloud per creare VM Spot per A4 e A3 Ultra

Non puoi creare una VM spot che utilizza le serie di macchine A4 o A3 Ultra utilizzando la console Google Cloud . In particolare, nella pagina Crea un'istanza, dopo aver selezionato un tipo di GPU per queste serie di macchine nel riquadro Configurazione macchina, il riquadro Avanzate indica che È necessaria una prenotazione e non consente di selezionare Spot nell'elenco Modello di provisioning delle VM.

Per risolvere il problema, utilizza gcloud CLI o REST per creare VM spot per A4 e A3 Ultra. In alternativa, puoi utilizzare la console Google Cloud per creare VM A4 e A3 Ultra che utilizzano il modello di provisioning vincolato alla prenotazione.

La modifica delle IOPS o del throughput su un disco primario di replica asincrona utilizzando il comando gcloud compute disks update causa un errore falso

Quando utilizzi il comando gcloud compute disks update per modificare IOPS e velocità effettiva su un disco primario di replica asincrona, Google Cloud 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 Google Cloud CLI o la console Google Cloud per vedere se le proprietà del disco mostrano i nuovi valori di IOPS e velocità effettiva. Per saperne di più, consulta Visualizzare le impostazioni delle prestazioni di cui è stato eseguito il provisioning per Hyperdisk.

Il server di metadati potrebbe visualizzare metadati della VM physicalHost precedenti

Dopo aver riscontrato un errore dell'host che sposta un'istanza su un nuovo host, quando interroghi il server dei metadati, potrebbe visualizzare i metadati physicalHost dell'host precedente dell'istanza.

Per risolvere questo problema, esegui una delle seguenti operazioni:

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

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

Quando genera i nomi dei dischi, se il nome risultante supera il limite di 63 caratteri del nome della risorsa, 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 le istanze che hanno pattern 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à, il che potrebbe causare il danneggiamento dei dati.

Per evitare conflitti di nomi del disco, mantieni il valore di baseInstanceName a una lunghezza massima di 54 caratteri.

La creazione di prenotazioni o richieste di prenotazione futura 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 va a buon fine, si verifica una delle seguenti condizioni:

    • 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.

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

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

Limitazioni durante l'utilizzo dei 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 che 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, devono essere presenti 2 dischi SSD, mentre per c3d-standard-8-lssd è necessario un solo disco SSD. Se il numero di dischi non corrisponde, riceverai un errore di configurazione errata dell'SSD locale dal control plane di Compute Engine. Consulta il documento 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 Kubernetes Engine Google Cloud 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 di rilevamento degli 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 una variabilità del throughput TCP a flusso singolo ed essere occasionalmente limitate a 20-25 Gbps. Per ottenere velocità più elevate, 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à di Cloud Monitoring relativa all'utilizzo della CPU nella scheda Compute Engine > Istanze VM > Osservabilità viene scalata solo fino al 50%. Due thread per core è il valore predefinito per tutti i tipi di macchina, ad eccezione di Tau T2D. Per maggiori informazioni, vedi 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 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 ovviare a questo 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 dischi permanenti causato dal ridimensionamento del disco

In alcuni casi, il ridimensionamento di dischi permanenti di grandi dimensioni (~3 TB o più) potrebbe interferire con le prestazioni I/O del disco. Se riscontri questo problema, i tuoi Persistent Disk potrebbero subire un aumento della latenza durante l'operazione di ridimensionamento. Questo problema può influire sui dischi permanenti di qualsiasi tipo.

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

I tuoi processi automatizzati che consumano e utilizzano i dati di risposta dell'API relativi alle quote di impegno basato sulle risorse di Compute Engine potrebbero non riuscire se si verificano tutti i seguenti eventi. I tuoi processi automatizzati possono includere qualsiasi snippet di codice, logica di business o campi di database che utilizzano o memorizzano le risposte 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 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 tutti gli SKU impegnati di Compute Engine.

    Per saperne di più sulle quote per gli impegni e gli SKU con impegno, consulta Quote per gli impegni e le risorse con impegno.

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 tuo 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 API e di conseguenza non va a buon fine.

Come risolvere il problema

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

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

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

Problemi noti per le istanze bare metal

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

Soluzione

Utilizza SLES 15 SP5.

Problemi relativi all'utilizzo delle interfacce di rete dinamiche

Questa sezione descrive i problemi noti relativi all'utilizzo di più interfacce di rete e delle 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

In un'istanza, il riutilizzo di un ID VLAN per una nuova NIC dinamica ha implicazioni per il monitoraggio delle connessioni 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 Compute 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. Elimina la NIC dinamica di esempio e crea 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 di sostituzione. 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 Compute li accetta senza dover valutare le regole firewall in entrata.

Per ulteriori informazioni sul monitoraggio delle connessioni e sulle regole firewall, consulta le 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 l'eliminazione dei 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 dei 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). La chiusura 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 contiene 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

Di seguito sono riportati i problemi noti per le VM Linux.

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:

  • Aggiorna 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

Impossibile avviare la VM SUSE Enterprise dopo aver modificato i tipi di istanze

Dopo aver modificato il tipo di istanza di una VM SUSE Linux Enterprise, l'avvio potrebbe non riuscire e il seguente errore viene ripetuto 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 sue immagini cloud con un initramfs (initial RAM filesystem) versatile 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, cosa che accade durante gli aggiornamenti di sistema, questi flag vengono omessi per impostazione predefinita. Il risultato è un initramfs più piccolo, creato appositamente per l'hardware del sistema attuale, che potrebbe escludere i driver necessari per altri tipi di istanza.

Ad esempio, le istanze C3 utilizzano unità NVMe, che richiedono moduli specifici da includere in initramfs. Se un sistema con un initramfs privo di questi moduli NVMe viene migrato a un'istanza C3, il processo di avvio non riesce. Questo problema può interessare anche altri tipi di istanza con requisiti hardware unici.

Soluzione alternativa

Prima di modificare 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 ripristino 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 significativamente inferiori alle attese per le IOPS sui dischi SSD locali.

Causa principale

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

Soluzione alternativa

Una patch di SUSE per risolvere questo problema non è disponibile o pianificata. Devi invece utilizzare il sistema operativo SLES 15.

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

Se le tue 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 essere perso al riavvio. Ciò 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 interrompendo e avviando la VM finché il problema non viene risolto. La perdita di connettività di rete può essere evitata 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 di Grub. 3. Riavvia la VM.

Il seguente problema è stato risolto il 13 gennaio 2025.

Le immagini pubbliche Google Cloud SUSE 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 Collegamenti simbolici non creati C3 e C3D con SSD locale.

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

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

Per individuare e aggiornare questa impostazione, completa 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. Modifica tutte le righe con 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 alcuni casi 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 tramite il driver NVMe della community è in versione beta, le prestazioni potrebbero non corrispondere a quelle delle istanze Linux. Il driver NVMe della community è stato sostituito dal driver Microsoft StorNVMe nelle immagini pubbliche di Google Cloud . Ti consigliamo di sostituire il driver NVME sulle VM create prima di maggio 2022 e utilizzare invece il driver Microsoft StorNVMe.
  • Dopo aver creato un'istanza, non puoi connetterti immediatamente. Tutte le nuove istanze Windows utilizzano lo strumento System preparation (sysprep) per configurare l'istanza, il 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 eseguono l'autenticazione iniziale 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 ai registri specifici del modello non emulati genererà errori di protezione generale, che possono causare un arresto anomalo del sistema a seconda del sistema operativo guest.

Windows Server 2025 e Windows 11 24h2 - Supporto per la sospensione e la ripresa

Windows Server 2025 e Windows 11 24h2 non possono essere riattivati quando vengono sospesi. Finché il problema non viene risolto, la funzionalità di sospensione e ripristino non sarà supportata per Windows Server 2025 e Windows 11 24h2.

Errori durante la misurazione della deriva temporale NTP utilizzando w32tm sulle VM Windows

Per le VM Windows su Compute Engine che eseguono schede di interfaccia di rete VirtIO, è presente un bug noto in cui la misurazione della deriva NTP produce 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 utilizzano gVNIC non riscontrano questo problema.

Per evitare questo problema, Google consiglia di utilizzare altri strumenti di misurazione della deriva NTP, ad esempio Meinberg Time Server Monitor.

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

Windows Server associa l'unità di avvio al tipo di interfaccia disco iniziale al primo avvio. Per modificare una VM esistente da una serie di macchine precedente che utilizza un'interfaccia disco SCSI a una serie di macchine più recente che utilizza un'interfaccia disco NVMe, esegui 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 del disco vengano scansionati per l'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 modo che utilizzi il nuovo tipo di macchina.
  3. Avvia la VM.

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

Larghezza di banda limitata con gVNIC sulle VM Windows

Il driver gVNIC incluso nelle immagini Windows offerte da Compute Engine può raggiungere fino a 50 Gbps di larghezza di banda di rete sulle istanze Windows, sia per le prestazioni di rete standard sia per le prestazioni di rete Tier_1 per VM. Una versione aggiornata del driver gVNIC può offrire prestazioni a velocità di linea (fino a 200 Gbps) e supporto per i frame Jumbo.

Il driver aggiornato è disponibile solo per le serie di macchine di terza generazione e successive (esclusa N4). Per maggiori informazioni, vedi Aggiornare la versione di gVNIC sul sistema operativo Windows.

Numero limitato di dischi collegati per le serie di macchine VM più recenti

Le VM in esecuzione su Microsoft Windows con l'interfaccia del disco NVMe (che include T2A, tutte le VM di terza generazione e successive) hanno un limite di 16 dischi per il collegamento dei dischi. Per evitare errori, consolida l'archiviazione Persistent Disk e Hyperdisk fino a un massimo di 16 dischi per VM. Lo spazio di archiviazione SSD locale è escluso da questo problema.

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 per utilizzare il driver Microsoft StorNVMe.

Devi aggiornare il driver NVMe sulla tua 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 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 SSD locale 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.

Sono in corso miglioramenti delle prestazioni.

Scarsa velocità effettiva di rete quando si utilizza gVNIC

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

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

  1. Controlla la versione del driver installata sulla tua VM eseguendo questo comando da un prompt dei comandi o da una sessione PowerShell con privilegi amministrativi:

    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 il seguente comando da un prompt dei comandi dell'amministratore o da una sessione di PowerShell:

    googet update

I tipi di macchine C4D e C3D con un numero elevato di vCPU non supportano le immagini del sistema operativo Windows

I tipi di macchine C4D e C3D con più di 180 vCPU non supportano le immagini sistema operativo Windows Server 2012 e 2016. I tipi di macchine C4D e C3D più grandi che utilizzano immagini sistema operativo Windows Server 2012 e 2016 non verranno avviati. 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 verranno avviate. 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 verranno avviate. 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

La possibilità di aggiungere o ridimensionare un disco Hyperdisk o permanente per una VM M3, C3, C3D o C4D in esecuzione non funziona come previsto su guest Windows specifici in questo momento. Windows Server 2012 R2 e Windows Server 2016, nonché 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 disconnette il disco da un'istanza di Windows Server senza che il sistema operativo Windows riconosca che il disco non è più presente. Le successive scritture sul disco restituiscono un errore generico.

Risoluzione

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