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.
Aggiornamento 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 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 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 la 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 tua rete VPC per importare route dinamiche personalizzate in questa relazione di peering, i prefissi NSX eseguono il peering delle route personalizzate nella tua 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 hai 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 VMware Engine da un progetto all'interno di un perimetro dei Controlli di servizio VPC. Per saperne di più, consulta Controlli di servizio VPC.
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 EXSi 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 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, segui questi 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 lo stato di ogni pool su Abilita provisioning.
Prova 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.