Su AZ-802 Hyper-V non si studia più come «creazione di una VM»: quella parte era di AZ-800 e qui è data per acquisita. Il dominio Manage virtual machines chiede la macchina che è già in produzione: come la si fotografa senza corrompere un database, che disco le si dà, a quale rete la si attacca e con quali tag, come resta in piedi quando cade il nodo e come la si replica in un altro sito. Sono tutte domande di configurazione, non di concetto: l’esame chiede quale opzione spuntare e quale parametro passare.

Checkpoint: la parola chiave è «coerenza applicativa»

Hyper-V ha due tipi di checkpoint. Lo standard checkpoint cattura anche lo stato della memoria e dei dispositivi: quando lo applichi ritrovi la VM esattamente com’era, applicazioni aperte comprese, ma il contenuto non è coerente dal punto di vista applicativo e su sistemi che replicano dati fra nodi (Active Directory, database) può creare inconsistenze. Il production checkpoint usa il Volume Shadow Copy Service dentro il guest Windows — o il File System Freeze su Linux — e produce un’immagine coerente dei dati; non salva la memoria, e infatti dopo averlo applicato la VM risulta spenta e va riavviata. Il production checkpoint è il default.

La sfumatura che l’esame sfrutta è il terzo valore del parametro:

Set-VM -CheckpointType Comportamento
Standard Crea sempre e solo checkpoint standard
Production Prova il production checkpoint; se fallisce ripiega su uno standard
ProductionOnly Prova il production checkpoint; se fallisce l’operazione fallisce, senza ripieghi

Se la policy dice «ogni checkpoint dev’essere application consistent, e in caso contrario deve fallire in modo visibile», l’unica risposta è ProductionOnly: Production soddisfa la prima metà della frase e tradisce la seconda.

I cmdlet da riconoscere sono Checkpoint-VM, Get-VMCheckpoint, Restore-VMCheckpoint (applicare), Remove-VMCheckpoint (eliminare), Rename-VMCheckpoint e Export-VMCheckpoint. Il modulo Hyper-V ha alias storici, quindi checkpoint e snapshot compaiono indifferentemente. Dietro le quinte ogni checkpoint è un file .avhdx nella stessa cartella del .vhdx: eliminando il checkpoint Hyper-V fonde i due file, e i .avhdx non vanno mai cancellati a mano. La posizione dei file di checkpoint si può cambiare solo finché la VM non ne ha nessuno.

Dischi virtuali: formato, tipo, catena

VHD arriva a 2 TB; VHDX arriva a 64 TB e aggiunge protezione dalla corruzione, ridimensionamento online, settori logici da 4 KB. Sul tipo: fixed alloca subito, dynamic cresce, differencing scrive le modifiche lasciando intatto un disco padre (è lo stesso meccanismo della catena di checkpoint). I pass-through disk bypassano il livello VHD e attaccano il disco fisico alla VM; i shared drive permettono a più VM di Generation 2 di accedere allo stesso disco, ed è così che si costruisce un guest cluster. La Storage QoS impone IOPS minimi e massimi per disco.

I cmdlet: New-VHD, Convert-VHD (VHD↔VHDX, fixed↔dynamic), Resize-VHD, Optimize-VHD, Merge-VHD, Add-VMHardDiskDrive. Ricorda che l’espansione online vuole il disco su un controller SCSI, e che la riduzione richiede spazio libero in coda al disco.

Switch virtuale e adattatore di rete

Lo Hyper-V Virtual Switch è uno switch Ethernet di livello 2 in software, in tre tipi: external (verso la rete fisica), internal (VM più sistema operativo di gestione), private (solo VM sullo stesso host). Si crea con New-VMSwitch e si collega un adattatore con Connect-VMNetworkAdapter. Le funzioni che l’esame nomina sono le protezioni e i controlli di porta: protezione da ARP/ND spoofing, DHCP guard, router guard, port ACL, port mirroring, limiti di banda minimi e massimi, trunk verso una VM e PVLAN isolate. Sul lato adattatore i parametri corrispondenti stanno tutti su Set-VMNetworkAdapter: -MacAddressSpoofing, -DhcpGuard, -RouterGuard, -PortMirroring Source|Destination, -MinimumBandwidthWeight, -MaximumBandwidth, -VmqWeight, -IovWeight, -DeviceNaming (solo Gen 2).

Il VLAN tagging è un cmdlet a parte, Set-VMNetworkAdapterVlan, e i modi sono mutuamente esclusivi:

Modo Sintassi Quando
Untagged -Untagged Nessun tag
Access -Access -VlanId 121 La VM vive in una sola VLAN
Trunk -Trunk -AllowedVlanIdList 10,20,30 -NativeVlanId 99 Appliance o firewall virtuale che ispeziona più VLAN
Isolated / Community -Isolated/-Community -PrimaryVlanId 10 -SecondaryVlanId 200 PVLAN, segregazione fra tenant
Promiscuous -Promiscuous -PrimaryVlanId 10 -SecondaryVlanIdList 200-201 La porta che parla con tutte le secondarie

In trunk mode il traffico taggato con uno degli ID consentiti arriva taggato all’adattatore virtuale, mentre il traffico non taggato viene trattato come appartenente alla NativeVlanId. Lo stesso cmdlet con -ManagementOS configura la VLAN dell’adattatore dell’host.

Teaming: SET sull’host, AllowTeaming nella VM

Sono due cose diverse e l’esame le mescola apposta.

