Un ambiente VMware vSphere Foundation 9.0 non nasce installando in fila un ESX e poi un vCenter: si dichiara in un wizard e lo costruisce un’appliance dedicata. Metà dell’obiettivo è sapere quali pezzi la compongono; l’altra metà, capire quando serve un deployment nuovo e quando una convergenza.

I componenti di una piattaforma VVF

vSphere Foundation mette insieme vSphere — cioè ESX, la piattaforma su cui girano VM, workload Kubernetes e AI/ML, e vCenter in edizione Standard, con cui si gestiscono più host a fattor comune — più vSphere Supervisor, vSAN e VCF Operations, con VCF Operations for Logs per il logging centralizzato. vSAN aggrega i dispositivi di capacità locali o direct-attached degli host ESX del cluster in un unico pool condiviso; sui cluster nuovi si va di norma sulla vSAN Express Storage Architecture (ESA), su NVMe TLC.

Ciò che VVF non ha pesa quanto ciò che ha: la documentazione dice che non include le capacità di cloud management e automazione integrata di VMware Cloud Foundation. Niente NSX, niente VCF Automation, nessun SDDC Manager che governa workload domain. Il networking è quello di vSphere: standard e distributed switch, port group, VMkernel, teaming, VLAN. Corollario che finisce spesso in domanda: i vSphere Pod sono supportati solo su Supervisor configurati con NSX come networking stack, quindi su VVF i container girano nei cluster VKS.

Il VCF Installer e la preparazione dell’ambiente

Il punto d’ingresso è il VCF Installer, la VM dedicata da cui si pianificano, configurano e deployano tutti i componenti di VCF e vSphere Foundation. Arriva nello stesso OVA di SDDC Manager (VCF-SDDC-Manager-Appliance-9.x.x.<build>.ova), si deploya a mano su un host ESX dal VMware Host Client con Deploy a virtual machine from an OVF or OVA file — FQDN, IP, DNS, NTP, password di root e admin@local — e poi si usa dal browser su https://installer_appliance_FQDN. Attenzione: se finisce dentro l’infrastruttura di management passa in modalità SDDC Manager e non è più utilizzabile in modalità installer.

Servono poi i binari: con accesso a Internet, un online depot e un download token generato dal Broadcom Support Portal; altrimenti un offline depot già popolato, o il VCF Download Tool. Per vSphere Foundation bastano quelli di Cloud Foundation Operations e vCenter.

Gli host il wizard non li sistema: ESX si installa su tutti, rete e accesso amministrativo si configurano dalla DCUI, il port group VM Network si crea host per host dal VMware Host Client, si attiva NTP e, fissati gli hostname, si rigenerano i certificati self-signed. Gli host stateless non sono supportati; il numero minimo dipende da storage e modello di deployment e si legge nel Planning and Preparation Workbook.

Il wizard, pagina per pagina

Da Deployment Wizard → VMware vSphere Foundation si compilano in sequenza General Configuration (password generate automaticamente, adesione al CEIP), VCF Operations, vCenter, lo storage, che fissa lo shared storage iniziale del cluster primario, i dettagli degli host ESX, che devono condividere la stessa password a meno di usare la specifica JSON, la rete con gateway, VLAN, MTU e gli IP inclusion range per vSAN e vMotion, e il vSphere Distributed Switch Profile: Default, Storage Traffic Separation, NSX Traffic Separation, Storage and NSX Traffic Separation o Custom Switch Configuration. Chiudono Review e Validate & Deploy: la validazione restituisce errori e warning da leggere prima del Deploy; l’avanzamento si segue dal pannello Tasks.

Converge: quando vSphere gira già

Se vCenter e host sono in produzione non si ricostruisce nulla. Alla pagina Existing Components si seleziona VMware vCenter, si compilano General information, VCF Operations e vCenter con i dati dell’istanza esistente, poi Review e Validate & Deploy: vengono deployati i componenti VCF Operations che completano la piattaforma, mentre vCenter e host restano dov’erano. Contano le versioni: VVF 9.0.0 richiede vCenter 9.0 ed ESX 9.0, mentre 9.0.1 e 9.0.2 accettano vCenter 8.0 Update 3 ed ESX 8.0 Update 1. A valle si registra vCenter in VCF Operations e si licenzia.

Dopo il Deploy: licenza, log, Supervisor

Il primo passo è il deployment di VCF Operations; subito dopo, la licenza. Dalla 9.0 si licenzia proprio tramite un’istanza VCF Operations: i file a sottoscrizione sostituiscono le chiavi a 25 caratteri, si aggiungono dalla VCF Business Services console (vcf.broadcom.com) e si assegnano ai vCenter; vanno aggiornati almeno ogni 180 giorni, o gli host vengono disconnessi e le operazioni sui workload bloccate. Seguono backup, certificate e password management.

VCF Operations for Logs, su VVF, si deploya a mano con Deploy OVF Template dal vSphere Client, avviando un deployment nuovo o un join a un nodo esistente; l’aggancio alla UI passa dal tile Operations-Logs Appliance Integration. vSphere Supervisor si attiva per ultimo: con Foundation Load Balancer e networking VDS servono 3 host ESX per cluster senza vSAN (4 con vSAN e almeno 2 NIC fisiche), da 1 a 3 control plane VM, DRS in Fully Automated e HA attivi, e MTU 1600 o superiore sui distributed port group.

Trappole tipiche d’esame

  • VVF non è VCF. Ogni risposta che nomina NSX, VCF Automation, SDDC Manager o i workload domain descrive VCF: il perimetro VVF è vSphere + vSAN + VCF Operations + VCF Operations for Logs.
  • vSphere Pod contro cluster VKS. I Pod richiedono un Supervisor con NSX: su VVF, con networking VDS, i container girano nei cluster VKS.
  • Il VCF Installer non è SDDC Manager, ma è lo stesso OVA. Se l’appliance finisce dentro l’infrastruttura di management, la modalità installer è persa.
  • Deploy nuovo contro converge. Se lo scenario cita vCenter e host già in produzione la risposta è Existing Components, non una reinstallazione; e vanno verificate le versioni minime della release.
  • Licenza e log non sono automatici. La licenza si assegna da VCF Operations subito dopo il deployment, con rinnovo entro 180 giorni; VCF Operations for Logs si deploya manualmente da OVA, non dal wizard.