Come si organizza il fabric: Resource Group e Host Profile
vMode introduce due concetti che cambiano il modo di ragionare rispetto ad aMode.
Resource Group
Un Resource Group è un contenitore logico per organizzare le risorse di virtualizzazione. Due regole da tenere a mente: non sono annidabili, e ogni host appartiene a esattamente un Resource Group.
Servono a segregare gli host per ambiente (produzione, staging, lab) e a ridurre il rumore, perché ricerca e operazioni si possono limitare al gruppo di interesse.
Host Profile
Ogni sistema aggiunto viene classificato con un profilo, che determina la vista in cui compare e i flussi disponibili:
- Compute — host che erogano virtualizzazione. È il profilo operativo oggi.
- Storage — sistemi storage per le VM (SAN, NAS, iperconvergente con S2D). Il profilo storage non è ancora disponibile: la vista Storage mostra i dispositivi già onboardati collegati ai sistemi compute.
- Networking — servizi SDN. Anche questo profilo non è ancora disponibile; la vista Network serve oggi a gestire i template di intent di rete.
Vale la pena essere espliciti su questo punto, perché è dove la comunicazione di marketing e lo stato reale del prodotto divergono di più: il supporto architetturale a SAN, NAS, iperconvergenza e scale-out file server è dichiarato, ma la gestione completa di storage e networking software-defined non è ancora tutta lì. Storage e networking definiti da software risultano non disponibili al momento.
Il wizard di onboarding
Un unico wizard copre l’intero flusso: profilo host, FQDN, networking, clustering, storage, compute.
L’avanzamento è tracciabile in tempo reale dall’icona Workflow status in alto a destra, che mostra i singoli passaggi — installazione dell’agent inclusa.
Public Preview 2 ha reso il wizard più “intelligente” su due fronti utili in ambienti reali: se il sistema che state aggiungendo ha già un agent e potrebbe essere gestito da un’altra installazione vMode, il wizard vi avvisa e blocca l’avanzamento finché il conflitto non è risolto; e quando il nodo aggiunto appartiene a un cluster, gli altri membri vengono identificati automaticamente, evitando onboarding parziali.
Network Intent Template
La configurazione di rete degli host è storicamente il punto più soggetto a errore manuale. vMode introduce il concetto di network intent template: un intent astratto e predefinito, non ancora applicato a una scheda di rete né associato a un cluster o a un host.
Il template funziona da blueprint: si definisce una volta, si specifica su quali NIC applicarlo, e si riusa. I template persistono tra le sessioni: dopo averne creato uno nel flusso di Add Resource, resta salvato e selezionabile da menu a tendina al prossimo onboarding, senza doverlo ricreare. Sono anche gestibili fuori dal wizard, dalla vista Network nella barra di navigazione superiore, dove si possono consultare, creare, modificare ed eliminare.
Per un onboarding valido servono almeno un intent di management, uno di compute e uno di storage.
Ciclo di vita delle VM
Le operazioni quotidiane sono raccolte in un’unica interfaccia. Dalla creazione si controllano generazione (1 o 2), host di destinazione per le VM in cluster, path di storage, processori virtuali, virtualizzazione annidata, compatibilità processore (utile per la live migration tra CPU di generazioni diverse), memoria di avvio, Dynamic Memory e virtual switch.
La ricerca globale merita una nota, considerato il tetto di 25.000 VM: supporta testo semplice con wildcard (web-0* restituisce web-01 e web-02) e opera sulle risorse presenti nella gerarchia. Non sono ricercabili risorse eliminate né oggetti collegati come i dischi virtuali. Public Preview 2 l’ha estesa con ricerca per profilo, per oggetto e gerarchica.
La live migration si esegue da Manage → Move, scegliendo come destinazione un Failover Cluster (e quindi un member server) oppure un singolo server.
VM Template: standardizzare il provisioning
Questa funzionalità è già disponibile — e va detto, perché in molti articoli viene ancora elencata tra i “desiderata” (documentazione ufficiale).
Il flusso è lineare:
- Da VM a template. La VM va spenta, poi Convert to Template. Diventa read-only e assume il prefisso
{Template}{Read-only}nel riquadro risorse. Non è più disponibile come VM in esecuzione. - Deploy. Deploy VM dal template: si indicano nome e storage path della nuova VM. Il workflow valida il template, lo esporta, importa la nuova VM, la avvia e ripristina il template — che resta intatto per i deployment successivi.
- Ritorno indietro. Convert to VM rimuove lo stato read-only e riporta il template a VM normale.
Consiglio operativo che vale il paragrafo: eseguite sysprep sulla VM prima di convertirla in template. La generalizzazione rimuove le informazioni specifiche della macchina ed è ciò che rende il template davvero riutilizzabile. È una raccomandazione esplicita della documentazione, ed è il tipo di passaggio che si scopre di aver saltato tre VM dopo.
Hyper-V Replica: il DR è già dentro vMode
Altro punto spesso ancora elencato come “futuro” e invece già integrato, in preview (host singolo — cluster).
Su host singolo: si seleziona l’host destinato a fare da replica server, Settings → Hyper-V Host Settings → Replication, si abilita la macchina come replica server e si sceglie il metodo di autenticazione tra Kerberos (HTTP) e autenticazione basata su certificati (HTTPS), con porte personalizzabili.
Su cluster: si configura il ruolo Hyper-V Replica Broker, il ruolo clusterizzato che fa da punto di contatto unico per il traffico di replica anche quando la VM replica si sposta tra i nodi.
Sulla singola VM: dalla overview della VM, Manage → Configure Replication.
Due dettagli architetturali importanti per chi progetta DR: se si usa l’autenticazione a certificati non esiste dipendenza da Active Directory tra gli host — il che apre scenari tra siti con domini diversi. E per poter tornare indietro dopo un failover, vanno configurati per la replica sia il lato primario sia il lato replica, non solo il ricevente. Sono supportati failover di test, pianificati e non pianificati.
VMware exit: l’estensione VM Conversion
Per rispondere alle attuali esigenze di mercato, Microsoft ha rilasciato in Public Preview l’estensione VM Conversion per Windows Admin Center, che migra VM da vCenter a Hyper-V (overview ufficiale). È gratuita, agentless e distribuita come estensione della console.
Il flusso è in due fasi, pensato per minimizzare il downtime:
- Sincronizzazione — copia completa iniziale dei dischi mentre la VM sorgente resta accesa. Viene creato uno snapshot sulla sorgente per tracciare le modifiche e generato un file VHDX sull’host Hyper-V di destinazione.
- Migrazione — tramite Change Block Tracking (CBT) vengono replicati solo i blocchi modificati. Al cutover: delta sync, spegnimento della VM sorgente, delta sync finale, import in Hyper-V con configurazione di CPU, memoria e rete.
Le capacità più rilevanti in ottica Enterprise:
- Migrazione bulk fino a 10 VM per volta, raggruppabili per dipendenza applicativa, dipendenza da cluster, confini di business o dipendenza da rack;
- migrazione cluster-aware, da host ESXi verso cluster Failover Windows Server;
- conservazione degli indirizzi IP statici dalla sorgente alla destinazione;
- configurazione di Secure Boot e UEFI con impostazioni derivate dal tipo di OS;
- connessioni multiple a vCenter, con possibilità di passare da un endpoint all’altro;
- supporto multi-disco, prechecks automatici e rimozione dei VMware Tools dalle VM Windows dopo la migrazione.
Compatibilità: vCenter 6.x, 7.x e 8.x. Guest supportati: Windows Server dal 2012 R2 al 2025, Windows 10 e 11, distribuzioni Debian-based (Ubuntu 20.04 e 24.04, Debian 11 e 12) e RHEL-based (Alma Linux, CentOS, Red Hat Linux 9.0).
Attenzione sui guest Linux: i driver Hyper-V vanno installati prima di avviare la migrazione, altrimenti il boot post-migrazione non riesce. È il singolo punto che genera più ticket.
Best practice dichiarata: collocare il gateway Windows Admin Center nello stesso sito degli host ESXi e Hyper-V coinvolti, per minimizzare traffico WAN e latenza.
