Il dominio «Manage virtual machines» di AZ-802 non chiede più di creare una VM: dà per scontato che tu sappia farlo e ti mette davanti a una macchina che esiste già e si comporta male. Il pulsante della sessione avanzata è grigio, la VM è su uno switch privato e non la raggiungi, la memoria massima è troppo bassa e il database è in produzione, la GPU va divisa fra dieci desktop virtuali. Tutte le domande di questo modulo hanno la stessa forma: un sintomo, e la configurazione che lo spiega. Di seguito le sette configurazioni che l’esame mette alla prova.
Enhanced Session Mode: gli interruttori sono due, più uno
Enhanced Session Mode fa passare VMConnect da una console video grezza a una sessione RDP che viaggia dentro l’host, senza rete fra host e guest. Da lì arrivano appunti condivisi, redirezione di stampanti, audio, smart card, dischi locali (compreso C:) e dispositivi USB: sono esattamente le cose che in sessione base non funzionano.
Perché il pulsante sulla barra di VMConnect sia attivo servono tre condizioni contemporanee:
- Il guest è Windows. La documentazione è esplicita: la funzione esiste solo per le VM Windows. Per i guest Linux la strada è un’altra (SSH Direct, più sotto).
- Nel guest è acceso Remote Desktop. È la causa numero uno del pulsante grigio: la VM è perfetta, l’host è configurato, ma dentro il sistema operativo ospite «Abilita Desktop remoto» è spento. Su Windows 10 2004+ e Windows 11 c’è un secondo passo: disattivare «For improved security, only allow Windows Hello sign-in for Microsoft accounts on this device», altrimenti la finestra non mostra nemmeno il prompt di accesso.
- L’host lo consente. In Hyper-V Manager ci sono due caselle distinte: Server → Enhanced Session Mode Policy → Allow enhanced session mode (criterio del server) e User → Enhanced Session Mode → Use enhanced session mode (preferenza dell’utente che si connette). In PowerShell il criterio del server è
Set-VMHost -EnableEnhancedSessionMode $true.
Se le prime due condizioni non sono soddisfatte, agire sull’host non serve a niente: è proprio lo scenario che l’esame ti mette davanti.
Amministrare una VM che non ha rete
Quando il solo adattatore di una VM sta su uno switch privato, WinRM, RDP e OpenSSH sono irraggiungibili per definizione. Restano i canali che passano per VMBus.
| Canale | Per quale guest | Prerequisiti | Comandi |
|---|---|---|---|
| PowerShell Direct | Windows 10 / Windows Server 2016 e successivi | host Windows 10 / WS2016+, VM locale e accesa con almeno un profilo utente, essere loggati sull’host come Hyper-V administrator, credenziali valide del guest | Enter-PSSession -VMName "APP1", Invoke-Command -VMName "APP1" -ScriptBlock { … }, New-PSSession -VMName "APP1" -Credential (Get-Credential) |
| SSH Direct | guest Linux | sshd nel guest in ascolto sul socket Hyper-V; host che espone il canale |
connessione SSH instradata su Hyper-V Sockets anziché su TCP/IP |
| Copy-VMFile | Windows e Linux | integration service Guest Service Interface abilitato (è l’unico spento per impostazione predefinita) | Copy-VMFile -VMName "LAB1" -SourcePath … -DestinationPath … -FileSource Host -CreateFullPath |
Due dettagli che l’esame sfrutta. Primo: PowerShell Direct non accetta -RunAsAdministrator (funziona solo verso i container) e non ti regala l’accesso: le credenziali del guest vanno sempre fornite. Secondo: per copiare un file dall’host nel guest non serve PowerShell Direct con sessione persistente se il guest è irraggiungibile — serve Copy-VMFile, e serve prima Enable-VMIntegrationService -VMName "LAB1" -Name "Guest Service Interface".
Integration services: abilitato sull’host ≠ in esecuzione nel guest
Get-VMIntegrationService -VMName "LAB1" elenca sei voci: Guest Service Interface, Heartbeat, Key-Value Pair Exchange, Shutdown, Time Synchronization, VSS. Su un guest Windows sono tutte attive tranne Guest Service Interface, che è Enabled False.
La regola: ogni servizio deve essere abilitato sull’host e in esecuzione nel guest. Abilitarlo sull’host lo avvia automaticamente nel guest; se lo fermi nel guest mentre è abilitato sull’host, Hyper-V lo riavvia; se lo disabiliti nel guest, Hyper-V non riesce più ad avviarlo. Nel guest Windows i servizi si chiamano vmic* (Get-Service -Name vmic* | FT -AutoSize): vmicguestinterface, vmicrdv (quello che serve alla sessione avanzata), vmicvmsession (PowerShell Direct), vmicvss. Nei guest Linux non ci sono servizi Windows: il driver è hv_utils nel kernel e i daemon sono hv_kvp_daemon, hv_vss_daemon, hv_fcopy_daemon.
Memoria dinamica: cosa si cambia a macchina accesa
Dynamic Memory ha tre valori e due comportamenti runtime che l’esame chiede con precisione chirurgica.
| Impostazione | Significato | Limiti |
|---|---|---|
| Startup RAM | memoria all’avvio; è anche la sola memoria disponibile durante l’installazione o l’upgrade del sistema operativo guest | — |
| Minimum RAM | minimo assegnabile dopo l’avvio | da 32 MB fino al valore di Startup RAM |
| Maximum RAM | tetto assegnabile | da Startup RAM fino a 1 TB, comunque non oltre il massimo supportato dal guest |
| Memory buffer | percentuale di margine sopra il fabbisogno misurato | non garantito se l’host è sotto pressione |
| Memory weight | priorità nella contesa fra VM | — |
A macchina accesa Hyper-V consente due sole modifiche: aumentare il massimo e diminuire il minimo. Alzare il tetto di un database in produzione da 8 GB a 16 GB quindi non richiede alcun fermo — è il caso classico. Alzare Startup RAM, invece, richiede lo spegnimento.
Smart Paging copre il divario fra minimo e avvio, ma solo in uno scenario preciso: riavvio della VM, nessuna memoria fisica disponibile e nessuna recuperabile da altre VM. Non interviene all’accensione da stato spento, non interviene in caso di failover di cluster, e dura al massimo una decina di minuti prima che il ballooning restituisca la memoria.
Nested virtualization
Si attiva a VM spenta con Set-VMProcessor -VMName "LAB1" -ExposeVirtualizationExtensions $true: espone al guest le estensioni hardware (Intel VT-x, AMD-V) così che dentro possa girare un altro hypervisor. La conseguenza da ricordare non è l’attivazione ma il vincolo sulla memoria: quando Hyper-V gira dentro la VM, la memoria non si tocca a caldo — la VM va spenta, e l’eventuale memoria dinamica di fatto non fluttua. Attenzione alla sfumatura: è l’Hyper-V in esecuzione nel guest a creare l’incompatibilità, non il flag in sé. Uno scenario supportato in produzione è un solo livello di annidamento; Failover Clustering annidato e carichi sensibili alle prestazioni no.
Device assignment e GPU partitioning
Sono due risposte diverse alla stessa domanda «voglio hardware PCIe in una VM», e l’esame le contrappone.
| Discrete Device Assignment (DDA) | GPU partitioning (GPU-P) | |
|---|---|---|
| Cosa assegna | l’intero dispositivo PCIe a una sola VM | una frazione hardware di GPU, via SR-IOV, a più VM |
| Generazione VM | Gen 1 o Gen 2 | — |
| Classi supportate | schede grafiche e storage NVMe | elenco chiuso di GPU: NVIDIA A2/A10/A16/A40, L2/L4/L40/L40S, RTX Pro 6000 Blackwell Server Edition, AMD Radeon PRO V710 |
| Live migration | no | sì, da Windows Server 2025, con CPU capaci di IOMMU DMA bit tracking e driver NVIDIA vGPU Software v18.x o successivo |
| Altri vincoli | niente save/restore, niente memoria dinamica, niente aggiunta a cluster HA | configurazione omogenea (stessa marca, modello e numero di partizioni su tutti i server); una GPU o è DDA o è partizionabile, mai entrambe |
La sequenza DDA è fissa e va nell’ordine: Set-VM -Name "ANALYTICS1" -AutomaticStopAction TurnOff → disabilitare il dispositivo sull’host (Device Manager o Disable-PnpDevice) → Dismount-VMHostAssignableDevice -LocationPath $locationPath → Add-VMAssignableDevice -LocationPath $locationPath -VMName "ANALYTICS1". Il LocationPath è del tipo PCIROOT(20)#PCI(0300)#PCI(0000) e si legge nella scheda Details → Location Paths delle proprietà del dispositivo, oppure con lo script SurveyDDA.ps1. Per le GPU (non per gli NVMe) va allargato lo spazio MMIO, che di default è 128 MB basso e 512 MB alto: Set-VM -LowMemoryMappedIoSpace e -HighMemoryMappedIoSpace, sommando il fabbisogno di tutti i dispositivi più un margine pari ai valori predefiniti.
Trappole tipiche d’esame
- Il pulsante grigio non si ripara sull’host. Se Enhanced Session Mode risulta non disponibile per una singola VM Windows mentre l’host lo consente, la causa è nel guest: Desktop remoto spento (o
vmicrdvfermo). RieseguireSet-VMHost -EnableEnhancedSessionMode $truenon cambia nulla. - «Nessuna rete» non vuol dire «nessun accesso». Switch privato, WinRM e OpenSSH irraggiungibili: la risposta è PowerShell Direct (
Enter-PSSession -VMName), non aggiungere un adattatore o aprire una porta. E per un guest Linux nella stessa condizione la risposta è SSH Direct, non PowerShell Direct. - Copiare un file non è PowerShell Direct. Se la traccia mostra l’output di
Get-VMIntegrationServiceconGuest Service InterfaceaFalse, sta indicando la risposta: abilitarlo e usareCopy-VMFile. Enabled sull’host e servizio in esecuzione nel guest sono due condizioni distinte, e l’esame le separa apposta. - A caldo si alza il massimo e si abbassa il minimo, e basta. Portare Maximum RAM da 8192 a 16384 MB su una VM accesa è legittimo; alzare Startup RAM no. E Startup RAM è anche il tetto reale durante l’installazione del sistema operativo, per quanto generoso sia il massimo.
- Smart Paging non è il file di paging del guest. Interviene solo al riavvio, solo senza memoria fisica disponibile né recuperabile: non all’accensione da spento, non in oversubscription, non al failover di cluster.
- DDA e GPU-P non sono intercambiabili. «Ogni desktop virtuale riceve una frazione di GPU» esclude DDA in partenza, perché DDA assegna l’intera scheda a una VM sola. E se lo scenario aggiunge la migrazione a caldo su host Windows Server 2022, la risposta è aggiornare a Windows Server 2025: prima non esiste.
- Nested virtualization non blocca la memoria dinamica di per sé. È l’hypervisor in esecuzione dentro la VM a impedire il ridimensionamento a caldo della memoria; il flag
-ExposeVirtualizationExtensionsda solo non ha effetto su Dynamic Memory.