Problemi noti

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

Problemi generici

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

Impossibile creare uno sconto per impegno di utilizzo (CUD) per C4A

Non puoi creare un CUD per l'istanza C4A utilizzando la console Google Cloud, gcloud CLI o REST.

I CUD per C4A non sono disponibili in tutte le regioni. Il supporto verrà aggiunto gradualmente a tutte le regioni.

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, 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 consumata automaticamente (valore predefinito), la creazione di VM con proprietà corrispondenti non consumerà la prenotazione.

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

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

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

Limitazioni relative all'utilizzo dei tipi di macchine 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 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 è richiesto un solo disco SSD. Se il numero del disco non corrisponde, verrà visualizzato un errore di configurazione errata dell'unità SSD locale dal piano di controllo di Compute Engine. Consulta il documento Famiglia di macchine per uso generale 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 comporta un errore di creazione dei nodi o la mancata rilevazione delle unità SSD locali come archiviazione temporanea.

Variabilità della velocità effettiva TCP di un singolo flusso sulle VM C3D

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

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

I gruppi di istanze gestite (MIG) 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 MIG. In questi progetti, la scalabilità automatica in base all'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 VM utilizza un thread per core, la metrica di osservabilità dell'utilizzo della CPU di Cloud Monitoring nella scheda Compute Engine > Istanze VM > Osservabilità viene scalata solo al 50%. Due thread per core è l'impostazione predefinita per tutti i tipi di macchine, tranne Tau T2D. Per ulteriori 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 ulteriori 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 tue istanze VM, potresti non essere in grado di utilizzare la funzionalità SSH nel browser.

Per risolvere il problema, esegui una delle seguenti operazioni:

La riduzione delle dimensioni o l'eliminazione di prenotazioni specifiche impedisce alle VM di utilizzare altre prenotazioni

Se riduci le dimensioni o elimini una prenotazione specifica che è stata utilizzata da una o più VM, le VM orfane non possono utilizzare alcuna prenotazione.

Scopri di più su come eliminare le prenotazioni e modificarne le dimensioni.

Il trasferimento di VM o dischi utilizzando l'API moveInstance o gcloud CLI causa un comportamento imprevisto

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 delle 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 tipi di macchine n2d-standard-64 non raggiungono in modo coerente i limiti di prestazioni

I dischi permanenti collegati alle VM con tipi di macchine n2d-standard-64 non raggiungono in modo coerente il limite di prestazioni massimo di 100.000 IOPS. Questo accade sia per le IOPS in lettura che per quelle in scrittura.

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 dell'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 dei dischi

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

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 utilizzi Google Cloud CLI o l'API Compute Engine, possono verificarsi i seguenti problemi:

  • pd-standard viene configurato come tipo di disco di avvio predefinito e il disco viene creato, a meno che non specifichi un tipo di disco di avvio supportato diverso, ad esempio pd-balanced o pd-ssd.
  • Prima della disponibilità generale (GA) della C3, potevi collegare dischi pd-extreme alle VM C3 e dischi 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 su un nuovo tipo di disco supportato, come descritto in Modificare 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 dischi 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.

Le procedure automatiche potrebbero non riuscire se utilizzano i dati della risposta dell'API relativi alle quote di impegno basate sulle risorse

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

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

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

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

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

Causa principale

Quando hai una quota limitata, se definisci il campo items[].quotas[].limit o quotas[].limit come tipo int, i dati di risposta dell'API per i limiti di quota potrebbero comunque rientrare nell'intervallo per il tipo int e la procedura automatica potrebbe non essere interrotta. 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. La procedura automatica non può utilizzare il valore restituito dal metodo dell'API e di conseguenza non va a buon fine.

Come risolvere il problema

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

Problemi noti per le istanze Bare Metal

Questi sono i problemi noti per le istanze bare metal di Compute Engine.

La statistica dei pacchetti persi non è corretta

Il numero di pacchetti persi 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. Viene visualizzato come RX dropped quando esegui ifconfig.

Problemi noti per le istanze VM Linux

Questi sono i problemi noti per le VM Linux.

