1 21/10/2026 9 min

Verificare prima il requisito, poi il modulo

Quando si parla di Hyper-V su Windows, la confusione nasce quasi sempre da un equivoco semplice: una cosa è il modulo PowerShell che espone i cmdlet di gestione, un’altra è la funzionalità di sistema che abilita l’host Hyper-V. Se devi capire quali funzionalità sono richieste, il punto di partenza non è il comando più comodo, ma la differenza tra ciò che è installato, ciò che è disponibile e ciò che è realmente attivo.

In pratica, il controllo va fatto su tre livelli: il ruolo/funzionalità di Windows, il modulo PowerShell e lo stato dei servizi correlati. Se uno di questi tre manca, i cmdlet possono esistere ma non funzionare come ti aspetti, oppure il sistema può risultare compatibile solo in parte.

Funzionalità Windows necessarie per Hyper-V

Su un host Windows Server o su un client Windows con supporto Hyper-V, la funzionalità principale è Hyper-V. In PowerShell la vedi come feature del sistema operativo, non come semplice modulo. Per verificarla puoi usare il modulo ServerManager su server oppure i cmdlet DISM / PowerShell lato client, a seconda della versione e del contesto operativo.

Su Windows Server, il controllo più diretto è questo:

Get-WindowsFeature -Name Hyper-V*

Il risultato atteso, su un host con Hyper-V installabile o già installato, mostra almeno la feature Hyper-V e i relativi componenti. Se la feature è presente ma non installata, la colonna dello stato lo indica chiaramente. Se invece la feature non compare, il problema è a monte: edizione del sistema, supporto hardware o contesto errato.

Su client Windows, il controllo equivalente passa spesso da Get-WindowsOptionalFeature o dalla verifica del supporto alla virtualizzazione. Un esempio utile:

Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All

Se il comando restituisce Enabled, la funzionalità è attiva. Se restituisce Disabled, puoi abilitarla senza reinventare la configurazione. Se compare un errore di nome feature non valido, stai probabilmente lavorando su un’edizione o una build che usa nomi diversi oppure non espone quella feature.

Modulo PowerShell: cosa serve davvero per gestire Hyper-V

Per amministrare Hyper-V con PowerShell, il modulo da cercare è Hyper-V. Non è un requisito opzionale: è il contenitore dei cmdlet come Get-VM, Start-VM, Stop-VM, Get-VMSwitch e simili. Se il modulo non è caricato o non è presente, puoi comunque avere Hyper-V installato, ma non avrai la gestione via cmdlet disponibile nel modo atteso.

Per vedere se il modulo esiste nel sistema:

Get-Module -ListAvailable Hyper-V

Se il modulo è disponibile, il comando restituisce il percorso del modulo e la versione. Se non restituisce nulla, vuol dire che il sistema non ha installato i componenti necessari per esporre i cmdlet Hyper-V o che la sessione non ha accesso al percorso corretto dei moduli.

Per caricarlo esplicitamente nella sessione:

Import-Module Hyper-V

Se il modulo si importa correttamente, puoi subito elencare i cmdlet e capire cosa è effettivamente a disposizione:

Get-Command -Module Hyper-V

Questo è il passaggio più utile quando vuoi “mostrare le funzionalità richieste”: non ti limiti a dire che Hyper-V esiste, ma elenchi i comandi presenti sul sistema e quindi la superficie operativa realmente disponibile.

Elencare le funzionalità richieste in modo leggibile

Se devi produrre un inventario delle funzioni Hyper-V richieste, conviene partire dai cmdlet del modulo e filtrare quelli più rilevanti per l’operatività quotidiana. In genere, i gruppi più interessanti sono quattro: macchine virtuali, switch virtuali, dischi virtuali e checkpoint.

Un elenco sintetico dei cmdlet più usati può essere ottenuto così:

Get-Command -Module Hyper-V | Select-Object Name, Verb, Noun | Sort-Object Noun, Name

Se vuoi restringere la vista ai comandi principali, puoi fare così:

