Nel panorama IT odierno, quando si parla di abbandono delle piattaforme di virtualizzazione proprietarie, la narrativa dominante spinge verso il cloud pubblico o verso architetture iperconvergenti di ultima generazione. Ma per le aziende Enterprise che hanno già infrastrutture consolidate — server tradizionali, SAN in fibra, cluster Failover collaudati — c’è un dato che vale la pena rimettere al centro: Hyper-V non è affatto morto.
Non è un’affermazione di parte. La documentazione di sicurezza di Azure lo dice chiaramente: il sistema hypervisor di Azure è basato su Windows Hyper-V, con il partizionamento tra root partition e guest partition che conosciamo dall’on-premises (Hypervisor security on the Azure fleet). La stessa famiglia tecnologica che gira nei datacenter Microsoft di mezzo mondo è quella che possiamo installare su un server nel nostro rack.
Il vero problema di Hyper-V, storicamente, non è mai stato l’hypervisor. È stata la console.
Il problema che tutti conosciamo
Per anni gli amministratori di sistema hanno gestito ambienti Hyper-V saltando da uno strumento all’altro: Hyper-V Manager per le VM, Failover Cluster Manager per i cluster, PowerShell per tutto il resto, e System Center Virtual Machine Manager (SCVMM) quando serviva davvero una vista di fabric — con il costo di licenza e il peso operativo che SCVMM si porta dietro.
Windows Admin Center ha migliorato molto le cose, ma con un limite architetturale preciso: è nato stateless. Si connette al server, esegue il comando, chiude la sessione. Perfetto per il troubleshooting su un singolo host, strutturalmente inadatto a rappresentare un fabric da centinaia di nodi.
È esattamente questo il gap che Microsoft ha deciso di colmare.
Due modalità, due filosofie: aMode vs vMode
Windows Admin Center oggi esiste in due modalità indipendenti, come descritto nell’overview ufficiale:
- Administration Mode (aMode) — la console che già conosciamo, orientata all’amministrazione generale di sistema: Device Manager, Registry Editor, Ruoli e Funzionalità, Remote Desktop.
- Virtualization Mode (vMode) — una piattaforma orientata alla gestione del fabric di virtualizzazione: host e cluster Hyper-V, ciclo di vita delle VM, Storage Spaces Direct, Network ATC, volumi.
Le differenze non sono cosmetiche. Questa è la sintesi che ne dà Microsoft
Importante: aMode e vMode devono essere installati su sistemi separati. Non è una raccomandazione, è un requisito documentato.
Le tappe: dove siamo oggi
La cronologia aiuta a capire quanto rapidamente si stia muovendo il team:
- Novembre 2025 (Ignite) — annuncio e prima Public Preview di vMode (blog di annuncio).
- Aprile 2026 — Public Preview 2, con miglioramenti sostanziali a installazione e upgrade, Resource Health, wizard di onboarding e ricerca globale (annuncio PP2).
- Giugno 2026 — aggiornamento della build di Public Preview 2 alla 2.7.1.8, con il passaggio di tutte le estensioni ad Angular 20 e la correzione, tra le altre, di un errore sui requisiti OS che si presentava sui sistemi in lingua non inglese (note di rilascio).
Una precisazione terminologica utile, perché genera confusione: “Public Preview 2” indica la seconda preview pubblica di vMode, non la versione 2 di Windows Admin Center. La data di General Availability non è ancora stata annunciata ufficialmente.
Un dettaglio operativo che fa piacere: a partire da PP2 l’upgrade si esegue lanciando il nuovo installer sopra l’installazione esistente. Il database viene aggiornato automaticamente e, se la release lo richiede, anche gli agent sulle macchine gestite vengono aggiornati in autonomia.
Sotto il cofano: architettura client-server e stato persistente
vMode si distribuisce come appliance su una macchina fisica o virtuale. L’architettura è client-server:
- un gateway web che gestisce autenticazione utente, routing delle richieste e mantiene un database stateful;
- agent locali installati sugli host Hyper-V gestiti, che eseguono materialmente le operazioni;
- comunicazione tra gateway e agent protetta da TLS.
Il vantaggio pratico dell’agent è la parallelizzazione: le operazioni non vengono serializzate su sessioni WinRM aperte al volo, ma distribuite agli agent che le eseguono simultaneamente sui rispettivi host. Microsoft dichiara che questa architettura è progettata per orchestrare ambienti su larga scala senza impattare disponibilità e prestazioni degli host gestiti durante le normali operazioni.
Il ruolo di PostgreSQL
La persistenza dello stato è affidata a un database PostgreSQL installato localmente insieme al gateway, che conserva l’inventario, i Resource Group, i template e lo stato del fabric.
Attenzione a un punto che circola spesso in forma imprecisa: PostgreSQL non è del tutto invisibile durante il setup. La procedura di installazione presenta una schermata dedicata in cui si scelgono username, password e porta del database (documentazione di installazione). È trasparente nella gestione quotidiana e negli upgrade — non nel giorno uno. Conservate quelle credenziali insieme al resto della documentazione di infrastruttura.
Prerequisiti: leggere prima di accendere il lab
Qui si concentra la maggior parte dei fallimenti di onboarding. Ci sono due set distinti di requisiti: uno per il gateway, uno per gli host gestiti. Sono diversi, e il secondo è più stringente del primo.
1. Il server gateway vMode
| Requisito | Valore |
|---|---|
| CPU | 4 vCPU (o core fisici equivalenti) |
| RAM | Almeno 8 GB |
| Disco | Almeno 10 GB liberi |
| Sistema operativo | Windows Server 2025 o successivo, edizione Standard o Datacenter |
| Dominio | Domain-joined, con risoluzione DNS tramite FQDN |
| Coesistenza | Sistema dedicato: aMode e vMode non convivono sulla stessa macchina |
| Privilegi | Diritti amministrativi sulla macchina di installazione |
2. Gli host Hyper-V da gestire
Questo è il punto che l’entusiasmo fa saltare più spesso. Per essere onboardati in vMode, gli host devono soddisfare requisiti più restrittivi del gateway (documentazione Add resources):
- 4 vCPU, almeno 8 GB di RAM, 10 GB di spazio libero;
- Windows Server 2025 o successivo, edizione Datacenter soltanto;
- domain-joined, nello stesso dominio del gateway vMode, con risoluzione FQDN;
- le seguenti funzionalità Windows Server già installate:
- Hyper-V
- Failover Clustering
- Data Center Bridging
- Network ATC
- l’utente che esegue l’onboarding deve essere Administrator locale su ciascun host.
Se avete un lab con host in edizione Standard, l’onboarding non andrà a buon fine. Meglio saperlo prima di installare.
3. Dipendenze software sul gateway
L’unico prerequisito software è il Visual C++ Redistributable:
# Prerequisito software richiesto sul gateway vMode. # Fonte: Microsoft Learn - Install Windows Admin Center Virtualization Mode winget install Microsoft.VCRedist.2015+.x64 --Silent
In assenza di connettività Internet sul server, si scarica il pacchetto manualmente dalla pagina ufficiale Visual C++ Redistributable.
4. Firewall sugli host
Prima di aggiungere una risorsa vanno abilitate due regole in ingresso del Windows Firewall:
- File and Printer Sharing (SMB-In) — necessaria solo per l’installazione dell’agent; può essere disabilitata a onboarding completato;
- Windows Remote Management — usata dal gateway per comunicare con l’host dopo l’installazione dell’agent.
Sono gestibili centralmente via Group Policy o localmente via PowerShell. Notare che il set richiesto è più ristretto di quanto si legga spesso in giro: non serve aprire mezzo perimetro.
5. Certificati
Durante il setup si sceglie il certificato TLS. Al momento i certificati preinstallati non sono disponibili: l’installer genera un self-signed con validità 60 giorni. In un lab non è un problema; per una valutazione prolungata mettetelo in agenda, perché la scadenza arriva prima di quanto sembri.
Buona notizia da PP2: la pagina Resource Health, accessibile selezionando la macchina vMode nella gerarchia di navigazione, monitora lo stato degli agent e i certificati in scadenza, e consente di consultare e scaricare i log.
