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 generici noti che interessano VMware Engine.
L'upgrade di HCX Manager è etichettato erroneamente come upgrade della versione vSphere
Problema: l'upgrade di HCX Manager è etichettato erroneamente come "upgrade della versione vSphere" nellaconsolle. Google Cloud
Dettagli: anche se le notifiche via 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 console etichetta esplicitamente l'operazione come un upgrade della versione vSphere.Google Cloud 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), 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 "Upgrade della versione vSphere" nella Google Cloud consolle si riferisce rigorosamente all' aggiornamento di HCX Manager. Non è richiesto alcun intervento da parte tua.
Stato: si tratta di una limitazione nota della progettazione del sistema di notifica corrente.
Tempo di provisioning per i cloud privati di 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 alternativa: non è necessaria alcuna soluzione alternativa, 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: questo è il comportamento previsto a causa degli aggiornamenti di versione e degli upgrade in corso.
La macchina virtuale con Windows Server 2022 KB5022842 (build del sistema operativo 20348.1547) configurata con l'avvio protetto abilitato non si avvia (90947)
Dopo l'installazione dell'aggiornamento KB5022842 di Windows Server 2022 (build del sistema operativo 20348.1547) il sistema operativo guest non può essere avviato quando le macchine virtuali sono configurate con l'avvio protetto abilitato. Per risolvere questo problema, puoi eseguire una delle seguenti operazioni:
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 eliminati. Per rimanere entro 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 del producer di servizi. Questi prefissi diventano route dinamiche personalizzate nella rete VPC del producer di servizi con 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:
- Il limite predefinito del router Cloud per il numero di prefissi univoci per regione, che VMware Engine eredita
- Il numero massimo di route dinamiche in un gruppo di peering nella rete VPC
Le operazioni del cloud privato tentate prima che il cloud privato sia completamente sottoposto a deployment non riescono
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 sottoposto a deployment (inclusi NSX-T e HCX), queste operazioni non riescono. Non tentare queste operazioni finché non hai eseguito il deployment completo del cloud privato.
Controlli di servizio VPC non è ancora completamente supportato da VMware Engine
VPC Service Controls implementa una soluzione provvisoria (soluzione alternativa) per consentirti di utilizzare comunque VMware Engine da un progetto in un perimetro di 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 si verifica quando abiliti i Controlli di servizio VPC sul
servicenetworking.googleapis.com peering come descritto in
Configurare 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 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 diagnostiche
Gli host ESXi negli ambienti con dispositivi NVMe PCIe potrebbero perdere temporaneamente la connettività durante la raccolta delle informazioni diagnostiche.
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ò comportare 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 pacchetto di log impedisce il riempimento della directory ramdisk /tmp e verifica che l'host EXSi non perda la connettività di rete. Per escludere il manifest NVMe:
- Accedi a vCenter utilizzando il nome utente e la password
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 del 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 in modo che soddisfi 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 questo 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 di cloni istantanei e impostali su Disabilita 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 di 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 all'account.