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 problemi generali noti che interessano VMware Engine.
Gli allarmi di errore pNIC vCenter integrati vengono attivati in caso di eventi di rete temporanei
Problema: gli allarmi dell'infrastruttura vCenter integrati, ad esempio "Tasso di errori pNIC elevato rilevato", possono attivarsi a intermittenza nella console vSphere Client a causa di anomalie transitorie e localizzate dei pacchetti.
Dettagli: il framework di avvisi VMware integrato valuta i contatori della scheda di interfaccia di rete (pNIC) fisica sottostante in finestre di campionamento brevi e rigide. A causa di questa progettazione, vCenter può attivare avvisi immediati per eventi di routine e non impattanti, come rumore transitorio o comportamento di perdita di pacchetti previsto sui collegamenti uplink vSAN in standby, anche quando il livello di rete è integro. Grazie alla ridondanza del percorso 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 alla sensibilità di campionamento degli avvisi vCenter integrati 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 sopprime questi avvisi della console integrati rivolti ai clienti. Il motore di Google Analytics monitora invece 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 una fibra ottica difettosi, la piattaforma avvisa automaticamente l'assistenza Google per indagare e risolvere il problema e ti invia sistematicamente una notifica automatica.
Stato: questa è una limitazione nota della logica di valutazione degli avvisi vCenter integrata. Google gestisce questo comportamento tramite l'intelligence della piattaforma sottostante integrata. VMware è a conoscenza del problema e ha fornito una soluzione alternativa.
L'upgrade di HCX Manager è etichettato erroneamente come upgrade della versione vSphere
Problema: l'upgrade di HCX Manager è etichettato erroneamente come "upgrade della versione di vSphere" nella console Google Cloud .
Dettagli: anche se le notifiche email specifiche che identificano l'upgrade di HCX vengono 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 vSphere. Questa mancata corrispondenza può causare confusione, in particolare per i clienti che hanno recentemente completato un upgrade full stack (ad esempio, da vSphere 7.x a 8.x), in quanto sembra che l'ambiente stia subendo 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 "Aggiornamento versione 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 quando esegui il deployment di nuovi cloud privati o espandi i cluster esistenti.
Rilevamento: potresti notare tempi di deployment più lunghi del solito per i nuovi cloud privati o quando espandi i cluster esistenti.
Stato: si tratta di un 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 SO 20348.1547), il sistema operativo guest non può essere avviato quando 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 tuo cloud privato alla tua rete VPC
Se l'annuncio di route supera questo limite, alcuni prefissi potrebbero essere eliminati. Per rispettare questo limite, implementa l'aggregazione su NSX-T Edge.
VMware Engine si basa sui Cloud Router 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 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 del cloud privato tentate prima del deployment completo del cloud privato non vanno a buon fine
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 che non sono ancora completamente sottoposti a provisioning. Tuttavia, se tenti queste operazioni in VMware Engine prima che il cloud privato sia completamente implementato (inclusi NSX-T e HCX), queste operazioni non vanno a buon fine. Non tentare queste operazioni finché non avrai eseguito il deployment completo del cloud privato.
VMware Engine non è ancora completamente supportato da Controlli di servizio VPC
I Controlli di servizio VPC implementano una soluzione provvisoria (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 tua connessione on-premise.
Questa configurazione si verifica quando abiliti i Controlli di servizio VPC sul peering servicenetworking.googleapis.com come descritto in Configura l'accesso a internet per le VM dei carichi di lavoro.
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 con i servizi di backend API esterni. Se utilizzi l'indirizzo IP esterno di Apigee per le configurazioni del firewall, devi aggiornare queste configurazioni per consentire il traffico dalla tua rete on-premise.
Gli host ESXi potrebbero perdere temporaneamente la connettività durante la raccolta delle informazioni diagnostiche
Gli host ESXi negli 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 la UI 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ò portare
l'host ESXi a perdere temporaneamente la connettività fino al completamento
della raccolta vm-support.
Soluzione alternativa:
L'esclusione del manifest NVME dalla sezione dei log selezionati nella pagina di creazione del pacchetto di log impedisce il riempimento della directory ramdisk /tmp e verifica che l'host ESXi non perda la connettività di rete. Per escludere il
manifest NVMe:
- Accedi a vCenter utilizzando il nome utente e la password di
cloudowner. - Nell'inventario, fai clic con il tasto destro del mouse sull'istanza di vCenter Server in cui vuoi l'esclusione.
- Fai clic su Esporta log di sistema….
- Seleziona l'host ESXi da cui vuoi escludere il pacchetto di log.
- In Seleziona log, scorri fino a 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 la denominazione delle risorse del cloud privato per rispettare 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 per i pool di cloni completi e istantanei e impostali su Disattiva provisioning.
Una volta completata la modifica del nome della risorsa 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 cloni istantanei:
- Pool di risorse
- Datastore
Imposta di nuovo 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 al tuo account.