Su VMware vSphere Foundation il networking è quello di vSphere e basta: standard switch, distributed switch, port group, adattatori VMkernel, teaming, VLAN. Non c’è NSX e non c’è VCF Automation — la documentazione dice esplicitamente che vSphere Foundation non include le capacità di cloud management e di automazione integrata disponibili in VMware Cloud Foundation. Tutto quello che segue si fa dal vSphere Client, e la domanda d’esame vera, sotto mille travestimenti, è sempre la stessa: standard o distribuito?

Due switch, due modelli di gestione

Il vSphere Standard Switch (VSS) vive dentro un singolo host ESX: esiste lì, si configura lì, e se hai dodici host hai dodici configurazioni da tenere allineate a mano. Il vSphere Distributed Switch (VDS) è invece un oggetto di vCenter Server, definito a livello di data center: la configurazione si scrive una volta sola e vCenter la propaga a tutti gli host associati, con provisioning, amministrazione e monitoraggio centralizzati.

Su ogni host il VDS si materializza come host proxy switch, la rappresentazione locale dello switch distribuito. È una distinzione che conta nella pratica quotidiana: le policy dei distributed port group e le impostazioni generali dello switch sono centrali, mentre l’associazione fra le schede fisiche dell’host e le uplink port del proxy switch, e la migrazione degli adattatori VMkernel da e verso lo switch distribuito, restano operazioni che si fanno host per host.

I percorsi reali

Standard switch. Selezioni l’host, tab Configure, espandi Networking, voce Virtual switches, poi Add networking. Il wizard chiede il connection type — VMkernel Network Adapter, Physical Network Adapter, Virtual Machine Port Group for a Standard Switch — poi New standard switch, poi le schede fisiche da assegnare (almeno due, per ridondanza), poi i parametri: VLAN ID, IPv4/IPv6, MTU, TCP/IP stack.

Distribuito. Tasto destro su un data center — non su un host, non su un cluster — poi Distributed Switch → New Distributed Switch. Il wizard chiede nome e posizione; la versione (Distributed Switch 9.0.0, che richiede ESX 9.0.0 o superiore, e a scendere 8.0.3, 8.0.0, 7.0.x); e nella pagina Configure settings il numero di uplink, l’abilitazione di Network I/O Control e la casella Create a default port group con il nome del port group. Nella 9.0 compaiono anche l’abilitazione Industrial vSwitch e la Network Offloads Compatibility (None, Pensando, NVIDIA BlueField), con la conseguente pagina di DPU Failover Configuration.

Dove si impostano le policy

Teaming e failover, sicurezza e traffic shaping esistono su entrambi gli switch, ma non alla stessa granularità. Sul VSS le policy si applicano a livello di switch virtuale o di port group. Sul VDS a livello di distributed port group o di singola porta: è questa la leva che permette di trattare diversamente due macchine virtuali attestate allo stesso port group, e in un VDS con centinaia di VM è esattamente il motivo per cui lo si sceglie.

Il resto delle regole vale ovunque. Il rilevamento del guasto è Link Status Only oppure Beacon Probing, che per non restare ambiguo vuole tre o più schede nel team. Notify Switches avvisa lo switch fisico quando una NIC entra in servizio o il traffico viene reinstradato. Failback è attivo per impostazione predefinita e rimette in servizio la scheda guarita, al prezzo di cambi di MAC frequenti sullo switch fisico. Il vincolo fisico non si aggira: tutte le porte dello switch fisico appartenenti a un team devono stare nello stesso dominio di broadcast di livello 2.

La security policy è di livello 2 e ha tre voci, sempre le stesse: promiscuous mode, MAC address changes, forged transmits.

Il traffic shaping è il punto in cui la differenza è netta e va sapula a memoria: ESX modella il traffico in uscita sugli standard switch, mentre i distribuiti supportano sia ingresso sia uscita. I parametri sono tre — average bandwidth e peak bandwidth in bit al secondo, burst size in byte — e il burst bonus accumulato quando la porta non consuma tutta la banda le consente di trasmettere temporaneamente più veloce.