Get-Command -Module Hyper-V | Where-Object { $_.Name -match '^(Get|New|Set|Start|Stop|Remove|Connect)-' } | Sort-Object Name

Il punto non è avere una lista infinita, ma capire se il sistema espone le funzioni necessarie per amministrare VM, reti virtuali e storage. Se uno di questi blocchi manca, la causa più comune è l’assenza del modulo completo o di un ruolo installato a metà.

Controllare anche i prerequisiti hardware e di piattaforma

Mostrare le funzionalità richieste per Hyper-V senza verificare la piattaforma è un errore tipico. Hyper-V non è solo software: dipende da estensioni di virtualizzazione hardware, SLAT e supporto firmware. In ambienti reali, il problema spesso non è il cmdlet mancante, ma una CPU o una configurazione BIOS/UEFI che non consente l’attivazione completa della virtualizzazione.

Per una verifica rapida lato sistema puoi usare:

systeminfo.exe | findstr /i "Hyper-V"

Il comando non è elegante, ma è utile perché mostra in modo immediato i requisiti mancanti o il supporto rilevato. Se vedi messaggi su virtualizzazione disabilitata nel firmware, la soluzione non sta in PowerShell: devi intervenire sul BIOS/UEFI del server o del client.

Su sistemi moderni conviene anche verificare lo stato della virtualizzazione con un controllo più diretto, soprattutto se il server è un host fisico o una VM annidata. In ambienti nested virtualization, il fatto che il modulo Hyper-V sia presente non garantisce che le VM partano correttamente.

Installare i componenti necessari senza fare confusione tra host e management tools

Qui c’è un altro punto che genera errori: alcune installazioni richiedono solo gli strumenti di gestione, altre richiedono il ruolo completo di Hyper-V. Se devi amministrare un host remoto, può bastare il modulo di gestione; se devi trasformare il server nell’host stesso, serve il ruolo completo.

Su Windows Server, l’installazione tipica del ruolo è questa:

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart

Il parametro -IncludeManagementTools è importante: aggiunge i componenti di amministrazione, evitando di ritrovarti con un host che ha il ruolo ma non i tool per gestirlo comodamente dalla stessa sessione. Il riavvio è spesso necessario perché l’host deve attivare il livello di virtualizzazione e i driver associati.

Su client Windows, l’abilitazione della feature può essere fatta così:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All

Se il comando fallisce, il primo controllo non è “riprovare”, ma leggere il motivo: errore di edizione, requisito mancante o policy aziendale che blocca l’installazione. In ambienti gestiti, il problema può essere una restrizione di compliance e non una mancanza tecnica.

Verificare la presenza dei cmdlet dopo l’installazione

Dopo l’installazione, la verifica corretta è molto semplice: il modulo deve comparire, i cmdlet devono essere enumerabili e almeno una query di stato deve funzionare. Un controllo utile è questo:

Get-Module -ListAvailable Hyper-V | Select-Object Name, Version, Path

Se vuoi validare la parte operativa, esegui un comando innocuo come l’elenco delle VM presenti sul sistema:

Get-VM

Se la macchina non ospita VM, il comando può restituire una lista vuota senza essere un errore. Questa differenza è importante: una risposta vuota non significa che Hyper-V non funzioni, ma solo che non ci sono oggetti da mostrare. Un errore vero invece indica assenza del modulo, permessi insufficienti o servizi non disponibili.

Per i switch virtuali:

Get-VMSwitch

Questo comando è utile perché collega la parte software alla rete del sistema. Se il modulo funziona ma non trovi switch, il problema può essere nella configurazione dell’host o in una gestione esterna delle interfacce virtuali.

Mostrare le funzionalità richieste in uno script PowerShell

Se devi documentare o automatizzare il controllo, uno script breve è più utile di una spiegazione teorica. L’idea è produrre un resoconto chiaro: feature di sistema, modulo disponibile, cmdlet principali, stato base dell’host. Ecco una struttura semplice e leggibile:

$result = [ordered]@{}
$result.OSFeature = (Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -ErrorAction SilentlyContinue).State
$result.Module = (Get-Module -ListAvailable Hyper-V | Select-Object -First 1).Version.ToString()
$result.Cmdlets = (Get-Command -Module Hyper-V -ErrorAction SilentlyContinue | Measure-Object).Count
$result.VMs = (Get-VM -ErrorAction SilentlyContinue | Measure-Object).Count
$result | Format-List

Questo approccio ha un vantaggio pratico: non si limita a dire “Hyper-V c’è”, ma mostra quali pezzi sono effettivamente disponibili. Se un campo torna vuoto, sai subito dove andare a cercare: nella feature di Windows, nel modulo o nei permessi della sessione PowerShell.

Se vuoi una versione più robusta per ambienti di produzione, conviene aggiungere un controllo di errore esplicito e un output in CSV o JSON. In questo modo puoi integrare il risultato in inventari, check di compliance o pipeline di amministrazione remota.

Permessi, sessione elevata e remoting

Molti test falliscono non perché Hyper-V manchi, ma perché la sessione non ha privilegi sufficienti. Per alcune operazioni su Hyper-V serve una shell elevata o l’appartenenza ai gruppi amministrativi corretti. Se stai lavorando in remoting, il problema può essere ancora più banale: il modulo è disponibile localmente, ma non nella sessione remota o non viene importato automaticamente.

Per verificare il contesto della sessione:

[Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()

Per il remoting, il test più concreto è eseguire un comando Hyper-V semplice sulla macchina remota e verificare che il risultato sia coerente con l’host target. Se il modulo non è importabile nella sessione remota, il problema può essere il path dei moduli, la configurazione WinRM o il profilo utente usato nel remoting.

Un esempio operativo completo

Se vuoi una sequenza lineare per vedere le funzionalità richieste e capire subito se il sistema è pronto, usa questo ordine:

  1. Verifica la feature di sistema con Get-WindowsFeature -Name Hyper-V* o con Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All, a seconda del sistema operativo.
  2. Controlla la presenza del modulo con Get-Module -ListAvailable Hyper-V.
  3. Importa il modulo con Import-Module Hyper-V.
  4. Elenca i cmdlet disponibili con Get-Command -Module Hyper-V.
  5. Esegui una query innocua, ad esempio Get-VM o Get-VMSwitch, per validare che il layer di gestione sia operativo.

Questa sequenza riduce gli equivoci e ti permette di diagnosticare rapidamente dove si interrompe il flusso. Se il primo comando fallisce, il problema è nella feature. Se il secondo fallisce, il problema è nel modulo o nell’installazione. Se il quarto funziona ma il quinto no, stai guardando una questione di autorizzazioni o di stato dell’host.

Errore comune: confondere l’assenza di VM con l’assenza di Hyper-V

Un sistema Hyper-V perfettamente funzionante può restituire nessuna VM, nessuno switch e nessun disco virtuale se è appena installato o se non è stato ancora configurato. Questo non va letto come guasto. La presenza del modulo e dei cmdlet è una condizione diversa dalla presenza di oggetti già creati.

Per distinguere i casi, osserva sempre tre cose: il modulo esiste, i cmdlet esistono, e il sistema risponde ai comandi di stato. Solo dopo ha senso parlare di configurazione delle VM. Se invece il modulo non esiste, non c’è nulla da amministrare via PowerShell fino a quando non installi i componenti corretti.

Conclusione operativa: cosa mostrare davvero

Se l’obiettivo è mostrare le funzionalità richieste per Hyper-V con PowerShell, il contenuto utile non è una lista astratta di cmdlet, ma una verifica completa del percorso: feature di Windows, modulo Hyper-V, cmdlet disponibili e stato base dell’host. In questo modo ottieni un quadro tecnico affidabile, replicabile e adatto sia a un controllo manuale sia a uno script di inventario.

La regola pratica è semplice: prima confermi che il sistema supporta Hyper-V, poi confermi che PowerShell lo espone, infine confermi che l’host risponde. Solo così la documentazione sulle funzionalità richieste ha valore operativo e non resta una descrizione teorica.