La VM SUSE Enterprise non riesce ad avviarsi dopo la modifica dei tipi di istanze

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

            Starting [0;1;39mdracut initqueue hook[0m...
   [  136.146065] dracut-initqueue[377]: Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks:
   [  136.164820] dracut-initqueue[377]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2fD3E2-0CEB.sh: "[ -e "/dev/disk/by-uuid/D3E2-0CEB" ]"
   [  136.188732] dracut-initqueue[377]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2fe7b218a9-449d-4477-8200-a7bb61a9ff4d.sh: "if ! grep -q After=remote-fs-pre.target /run/systemd/generator/systemd-cryptsetup@*.service 2>/dev/null; then
   [  136.220738] dracut-initqueue[377]:     [ -e "/dev/disk/by-uuid/e7b218a9-449d-4477-8200-a7bb61a9ff4d" ]
   [  136.240713] dracut-initqueue[377]: fi"

Causa principale

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

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

Soluzione alternativa

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

dracut --force --no-hostonly

Se il sistema è già interessato dal problema, valuta la possibilità di utilizzare la console seriale o una VM di recupero temporanea per accedere al sistema e rigenerare il file initramfs utilizzando il seguente comando:

dracut -f --no-hostonly -v /boot/initramfs-$(uname -r).img $(uname -r)

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 inferiori alle aspettative per le IOPS sui dischi SSD locali.

Causa principale

Si tratta di un problema all'interno della base di codice di SLES 12.

Soluzione alternativa

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

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

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

Risoluzione

La connettività di rete può essere ripristinata fermando e avviando la VM finché il problema non viene risolto. Per evitare che la perdita di connettività di rete si ripeta, segui questi passaggi: 1. Modifica il file /etc/default/grub e rimuovi i parametri del kernel net.ifnames=0 e biosdevname=0. 2. Rigenera la configurazione di grub. 3. Riavvia la VM.

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

Risoluzione

Per aggiungere regole udev per SUSE e immagini personalizzate, consulta Symlinks not created C3 and C3D with Local SSD.

Impossibile verificare la firma del file repomd.xml

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

Log di esempio:

[root@centos7 ~]# yum update


...

google-cloud-sdk/signature                                                                  | 1.4 kB  00:00:01 !!!
https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64/repodata/repomd.xml: [Errno -1] repomd.xml signature could not be verified for google-cloud-sdk
Trying other mirror.

...

failure: repodata/repomd.xml from google-cloud-sdk: [Errno 256] No more mirrors to try.
https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64/repodata/repomd.xml: [Errno -1] repomd.xml signature could not be verified for google-cloud-sdk

Risoluzione

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

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

Per individuare e aggiornare questa impostazione, segui questi passaggi:

  1. Cerca l'impostazione nel file /etc/yum.repos.d/google-cloud.repo.

    cat /etc/yum.repos.d/google-cloud.repo


[google-compute-engine]
name=Google Compute Engine
baseurl=https://packages.cloud.google.com/yum/repos/google-compute-engine-el7-x86_64-stable
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
[google-cloud-sdk]
name=Google Cloud SDK
baseurl=https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

  2. Cambia 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 alcune istanze che utilizzano l'accesso all'OS, potresti ricevere il seguente messaggio di errore dopo che la connessione è stata stabilita:

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

Risoluzione

Ignora il messaggio di errore.

Problemi noti per le istanze VM Windows

  • Il supporto di NVMe su Windows che utilizza il driver NVMe della community è in versione beta e 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 nelle VM create prima di maggio 2022 e di utilizzare il driver Microsoft StorNVMe.
  • Dopo aver creato un'istanza, non puoi connetterti immediatamente. Tutte le nuove istanze Windows utilizzano lo strumento di preparazione del sistema (sysprep) per configurare l'istanza, il che può richiedere 5-10 minuti.
  • Le immagini di Windows Server non possono essere attivate senza una connessione di rete akms.windows.googlecloud.com e smettono di funzionare se non si autenticano inizialmente entro 30 giorni. Il software attivato da KMS deve essere riattivato ogni 180 giorni, ma KMS tenta di riattivarlo ogni 7 giorni. Assicurati di configurare le istanze Windows in modo che rimangano attive.
  • Il software del kernel che accede a registri specifici 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 dello scostamento di tempo NTP utilizzando w32tm sulle VM Windows

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

w32tm /stripchart /computer:metadata.google.internal

Gli errori sono simili ai seguenti:

Tracking metadata.google.internal [169.254.169.254:123].
The current time is 11/6/2023 6:52:20 PM.
18:52:20, d:+00.0007693s o:+00.0000285s  [                  *                  ]
18:52:22, error: 0x80072733
18:52:24, d:+00.0003550s o:-00.0000754s  [                  *                  ]
18:52:26, error: 0x80072733
18:52:28, d:+00.0003728s o:-00.0000696s  [                  *                  ]
18:52:30, error: 0x80072733
18:52:32, error: 0x80072733

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

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

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

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

Per aggiornare la serie di macchine di una VM:

Da un prompt PowerShell come Administrator, esegui:

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

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

Larghezza di banda limitata con gVNIC sulle VM Windows

Il driver gVNIC pacchettizzato 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 in linea con la velocità della linea (fino a 200 Gbps) e il supporto dei frame jumbo.

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

Collegamento con numero limitato di dischi 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 e le VM che utilizzano Confidential Computing) hanno un limite di attacco di 16 dischi. Per evitare errori, consolida la tua archiviazione su Persistent Disk e Hyperdisk in un massimo di 16 dischi per VM. Lo spazio di archiviazione SSD locale è escluso da questo problema.

Sostituire il driver NVME nelle VM create prima di maggio 2022

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

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

Utilizza i seguenti comandi per installare il pacchetto 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 l'unità SSD locale su Microsoft Windows con VM C3 e C3D

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

Stiamo apportando dei miglioramenti alle prestazioni.

Basso throughput della rete quando si utilizza gVNIC

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

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

  1. Controlla la versione del driver installata sulla VM eseguendo il seguente comando da un prompt dei comandi o da una sessione Powershell di 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 o precedente, aggiorna il repository dei pacchetti GooGet eseguendo il seguente comando da un prompt dei comandi o da una sessione PowerShell di amministratore:1.0.0@44

    googet update

I tipi di macchine C3D con 180 e 360 vCPU 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. L'avvio delle VM C3D create con 180 vCPU e immagini del sistema operativo Windows Server 2012 e 2016 non andrà a buon fine. Per risolvere il problema, seleziona un tipo di macchina più piccolo o utilizza un'altra immagine del sistema operativo.

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

Errore generico del disco su Windows Server 2016 e 2012 R2 per le 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 relative varianti Windows non server non rispondono correttamente ai comandi di aggancio e ridimensionamento del disco.

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

Risoluzione

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