Sull’host, la tecnologia corrente è Switch Embedded Teaming (SET): il team vive dentro lo switch virtuale e si crea passando più schede a New-VMSwitch (-NetAdapterName NIC1,NIC2 -EnableEmbeddedTeaming $true). SET accetta fino a otto schede, che devono essere simmetriche (stesso produttore, modello, velocità, configurazione), supporta solo la modalità switch-independent con bilanciamento Dynamic o Hyper-V Port, e non prevede LACP né static teaming. Soprattutto: SET è l’unica tecnologia che consente il teaming di schede RDMA e quindi il traffico SMB Direct insieme a quello delle VM; LBFO non è supportato in questi scenari. L’RDMA si abilita poi sugli adattatori virtuali dell’host (Add-VMNetworkAdapter -ManagementOS, Enable-NetAdapterRdma), scegliendo fra iWARP (su TCP, PFC/ETS facoltativi) e RoCE (su UDP, che pretende DCB con PFC ed ETS su host e switch fisici); due schede parlano RDMA solo se usano lo stesso protocollo. Su Azure Local — il nuovo nome di Azure Stack HCI — questa configurazione la fa Network ATC e il New-VMSwitch manuale è sconsigliato.

Dentro la VM, invece, il teaming resta quello del guest: si creano due adattatori virtuali (idealmente su due switch diversi) e si abilita Set-VMNetworkAdapter -AllowTeaming On, altrimenti lo switch scarta il traffico del team.

Alta disponibilità delle VM

La VM diventa altamente disponibile quando è un ruolo clusterizzato di un failover cluster i cui file stanno su storage condiviso da tutti i nodi, tipicamente un Cluster Shared Volume. La live migration sposta una VM accesa fra nodi senza downtime, ma è mobilità, non alta disponibilità: il riavvio automatico su un altro nodo lo dà il cluster. Il protected network e il VM monitoring aggiungono reazione ai guasti di rete e ai servizi in errore dentro il guest; Set-VMNetworkAdapter -NotMonitoredInCluster $true esclude un adattatore dal monitoraggio (utile per le reti di backup). Per applicazioni che vogliono un cluster dentro le VM si usano i dischi condivisi fra VM di Generation 2.

Hyper-V Replica

Hyper-V Replica è replica asincrona fra host, verso un altro sito: frequenza a 30 secondi, 5 minuti o 15 minuti, punti di ripristino multipli, snapshot VSS application-consistent opzionali, compressione, esclusione di singoli dischi dalla replica, replica estesa verso un terzo sito. È disaster recovery, non alta disponibilità: il failover è un’azione, non un automatismo.

Quando la destinazione è un cluster, prima di replicare si abilita sul cluster ricevente il ruolo Hyper-V Replica Broker, che è un client access point (nome NetBIOS di massimo 15 caratteri, unico nel dominio, con IP statico o DHCP) e offre al primario un unico punto di contatto anche quando la VM replica si sposta fra i nodi. L’autenticazione è Kerberos su HTTP 80 se i domini sono lo stesso o si fidano; se le foreste non si fidano — o se serve cifratura — è obbligatoria quella basata su certificato, HTTPS 443. Il certificato deve essere valido, non scaduto, con EKU Client e Server Authentication e chiave privata, e con CN o SAN che corrispondono all’FQDN del ruolo Replica Broker del cluster ricevente; per poter fare failback serve un certificato anche sugli host primari, sull’FQDN del Broker primario. Le regole del firewall esistono ma non sono abilitate: vanno accese Hyper-V Replica HTTP Listener (TCP-In) oppure Hyper-V Replica HTTPS Listener (TCP-In) su tutti gli host riceventi. Poi si sceglie fra «allow replication from any authenticated server» e le authorization entry per singolo server primario (FQDN, percorso di storage su CSV, trust group), e si collauda con Test-VMReplicationConnection.

Trappole tipiche d’esame

  • Production non è ProductionOnly. Se lo scenario dice «deve fallire invece di ripiegare», la risposta è ProductionOnly: Production crea silenziosamente un checkpoint standard quando VSS non risponde.
  • Un checkpoint non è un backup e non «congela» un disco: crea una catena di .avhdx che cresce. Chi cancella un .avhdx a mano perde dati; l’unico modo pulito è Remove-VMCheckpoint, che fonde.
  • Access vs Trunk. Un’appliance con un solo adattatore che deve ispezionare VLAN 10, 20 e 30 vuole -Trunk -AllowedVlanIdList con -NativeVlanId per l’untagged; aggiungere tre adattatori in access mode è la distrazione classica, e -Access accetta un solo -VlanId.
  • Teaming di schede RDMA = SET, non LBFO. Se il team deve portare SMB Direct e traffico VM, la risposta contiene «Switch Embedded Teaming» e «switch-independent con Dynamic o Hyper-V Port»; qualunque opzione che parli di LACP, static teaming o schede di modello diverso è sbagliata.
  • Il teaming nella VM non si eredita dall’host. Senza -AllowTeaming On sull’adattatore virtuale, il team configurato dentro il guest non funziona.
  • Nel Replica fra cluster il certificato segue il Broker, non i nodi. CN/SAN devono corrispondere all’FQDN del Hyper-V Replica Broker del cluster ricevente; e se le foreste non si fidano, Kerberos su porta 80 non è un’opzione — è HTTPS 443 con la regola firewall corrispondente da abilitare a mano.
  • Live migration, cluster e Replica rispondono a domande diverse: mobilità senza downtime, riavvio automatico dopo un guasto del nodo, copia in un altro sito da attivare manualmente. Uno scenario che chiede continuità dopo la perdita di un nodo non si risolve con Hyper-V Replica.