Problemi noti
Questa pagina descrive i problemi noti che potresti riscontrare durante l'utilizzo di Google Cloud VMware Engine.
Problemi generici
Di seguito sono riportati i problemi generali noti che interessano VMware Engine.
Gli allarmi di errore pNIC vCenter integrati si attivano in caso di eventi di rete temporanei
Problema: gli avvisi integrati dell'infrastruttura vCenter, ad esempio "Rilevato tasso di errore pNIC elevato", possono attivarsi in modo intermittente nella console del client vSphere a causa di anomalie temporanee dei pacchetti localizzati.
Dettagli: il framework di avvisi VMware integrato valuta i contatori delle schede di interfaccia di rete fisiche (pNIC) sottostanti in finestre di campionamento brevi e rigide. A causa di questa progettazione, vCenter può attivare avvisi immediati per eventi di routine che non hanno impatto, come rumore transitorio o comportamento di perdita di pacchetti previsto sugli uplink vSAN in standby, anche quando il livello di rete è integro. A causa della ridondanza dei percorsi integrata, questi avvisi non influiscono sulla disponibilità dell'ambiente o sull'integrità dei dati.
Soluzione: non è richiesta alcuna azione o soluzione da parte del cliente. Poiché non è previsto un aggiornamento della sensibilità di campionamento degli allarmi vCenter integrata nel breve termine, Google ha implementato l'intelligence della piattaforma sottostante per gestire e filtrare questi falsi positivi. Per gli ambienti di produzione mirati, Google elimina questi avvisi integrati della console rivolti ai clienti. Invece, il motore di analisi di Google monitora i dati dell'infrastruttura e valuta continuamente il livello fisico utilizzando una media mobile di 30 minuti. Se il motore di analisi di Google identifica un degrado fisico persistente, ad esempio un cavo o un'ottica difettosi, la piattaforma avvisa automaticamente l'Assistenza Google per indagare e risolvere il problema e ti invia sistematicamente una notifica automatica.
Stato: si tratta di una limitazione nota della logica di valutazione degli allarmi vCenter integrata. Google gestisce questo comportamento tramite l'intelligence integrata della piattaforma sottostante. VMware è a conoscenza del problema e ha suggerito la soluzione alternativa.
Upgrade di HCX Manager etichettato erroneamente come upgrade della versione di vSphere
Problema: l'upgrade di HCX Manager è etichettato erroneamente come "Upgrade della versione di vSphere" nella console Google Cloud .
Dettagli: sebbene le notifiche via email specifiche che identificano l'upgrade di HCX vengano inviate almeno 14 giorni e 24 ore prima dell'evento, le notifiche automatiche "L'aggiornamento del tuo cloud privato è iniziato" e "L'aggiornamento del tuo cloud privato è stato completato" riflettono un aggiornamento generale del cloud privato. Inoltre, l'interfaccia della consoleGoogle Cloud etichetta esplicitamente l'operazione come upgrade della versione di vSphere. Questa mancata corrispondenza può causare confusione, in particolare per i clienti che hanno completato di recente un upgrade dello stack completo (ad esempio, da vSphere 7.x a 8.x), poiché sembra che l'ambiente sia sottoposto a un altro aggiornamento importante della piattaforma.
Soluzione alternativa: esamina le email di notifica specifiche di HCX inviate prima del periodo di manutenzione per confermare l'ambito del lavoro. Se la pianificazione è allineata, lo stato "Upgrade della versione di vSphere" nella console Google Cloud si riferisce esclusivamente all'aggiornamento di HCX Manager. Non è richiesta alcuna azione da parte tua.
Stato: si tratta di una limitazione nota dell'attuale progettazione del sistema di notifiche.
Tempo di provisioning per i cloud privati vSphere 8.0 update 3
Problema: VMware Engine ora esegue il deployment di nuovi cloud privati con VMware vSphere versione 8.0 Update 3 e NSX-T 4.2.1.2. Durante questo periodo di upgrade, la creazione e l'espansione del cloud privato utilizzano velocità di provisioning standard per tutti i nuovi deployment con le versioni aggiornate.
Dettagli: la creazione del cloud privato può richiedere fino a 140 minuti.
Soluzione: non è necessaria alcuna soluzione, ma pianifica un tempo aggiuntivo per il deployment di nuovi cloud privati o l'espansione dei cluster esistenti.
Rilevamento: potresti osservare tempi di deployment più lunghi del solito per i nuovi cloud privati o quando espandi i cluster esistenti.
Stato: questo è il comportamento previsto a causa degli aggiornamenti delle versioni e degli upgrade in corso.
La macchina virtuale con Windows Server 2022 KB5022842 (build sistema operativo 20348.1547) configurata con l'avvio protetto abilitato non si avvia (90947)
Dopo aver installato l'aggiornamento di Windows Server 2022 KB5022842 (build sistema operativo 20348.1547), il sistema operativo guest non può avviarsi se le macchine virtuali sono configurate con l'avvio protetto abilitato. Per risolvere il problema, puoi procedere in uno dei seguenti modi:
Esiste un limite di 100 prefissi per gli annunci di route dal cloud privato alla rete VPC
Se l'annuncio di route supera questo limite, alcuni prefissi potrebbero essere ignorati. Per rispettare questo limite, implementa l'aggregazione su NSX-T Edge.
VMware Engine si basa sui router Cloud per annunciare gli intervalli di indirizzi IP (prefissi o CIDR) da NSX a una rete VPC producer di servizi. Questi prefissi diventano route dinamiche personalizzate nella rete VPC del producer di servizi, che è in peering con la tua rete VPC.
Quando configuri la rete VPC per importare route dinamiche personalizzate in questa relazione di peering, i prefissi NSX eseguono il peering delle route personalizzate nella rete VPC. Il numero di prefissi NSX che puoi importare è limitato da due fattori:
- Limite predefinito del router Cloud per il numero di prefissi univoci per regione, ereditato da VMware Engine
- Il numero massimo di route dinamiche in un gruppo di peering nella tua rete VPC
Le operazioni sul cloud privato tentate prima del deployment completo del cloud privato non vanno a buon fine
Le operazioni come l'escalation dei privilegi, l'espansione del cloud privato e la sostituzione dei nodi sono consentite nel portale Google Cloud VMware Engine sui cloud privati operativi di cui non è ancora stato eseguito il provisioning completo. Tuttavia, se provi a eseguire queste operazioni in VMware Engine prima che il cloud privato sia stato completamente distribuito (inclusi NSX-T e HCX), le operazioni non riusciranno. Non tentare di eseguire queste operazioni finché non hai eseguito il deployment completo del tuo cloud privato.
VMware Engine non è ancora completamente supportato dai Controlli di servizio VPC
I Controlli di servizio VPC implementano una soluzione temporanea (soluzione alternativa) per consentirti di utilizzare comunque VMware Engine da un progetto in un perimetro dei Controlli di servizio VPC. Per saperne di più, consulta Controlli di servizio VPC.
Interoperabilità di Apigee con il routing internet on-premise
Se utilizzi Apigee con il peering VPC sulla stessa rete VPC di VMware Engine e configuri VMware Engine per instradare il traffico internet tramite una connessione on-premise, anche la comunicazione in uscita di Apigee potrebbe essere instradata tramite la connessione on-premise.
Questa configurazione avviene quando attivi i Controlli di servizio VPC sul peering servicenetworking.googleapis.com, come descritto in Configura l'accesso a internet per le VM dei workload.
Se il traffico Apigee viene instradato tramite la connessione on-premise, Apigee non utilizza più l'indirizzo IP esterno configurato per la comunicazione in uscita verso i servizi di backend delle API esterni. Se utilizzi l'indirizzo IP esterno di Apigee per le configurazioni del firewall, devi aggiornare le configurazioni del firewall per consentire il traffico dalla tua rete on-premise.
Gli host ESXi potrebbero perdere temporaneamente la connettività durante la raccolta delle informazioni di diagnostica
Gli host ESXi in ambienti con dispositivi NVMe PCIe potrebbero perdere temporaneamente la connettività durante la raccolta delle informazioni di diagnostica.
Causa principale
Quando utilizzi il comando vm-support o l'interfaccia utente di vCenter per raccogliere informazioni sui sistemi ESXi, i log vengono archiviati temporaneamente nella directory ramdisk /tmp. Se il sistema ha molti dispositivi NVMe PCIe o il file di log è di grandi dimensioni, la directory ramdisk /tmp si riempie rapidamente, il che può causare la perdita temporanea della connettività dell'host ESXi fino al completamento della raccolta vm-support.
Soluzione alternativa:
L'esclusione del manifest NVME dalla sezione dei log selezionati nella pagina di creazione del bundle di log impedisce che la directory ramdisk /tmp si riempia e verifica che l'host EXSi non perda la connessione di rete. Per escludere il manifest NVMe, segui questi passaggi:
- Accedi a vCenter utilizzando il nome utente e la password di
cloudowner. - Nell'inventario, fai clic con il tasto destro del mouse sull'istanza vCenter Server in cui vuoi l'esclusione.
- Fai clic su Esporta log di sistema….
- Seleziona l'host ESXi da cui vuoi escludere il bundle di log.
- In Seleziona log, scorri fino ad Archiviazione e deseleziona l'opzione NVMe, quindi fai clic su Log esportati. Il manifest NVMe è ora escluso.
Per saperne di più su questa correzione, consulta VMware ESXi 7.0 Update 3q.
Errore di traduzione del nome della risorsa cloud privato
Se esegui VMware Engine Horizon (VDI) su Google Cloud VMware Engine, potresti riscontrare errori dopo aver modificato i nomi delle risorse del cloud privato per soddisfare gli standard per Google Cloud CLI e l'API VMware Engine.
Il seguente errore di esempio si verifica quando si modificano i nomi delle risorse del cloud privato senza modificare correttamente il provisioning dei pool di desktop Horizon:
Error during Provisioning Cloning of VM Desktop-UK-005 has failed. No resource pool available for the pool: ic-pool-1
Error during Provisioning Cloning of VM Desktop-UK-005 has failed. No datastores available for the pool: {}ic-pool-1
Per risolvere il problema, completa i seguenti passaggi prima della data di traduzione del nome pianificata:
- Accedi alla dashboard di VMware Horizon.
- Modifica tutti i pool di desktop Horizon sia per i pool di cloni completi sia per i pool di cloni istantanei e impostali su Disattiva provisioning.
Una volta completata la modifica del nome della risorsa del cloud privato, completa i seguenti passaggi:
Modifica ogni pool di desktop e riconfigura le seguenti impostazioni nella scheda Impostazioni vCenter per i pool di cloni completi e istantanei:
- Pool di risorse
- Datastore
Imposta lo stato di ogni pool su Abilita provisioning.
Testa ogni pool aggiungendo o rimuovendo un desktop dal pool per verificare che il provisioning funzioni correttamente.
Il team di VMware Engine sta lavorando attivamente per fornire una soluzione di interoperabilità il prima possibile. Per rimanere aggiornato sulla disponibilità delle funzionalità, contatta il team dedicato all'account.