Il perimetro di questo obiettivo è più stretto di quanto sembri, ed è lì che l’esame lavora. I componenti compute di VMware vSphere Foundation sono ESX e vCenter; intorno a loro VVF porta VCF Operations, il VCF Operations collector e VCF Operations for Logs. Non porta SDDC Manager, non porta NSX Manager né NSX Edge, non porta VCF Automation, VCF Operations for Networks, Identity Broker o HCX: quelle appliance appartengono a VMware Cloud Foundation. La documentazione lo dice anche in negativo: vSphere Foundation «non include le capacità di cloud management e di automazione integrata» disponibili in VCF. Il networking, di conseguenza, è quello nativo di vSphere — standard switch, distributed switch, port group, VMkernel, teaming, VLAN — e nient’altro.

Preparare gli host ESX prima di aprire qualunque wizard

Il deployment non parte da un’interfaccia grafica: parte da host ESX già installati e raggiungibili. ESX si installa in tre modi — interattivo da supporto fisico o boot di rete, scripted con un file di configurazione, oppure con vSphere Auto Deploy, che è un servizio installato insieme a vCenter. Attenzione al terzo: in ESX 9.0 il boot di rete con immagini in memoria o in cache che non preservano alcuno stato è deprecato, e la documentazione VCF è esplicita nel dire che gli host ESX stateless non sono supportati sulla piattaforma.

La configurazione di rete si fa dalla DCUI: console dell’host, F2, login con la password di root, poi Configure Management Network. Da lì si imposta la VLAN (Optional) con l’ID della ESX Management Network; IPv4 Configuration → Set static IPv4 address and network configuration con indirizzo, subnet mask e default gateway; DNS Configuration → Use the following DNS Server address and hostname con DNS primario, secondario e hostname in FQDN; infine Custom DNS Suffixes, che va lasciato vuoto. Si esce con Esc e si conferma con Y. Il Virtual Machine Network port group si configura invece dal VMware Host Client, host per host.

Restano due passi che nessuno ricorda e che rompono tutto dopo: configurare il servizio NTP su ogni host, e rigenerare i certificati self-signed dopo aver impostato l’hostname (o installare certificati firmati esternamente, se la policy lo impone). Sulla sincronizzazione oraria vale la pena essere brutali: certificati SSL e token SAML sono sensibili al tempo, e con gli orologi alla deriva l’autenticazione fallisce, l’installazione di vCenter fallisce e il servizio vmware-vpxd può non partire. NTP e PTP, inoltre, non possono girare contemporaneamente sullo stesso host.

Il VCF Installer e il deployment wizard

Il deploy di VVF 9.0 si fa con la VCF Installer appliance, distribuita nell’OVA VCF-SDDC-Manager-Appliance-9.x.x.<build>.ova scaricato dal Broadcom Support Portal. La si deploya con il VMware Host Client su un host ESX già preparato, compilando port group, FQDN, indirizzo IP, subnet mask, default gateway, DNS domain name, fino a due DNS server, uno o più NTP server e le password di root e dell’utente locale (minimo 15 caratteri, con maiuscole, minuscole, cifra e carattere speciale). Poi si punta il browser su https://<fqdn_installer> e si entra come admin@local.

Prima del wizard bisogna scaricare i binari sull’appliance. Poi: Deployment Wizard → VMware vSphere Foundation, e si compilano nell’ordine General Configuration (password e CEIP), VCF Operations, vCenter, Storage, ESX Host Details, Networks, il profilo di vSphere Distributed Switch, Review, Validate & Deploy. Due dettagli operativi: tutti gli host ESX devono condividere la stessa password, a meno di usare un file di specifica JSON; e a fine deployment il pulsante Review Passwords mostra le credenziali generate, mentre il JSON di specifica si può scaricare per riusarlo.

La pagina Networks chiede la ESX Management Network e la VM Management Network, gli IP inclusion range per vSAN e vMotion, VLAN e MTU. Il profilo di distributed switch determina quanti vDS nascono e come si separa il traffico: il modello a switch singolo mette management, vMotion, vSAN e workload sullo stesso vDS; i modelli di separazione dello storage ne creano due, dedicandone uno al traffico vSAN su NIC fisiche distinte; esiste anche un profilo Custom. Su VVF i profili costruiti attorno alla separazione del traffico NSX non hanno un uso reale, perché NSX non c’è.