VLAN: EST, VST, VGT

Tre modi, e l’esame li chiede per numero.

  • EST: tagga lo switch fisico, VLAN ID 0 sul port group, schede su porte access.
  • VST: tagga il virtual switch prima che il pacchetto lasci l’host, VLAN ID da 1 a 4094, schede su porte trunk. È il modo normale.
  • VGT: tagga la macchina virtuale. VLAN ID 4095 sullo standard switch; sul distribuito si indica invece un intervallo di VLAN, e lo switch distribuito può restringere i pacchetti a VLAN specifiche. Serve un driver di trunking 802.1Q nel sistema operativo guest.

I private VLAN sono un gradino oltre: segmentano il dominio di broadcast logico in sottodomini più piccoli, con la primaria marcata promiscuous e le secondarie isolated (parlano solo con le porte promiscuous) o community (parlano anche fra loro). Richiedono il VDS e uno switch fisico PVLAN-capable, con gli ID già inseriti nel suo database VLAN.

VMkernel e stack TCP/IP

Gli adattatori VMkernel portano il traffico dell’infrastruttura: management, vMotion, provisioning, IP storage (iSCSI e NFS), Fault Tolerance, vSphere Replication, vSAN, vSphere Backup NFC, NVMe over TCP e RDMA. La regola documentata è dedicare un adattatore VMkernel separato a ogni tipo di traffico. Gli stack sono quattro: default, vMotion, provisioning e custom. Attenzione al comportamento: una volta configurato lo stack vMotion, gli adattatori sullo stack default vengono disabilitati per vMotion.

Che cosa sa fare solo il distribuito

Network I/O Control esiste solo sul VDS. La versione 3 assegna banda con shares, reservation e limit, sia al traffico di sistema sia a quello delle macchine virtuali, riservando in base alla capacità delle schede fisiche dell’host; da sapere, SR-IOV non è disponibile per le VM configurate con NIOC v3. Sul distribuito vivono anche LACP, i private VLAN e lo shaping in ingresso.

Il Supervisor, e il vincolo che non ti aspetti

Su VVF il vSphere Supervisor si attiva con lo stack di rete vSphere, cioè VDS: tutti gli host dei cluster che lo sostengono devono essere connessi allo stesso VDS, le workload network sono distributed port group, la primary workload network serve le control plane VM, e un load balancer è obbligatorio — Foundation Load Balancer oppure Avi. Il corollario da portare in sala d’esame: i vSphere Pod sono supportati solo con Supervisor configurati con NSX come networking stack, quindi su vSphere Foundation i container girano nei cluster VKS.

Trappole tipiche d’esame

  • Dove si crea il VDS. Si crea con il tasto destro su un data center, non su un cluster e non su un host. Lo standard switch, al contrario, nasce dall’host: Configure → Networking → Virtual switches → Add networking. Gli scenari mescolano apposta i due punti di partenza.
  • Traffic shaping, direzione. Standard switch: solo in uscita. Distributed switch: ingresso e uscita. È la domanda secca più frequente su questo obiettivo, e la risposta sbagliata (“entrambi in entrambe le direzioni”) è la più appetitosa.
  • VGT e il 4095. Il valore 4095 vale sullo standard switch; sul distribuito si specifica un intervallo di VLAN. Chi memorizza “VGT = 4095 sempre” cade sullo scenario che parla di distributed port group.
  • Le feature solo-VDS. Se lo scenario dice standard switch, qualunque risposta che citi Network I/O Control, LACP o private VLAN è sbagliata per costruzione — non perché la feature non serva, ma perché quello switch non ce l’ha.
  • La tentazione NSX. Davanti a uno scenario di rete del Supervisor su VVF, le opzioni che parlano di overlay, tier-0/tier-1 o NSX Load Balancer sono distrattori: su VVF si risponde VDS con Foundation Load Balancer (o Avi), e i workload containerizzati sono VKS, non vSphere Pod.