La virtualizzazione, prima di essere un prodotto, è un contratto doppio: l’hypervisor promette al sistema operativo ospite che sotto di lui c’è un computer vero, e promette all’amministratore che quel computer è, in fondo, un insieme di file. Quasi tutto ciò che l’esame chiede su questo obiettivo discende da tre proprietà — astrazione, incapsulamento, indipendenza dall’hardware — più una quarta che è il rovescio della prima: isolamento e condivisione sono lo stesso meccanismo visto da due lati. Conviene impararle con i nomi che usa la documentazione di vSphere 9.0, perché l’esame usa quelli.

L’astrazione: che cosa sostituisce davvero l’hypervisor

La definizione ufficiale è volutamente piatta: una macchina virtuale è «a software computer that, like a physical computer, runs an operating system and applications», e ogni VM contiene il proprio hardware software-based — CPU virtuale, memoria, disco, scheda di rete. ESX è l’hypervisor: aggrega e normalizza l’hardware dell’host in un insieme standard di risorse, così che la VM veda sempre la stessa piattaforma indipendentemente dal server sotto. vCenter sta un piano sopra e mette in pool le risorse di più host.

L’astrazione, però, non è gratis né uniforme. Sulla CPU la documentazione distingue due regimi: nella virtualizzazione software il codice applicativo dell’ospite gira direttamente sul processore mentre il codice privilegiato viene tradotto, e «the translated code is slightly larger and usually runs more slowly than the native version»; con l’assistenza hardware del processore la traduzione non serve e i carichi intensivi di system call girano molto vicino alla velocità nativa. In overcommitment l’hypervisor affetta il tempo dei processori fisici fra le VM, e per default le quote (shares) sono uguali per vCPU: una VM a due vCPU riceve di default il doppio di una a una vCPU. Da qui il consiglio esplicito della doc: le applicazioni single-thread vanno su VM uniprocessore, non su VM SMP.

Sulla memoria i livelli di indirizzamento diventano tre invece di due. Il VMM mantiene sia la mappa guest virtual → guest physical (gestita dal guest OS) sia quella guest physical → machine memory, le pagine reali dell’host; le shadow page table collassano la catena in una mappa diretta, mentre le CPU moderne offrono page table a due livelli che spostano il lavoro nel silicio al prezzo di TLB miss più costosi — mitigati usando large page. La memoria è in overcommitment quando «the combined working memory footprint of all virtual machines exceed that of the ESX host memory sizes», e ESX se la cava con ballooning, compressione e swap. Nota che sfugge spesso: l’overhead di virtualizzazione di ogni VM è anch’esso considerato riservato.

L’incapsulamento: una VM è una directory sul datastore

Aprendo Storage → datastore → Files nel vSphere Client si vede la seconda promessa mantenuta. Il .vmx è il file di configurazione; il .vmdk descrive le caratteristiche del disco virtuale mentre -flat.vmdk contiene i dati; il .nvram conserva la configurazione BIOS o EFI; il .vswp è il file di swap della VM; .vmsd tiene i metadati degli snapshot e .vmsn lo stato di memoria di uno snapshot; .vmss è il file di sospensione; vmware.log e vmware-#.log i log. Convertendo la VM in template, il .vmx diventa .vmtx.

Questo è il motivo per cui clonazione, template, OVF, Content Library, snapshot e backup esistono come operazioni banali: manipolano file. Ed è anche il motivo per cui lo snapshot non è un backup — è un file delta che vive accanto all’originale e cresce.

L’indipendenza dall’hardware e i suoi due confini reali

La doc afferma che una VM può essere spostata da un host fisico a un altro, o i suoi dischi da un tipo di storage a un altro, «without affecting the functioning of the virtual machine». In pratica l’indipendenza ha due confini che l’esame adora.

Il primo è la compatibilità della VM, cioè la hardware version: seleziona le versioni di ESX su cui la VM può girare e determina BIOS/EFI, slot PCI virtuali, numero massimo di CPU e configurazione massima di memoria. «ESX 9.0 and later» corrisponde alla hardware version 22; ogni livello di compatibilità copre almeno cinque release maggiori o minori di vSphere. Alzarla apre le feature nuove e chiude la strada agli host vecchi: non è reversibile con un clic.

Il secondo è il set di istruzioni della CPU fisica. vMotion esegue controlli di compatibilità proprio perché l’ospite, una volta avviato, ha già visto le feature del processore; EVC, che si attiva sulla pagina Configure del cluster, esiste per presentare a tutti gli host un set di feature comune e rendere possibile la migrazione a caldo fra generazioni diverse.

Isolamento, condivisione e il perimetro di VVF

Isolamento e condivisione sono la stessa astrazione: le VM condividono CPU, memoria, storage e rete di host che non conoscono, e proprio per questo restano separate. L’isolamento però non solleva nessuno dai doveri di un server fisico — il guest OS va installato, aggiornato e messo in sicurezza dall’amministratore esattamente come su hardware, e VMware Tools è la suite che migliora prestazioni e gestibilità dell’ospite, non un sostituto della manutenzione.

Un’ultima messa a fuoco sul perimetro dell’esame. vSphere Foundation è vSphere (vCenter Standard, ESX, vSphere Supervisor), vSAN, VCF Operations e VCF Operations for Logs: «vSphere Foundation does not include the cloud management and integrated automation capabilities that are available in VMware Cloud Foundation». Niente NSX, quindi il networking è quello di vSphere — standard switch, distributed switch, port group, VMkernel, VLAN, teaming.

Trappole tipiche d’esame

  • VVF non è VCF. Se una risposta nomina NSX, VCF Automation o i workload domain, su vSphere Foundation è fuori perimetro. È la confusione che l’esame sfrutta più spesso.
  • vSphere Pod contro cluster VKS. I vSphere Pod sono supportati solo su Supervisor configurati con NSX come networking stack: su VVF, con networking VDS, i container si eseguono nei cluster VKS. La domanda arriva travestita da «dove gira questo container?».
  • Hardware version ≠ versione di ESX ≠ versione di VMware Tools. Sono tre livelli indipendenti; la compatibilità determina le feature virtuali disponibili e gli host su cui la VM può accendersi, non la patch dell’ospite.
  • Overcommitment non è overhead. L’overcommitment è la somma dei footprint attivi che supera la memoria dell’host; l’overhead è il costo per-VM della virtualizzazione, che va contato come riservato.
  • Shares per vCPU, non per VM. Con le impostazioni di default la VM con più vCPU riceve più tempo di CPU: è una conseguenza aritmetica dello scheduler, non una priorità che qualcuno ha impostato.