vCenter: il wizard non è l’unico percorso

Il wizard deploya vCenter per te, ma devi conoscere anche l’installer GUI a due stage, perché è quello che userai in convergenza o in ripristino. Stage 1 deploya l’OVA sull’host ESX di destinazione; Stage 2 configura sincronizzazione oraria e vCenter Single Sign-On e avvia i servizi. In alternativa si deploya l’OVA a mano dal vSphere Client e si completa lo stage 2 dalla vCenter Management Interface su https://<fqdn>:5480. Prerequisiti da sapere a memoria: record DNS forward e reverse configurati per l’indirizzo statico, NTP attivi e sincronizzati con il server di destinazione, e host ESX target non in lockdown mode né in maintenance mode (se il target è un cluster DRS, almeno un host deve essere in quello stato).

Convergere un’infrastruttura vSphere esistente

Se il cliente ha già vSphere, non si ricostruisce: si converge. Il wizard, alla pagina Existing Components, accetta un vCenter esistente, e da quel momento le pagine Storage, Hosts, Networks e Distributed Switch spariscono — quella configurazione resta la tua. I prerequisiti di versione sono asimmetrici e vengono chiesti: per VVF 9.0.0 servono vCenter 9.0+ ed ESX 9.0+; per VVF 9.0.1–9.0.2 bastano vCenter 8.0 Update 3+ ed ESX 8.0 Update 1+. Vincolo bloccante: il vCenter esistente non deve avere un NSX Manager connesso. Quello che viene deployato ex novo sono VCF Operations, VCF Operations for Logs e VCF Operations Orchestrator.

Dopo il deploy: licenze e messa in sicurezza

Le licenze non si assegnano più host per host dal vSphere Client: si va in VCF Operations → License Management → Licenses, scheda Version 9+, e si usa Assign Primary License selezionando l’istanza o le istanze di vCenter. Gli altri asset connessi a quel vCenter, host ESX compresi, vengono licenziati automaticamente. Il modello è a capacità per core: non puoi assegnare una licenza se l’istanza richiede più capacità di quella disponibile. Un host in evaluation mode viene aggiunto al vCenter anche se la capacità non basta, ma superati i 90 giorni di evaluation non lo aggiungi più finché non aumenti la capacità. Chiudono la sequenza backup delle management component, gestione dei certificati e delle password, e solo dopo l’eventuale abilitazione di vSphere Supervisor.

Trappole tipiche d’esame

  • L’OVA si chiama VCF-SDDC-Manager-Appliance, ma su VVF SDDC Manager non lo ottieni. Lo stesso binario serve due piattaforme; il nome del file non è l’elenco di ciò che verrà installato. Su VVF nascono vCenter, ESX, VCF Operations, il collector e VCF Operations for Logs — punto.
  • Appliance VCF-only spacciate per VVF. NSX Manager, NSX Edge, VCF Automation, VCF Operations for Networks, VCF Identity Broker, VCF Operations HCX e SDDC Manager sono di VMware Cloud Foundation. Una risposta che li nomina in uno scenario VVF è sbagliata anche se il resto della frase è corretto.
  • Auto Deploy «stateless» presentato come scelta valida. Il boot senza stato è deprecato in ESX 9.0 e VCF/VVF non supporta host ESX stateless: in uno scenario di deployment la risposta corretta è l’installazione interattiva, quella scripted o Auto Deploy con stato persistente.
  • Licenza assegnata all’host invece che al vCenter. Il flusso 9.0 passa da VCF Operations e propaga la licenza agli host; ricordati anche che l’evaluation di 90 giorni non blocca l’aggiunta di un host, ma la sua scadenza sì.
  • Container su VVF. I vSphere Pod richiedono NSX come networking stack, quindi su vSphere Foundation i workload containerizzati girano nei cluster VKS gestiti dal vSphere Supervisor. Una domanda che offre i vSphere Pod come risposta in un ambiente VVF sta misurando proprio questo.