Dopo un upgrade a vCenter Server, prendere in considerazione le opzioni e i requisiti post-upgrade.

  • Completare le riconfigurazioni dei componenti che potrebbero essere necessarie per le modifiche durante l'upgrade.
  • Verificare di aver compreso il processo di autenticazione e di identificare le origini identità.
  • Se è stata effettuata la migrazione di vCenter Server su Windows a vCenter Server Appliance di destinazione e si utilizza un nome utente del sistema operativo locale per accedere al servizio vCenter Single Sign-On, è necessario ricreare quest'ultimo e riassegnargli le autorizzazioni.
  • Se è stato eseguito un upgrade, effettuare l'upgrade tutti i moduli aggiuntivi collegati all'istanza di vCenter Server in questione, ad esempio Update Manager. Se è stata eseguita una migrazione da vCenter Server per Windows a vCenter Server Appliance, anche il modulo Update Manager viene migrato a vSphere Lifecycle Manager.
  • Facoltativamente, eseguire l'upgrade o la migrazione degli host ESXi nell'inventario di vCenter Server alla stessa versione dell'istanza di vCenter Server.
  • Se si utilizza Update Manager nella distribuzione vCenter Server e Update Manager e vCenter Server erano in esecuzione su macchine separate prima della migrazione, è consigliabile interrompere o eliminare la macchina host Update Manager una volta completata la migrazione. Prima di eliminare la macchina host Update Manager, tenere in considerazione quanto segue:
    • La macchina host potrebbe essere necessaria per eseguire il rollback dell'ambiente di cui è stato eseguito l'upgrade o la migrazione.
    • È possibile che nella macchina sia in esecuzione un altro software.
  • Se si utilizza l'autenticazione smart card, assicurarsi di tenere aperta la porta della smart card nell'ambiente client. Per impostazione predefinita, la porta della smart card è aperta in vCenter Server. Per informazioni dettagliate sulla porta della smart card, vedere lo strumento VMware Ports and Protocols™ all'indirizzo https://ports.vmware.com
  • Se si prevede di installare Windows 11 come sistema operativo guest in una macchina virtuale, è necessario configurare un provider di chiavi. L'installazione di Windows 11 richiede Trusted Platform Module (TPM) 2.0. Quando si installa Windows 11 come sistema operativo guest in una macchina virtuale, anziché utilizzare un TPM fisico, è possibile utilizzare un Virtual Trusted Platform Module (vTPM). Un vTPM è una rappresentazione basata sul software di un chip TPM 2.0 fisico. Un vTPM dipende dalla crittografia della macchina virtuale per proteggere i dati fondamentali di TPM. È quindi necessario configurare un provider di chiavi. Per informazioni sui provider di chiavi supportati da vSphere, vedere il capitolo Crittografia della macchina virtuale nella documentazione relativa alla sicurezza di vSphere. Il modo più semplice consiste nel configurare un VMware vSphere® Native Key Provider™. vSphere Native Key Provider è incluso in tutte le versioni di vSphere e non richiede un server chiavi esterno. Per informazioni sulla configurazione di vSphere Native Key Provider, vedere il capitolo Configurazione e gestione di vSphere Native Key Provider nella documentazione relativa alla sicurezza di vSphere. Come per tutte le soluzioni di sicurezza, tenere presenti la progettazione del sistema, le considerazioni sull'implementazione e i compromessi relativi all'utilizzo di vSphere Native Key Provider.

  • Se prima dell'aggiornamento è stato modificato il livello di automazione del cluster DRS, è possibile continuare a utilizzare le impostazioni modificate o ripristinare il livello di automazione completo.