• Guide, Sistemi Operativi
• 7 Febbraio 2026

Con l’arrivo di Windows Server 2025, Microsoft continua a spingere sull’automazione e sulla semplificazione della gestione delle infrastrutture, in particolare quando si parla di cluster Hyper-V e scenari Software Defined. Se avete mai configurato manualmente la rete di un failover cluster, sapete bene quanto questa fase possa diventare complessa e delicata: tra teaming, RDMA, QoS, MTU, VMQ, RSS e decine di parametri da allineare su tutti i nodi, il rischio di errori o configurazioni non coerenti è sempre dietro l’angolo.

Proprio per affrontare queste difficoltà nasce Network ATC (Automated Traffic Control), una delle novità più interessanti introdotte nelle edizioni Datacenter di Windows Server 2025. L’idea alla base di questa funzionalità è semplice ma molto potente: invece di configurare manualmente ogni singolo aspetto della rete, vi basta dichiarare l’intento, cioè il ruolo che quelle schede di rete dovranno svolgere all’interno del cluster. Sarà poi il sistema ad applicare automaticamente le impostazioni consigliate, seguendo le best practices validate da Microsoft.

Questo approccio, basato sugli intenti e non più sulle singole configurazioni, riduce drasticamente il tempo necessario per la preparazione dei nodi e, soprattutto, evita la deriva delle configurazioni nel tempo. Se qualcuno modifica manualmente un parametro su una scheda di rete, Network ATC è in grado di riportare automaticamente l’ambiente allo stato desiderato, garantendo coerenza e stabilità all’intero cluster.

In questo articolo vedremo come funziona Network ATC, quali sono i requisiti da rispettare e come utilizzarlo in pratica su un cluster Hyper-V con Windows Server 2025, in modo da costruire una base di rete solida e allineata alle best practice prima ancora di distribuire i carichi di lavoro.

Scenari di configurazione con Network ATC

Uno degli aspetti più interessanti di Network ATC è la sua flessibilità. Non esiste un’unica configurazione valida per tutti: potete adattare il design della rete in base al numero di schede disponibili e al tipo di ambiente che state realizzando. La documentazione ufficiale Microsoft descrive tre scenari principali, che rappresentano i modelli più comuni per i cluster Hyper-V.

Il primo scenario è quello completamente convergente, pensato per ambienti con poche schede di rete. In questo caso, due sole NIC gestiscono tutto il traffico del cluster: management, compute e storage. È la configurazione più semplice e spesso viene utilizzata nei laboratori o in ambienti di piccole dimensioni.

Figura 1: Fully converged intent
Scenario convergente con due schede di rete: traffico di management, compute e storage gestito dallo stesso team di NIC tramite un unico intent di Network ATC

Il secondo scenario è quello parzialmente convergente, molto diffuso negli ambienti di produzione. Qui il traffico di management utilizza una coppia dedicata di schede, mentre compute e storage condividono un’altra coppia di NIC ad alte prestazioni. Questa soluzione rappresenta un buon compromesso tra semplicità e isolamento del traffico.

Figura 2: Converged compute and storage intent; separate management intent
Scenario parzialmente convergente: intent dedicato al management su una coppia di NIC e intent condiviso per compute e storage su una seconda coppia di schede ad alte prestazioni

Il terzo scenario è quello completamente disaggregato, tipico degli ambienti datacenter o delle infrastrutture ad alte prestazioni. In questa configurazione ogni tipo di traffico utilizza una coppia di schede dedicata: due NIC per il management, due per il compute e due per lo storage. Questo approccio garantisce il massimo isolamento tra i flussi di traffico e permette di ottimizzare in modo specifico ogni rete.

Figura 3: Fully disaggregated intent
Scenario completamente disaggregato: intent separati per management, compute e storage, ciascuno con una coppia dedicata di schede di rete per garantire isolamento e prestazioni ottimali

Prerequisiti e configurazione delle schede di rete

Prima di configurare Network ATC è fondamentale preparare correttamente gli host, perché questa funzionalità si basa su alcuni requisiti molto precisi. Se questi prerequisiti non vengono rispettati, l’intent non verrà applicato e la configurazione automatica della rete non potrà essere eseguita.

Per il laboratorio utilizzeremo macchine virtuali Hyper-V in nested virtualization, una soluzione molto comoda per test e demo, perché permette di simulare un cluster completo anche su un singolo host fisico. All’interno di ogni host virtuale creeremo 6 schede di rete, così da poter realizzare una configurazione completamente disaggregata, con traffico di management, compute e storage separati.

Secondo la documentazione ufficiale Microsoft, tutti i nodi del cluster devono eseguire Windows Server 2025 Datacenter e disporre di schede di rete simmetriche tra loro, cioè con lo stesso modello, la stessa velocità e la stessa configurazione. Inoltre, è fondamentale che gli adattatori utilizzati negli intent abbiano gli stessi nomi su tutti i nodi; in caso contrario, Network ATC non riuscirà ad applicare la configurazione.

Creazione delle schede di rete nelle VM

Come ho già scritto prima, nel nostro laboratorio creeremo due nodi Hyper-V virtuali, ciascuno con 6 schede di rete. La suddivisione sarà la seguente:

• Due schede per il traffico di management
• Due schede per il traffico di compute
• Due schede per il traffico di storage

Questa configurazione è quella più completa e riflette uno scenario tipico di datacenter, dove i flussi di traffico vengono separati per ottenere prestazioni e isolamento migliori.

Una volta aggiunte le schede di rete alle macchine virtuali, è necessario uniformare i nomi all’interno del sistema operativo.

Verifica dei nomi delle schede

All’interno di ogni nodo, aprite una sessione PowerShell con privilegi amministrativi ed eseguite:

Otterrete un elenco con i nomi delle schede di rete, come mostrato nella figura sotto:

Figura 4: Schede di rete presenti sugli host di virtualizzazione

Questi nomi non sono adatti per Network ATC, perché devono essere coerenti e prevedibili su tutti i nodi.

Rinominare le schede di rete

Per uniformare i nomi, possiamo usare il cmdlet Rename-NetAdapter. Eseguite i seguenti comandi su ciascun nodo:

Al termine, verificate nuovamente la configurazione

Il risultato dovrà essere identico su tutti i nodi, come vi mostrato nella figura sotto:

Figura 5: Tutte le schede di rete sono state rinominate

Questa uniformità è essenziale, perché Network ATC applica gli intent a livello di cluster e si basa sui nomi delle schede per identificare gli adattatori corretti.

Installazione delle funzionalità richieste

Prima di configurare Network ATC è necessario installare alcune feature di Windows Server su tutti i nodi:

• Hyper-V
• Failover Clustering
• Data Center Bridging
• Network ATC

Possiamo installarle tutte con un unico comando:

Al termine dell’installazione, riavviate i nodi.

Figura 6: Installazione delle funzionalità necessarie per Hyper-V, Failover Clustering, Data Center Bridging e Network ATC tramite PowerShell, con richiesta di riavvio del server per completare la configurazione

A questo punto gli host sono pronti: le schede di rete sono simmetriche, hanno nomi coerenti e tutte le funzionalità necessarie sono installate.

Creazione del cluster Hyper-V

Dopo aver preparato gli host e configurato correttamente le schede di rete, il passo successivo consiste nella creazione del failover cluster. Network ATC è progettato per funzionare su cluster Windows Server; quindi, gli intent possono essere applicati solo dopo che il cluster è stato creato e validato correttamente, come indicato nella documentazione ufficiale Microsoft.

Verifica preliminare del cluster

Prima di creare il cluster è sempre consigliato eseguire la validazione, così da verificare che l’hardware e la configurazione siano compatibili con il failover clustering.

Da uno dei nodi, aprite PowerShell con privilegi amministrativi ed eseguite:

Sostituite HV-ATC1 e HV-ATC2 con i nomi reali dei vostri nodi.

Al termine del test verrà generato un report HTML con l’esito delle verifiche. In un ambiente di laboratorio con virtualizzazione nested è possibile ricevere alcuni warning, ma l’importante è che non ci siano errori bloccanti.

Figura 7: Test del Cluster e generazione del report di validazione

Creazione del cluster

Una volta completata la validazione, possiamo procedere con la creazione del cluster. Sempre da PowerShell:

Dopo pochi secondi, il cluster verrà creato e i nodi verranno aggiunti automaticamente.

Figura 8: Creazione del failover cluster tramite PowerShell e verifica dei nodi operativi all’interno di Failover Cluster Manager

NOTA: In questo articolo ci concentreremo esclusivamente sulla configurazione della rete e sull’utilizzo di Network ATC, senza entrare nel dettaglio di tutti gli aspetti legati al failover clustering. Non verranno quindi trattati argomenti come la configurazione dello storage condiviso, il quorum o le altre impostazioni avanzate richieste da un cluster di produzione. L’obiettivo è costruire un ambiente di laboratorio funzionante, sufficiente per comprendere il funzionamento degli intent e l’automazione introdotta da Network ATC, senza appesantire la guida con configurazioni non strettamente necessarie a questo scenario. Però se volete approfondire come configurare al meglio un failover cluste rin Windows Server, potete dare un’occhiata alla mia guida Configurare un Failover Cluster in Windows Server 2019 e Windows Server 2022 – ICT Power

Configurazione degli intent con Network ATC

Dopo aver creato il failover cluster e verificato che tutti i nodi siano operativi, possiamo passare alla parte centrale della guida: la configurazione degli intent di Network ATC. È proprio in questa fase che entra in gioco l’approccio intent-based, che permette di definire il ruolo delle schede di rete senza dover configurare manualmente ogni singolo parametro.

Nel laboratorio ho scelto uno scenario completamente disaggregato con 6 schede di rete per nodo, quindi creeremo tre intent separati: uno per il management, uno per il traffico compute delle macchine virtuali e uno per lo storage.

Secondo la documentazione ufficiale Microsoft, è sufficiente specificare il nome dell’intent, il tipo di traffico e le schede di rete da utilizzare. Tutte le altre configurazioni, come Switch Embedded Teaming, QoS, DCB e le ottimizzazioni delle schede, verranno applicate automaticamente.

Creazione dell’intent di management

Il primo intent sarà dedicato al traffico di gestione del cluster. Utilizzeremo le schede pNIC01 e pNIC02.

Eseguite il comando da uno dei nodi del cluster:

Questo comando crea un intent di tipo management e lo applica automaticamente a tutti i nodi del cluster.

Figura 9: Creazione dell’intent di management con il comando Add-NetIntent e verifica automatica delle schede di rete su tutti i nodi del cluster

Creazione dell’intent di compute

Ora configuriamo l’intent dedicato al traffico delle macchine virtuali, utilizzando pNIC03 e pNIC04.

Questo intent verrà utilizzato per la connettività delle VM e per la creazione dello switch virtuale Hyper-V.

Figura 10: Creazione dell’intent dedicato al traffico compute, con verifica automatica delle schede di rete e applicazione della configurazione su tutti i nodi del cluster

Creazione dell’intent di storage

Infine, configuriamo l’intent per il traffico di storage, utilizzando le schede pNIC05 e pNIC06.

In uno scenario reale, questo intent sarebbe utilizzato per traffico SMB, Live Migration o Storage Spaces Direct, con tutte le ottimizzazioni automatiche applicate da Network ATC.

VLAN predefinite per lo storage

Secondo la documentazione ufficiale Microsoft, Network ATC applica automaticamente alcune VLAN predefinite quando viene configurato un intent di tipo storage. Questo comportamento serve a semplificare la configurazione delle reti SMB tra i nodi, evitando interventi manuali e mantenendo la coerenza tra tutti gli host del cluster.

Se le schede di rete dedicate allo storage sono collegate a uno switch fisico, queste VLAN devono essere consentite sulla rete; in uno scenario switchless, invece, non è richiesta alcuna configurazione aggiuntiva.

Di seguito le VLAN utilizzate automaticamente da Network ATC per gli adattatori con intent di storage:

Nel nostro laboratorio, utilizzando due schede dedicate allo storage, Network ATC assegna automaticamente le VLAN 711 e 712, come è possibile vedere anche nell’output dei comandi di creazione degli intent. Questo comportamento conferma che le impostazioni vengono applicate in modo automatico e coerente su tutti i nodi del cluster, senza necessità di configurazioni manuali.

Figura 11: Creazione dell’intent di storage con Network ATC e validazione automatica delle schede dedicate su tutti i nodi del cluster

Dopo la creazione degli intent, Network ATC avvia automaticamente la fase di provisioning, durante la quale vengono applicate tutte le configurazioni di rete sui nodi del cluster. Questa operazione richiede in genere alcuni minuti: in un ambiente di laboratorio bastano spesso 2–5 minuti, mentre in cluster reali i tempi possono arrivare anche a 10–15 minuti, in base all’hardware e al numero di nodi. Lo stato della configurazione può essere verificato con il comando Get-NetIntentStatus.

Figura 12: Verifica dello stato degli intent con il comando Get-NetIntentStatus, che mostra errori di provisoning

NOTA: In ambienti di laboratorio basati su nested virtualization, alcune funzionalità hardware come RDMA o DCB non sono disponibili. In questi casi gli intent possono risultare nello stato Failed o Pending. È sufficiente applicare un AdapterPropertyOverride che disabiliti NetworkDirect (RDMA) sugli intent per completare correttamente il provisioning.

Figura 13: Applicazione dell’override per disabilitare RDMA sugli intent di management, compute e storage in ambiente nested virtualization

Dopo aver applicato gli override necessari, è possibile forzare la riapplicazione della configurazione sugli host del cluster utilizzando il comando Set-NetIntentRetryState. Questa operazione chiede a Network ATC di riprovare il provisioning degli intent senza doverli rimuovere e ricreare.

Una volta avviato il retry, Network ATC procede nuovamente con l’applicazione delle configurazioni sui nodi del cluster. Anche in questo caso il processo non è immediato e può richiedere alcuni minuti, soprattutto in ambienti virtualizzati. Durante questa fase lo stato degli intent può rimanere su Pending; è sufficiente attendere il completamento automatico e verificare l’esito con il comando Get-NetIntentStatus, che mostrerà lo stato Completed una volta terminato il provisioning.

Figura 14: Verifica finale degli intent con Get-NetIntentStatus: tutti gli intent di management, compute e storage risultano configurati correttamente con stato Success e provisioning Completed su entrambi i nodi del cluster

Dopo il completamento del provisioning degli intent, è possibile verificare direttamente dal Virtual Switch Manager le configurazioni applicate automaticamente da Network ATC. Nel nostro scenario compaiono due switch virtuali: uno associato all’intent di management, che crea anche la relativa vNIC per la gestione dell’host, e uno dedicato all’intent di compute, utilizzato per il traffico delle macchine virtuali. L’intent di storage, invece, non genera uno switch visibile nel Virtual Switch Manager, poiché viene utilizzato esclusivamente per il traffico SMB tra i nodi del cluster. Questo comportamento è previsto dalla progettazione di Network ATC e conferma che la configurazione della rete è stata applicata correttamente in base agli intent definiti.

Figura 15: Virtual Switch Manager di Hyper-V: visualizzazione degli switch creati automaticamente da Network ATC per gli intent di management e compute, senza configurazioni manuali

Nelle connessioni di rete dell’host è possibile osservare le schede fisiche assegnate ai vari intent e la vNIC di management creata automaticamente da Network ATC. Solo l’intent di management genera una vNIC visibile sull’host, mentre l’intent di compute crea esclusivamente lo switch virtuale per le macchine virtuali. Questo comportamento è previsto e conferma che la configurazione degli intent è stata applicata correttamente.

Figura 16: Connessioni di rete dell’host dopo l’applicazione degli intent: le pNIC fisiche e la vNIC di management create automaticamente da Network ATC

Figura 17: Verifica delle reti di storage nel Failover Cluster Manager: dopo l’abilitazione del trunk VLAN sull’host fisico, le reti Storage_VLAN711 e Storage_VLAN712 risultano operative su entrambi i nodi

Considerazioni per ambienti in nested virtualization

Quando si utilizza Network ATC in un ambiente di laboratorio basato su nested virtualization, è importante tenere presente che le configurazioni di rete applicate all’interno delle VM devono poter attraversare anche lo switch virtuale dell’host fisico che le ospita.

Nel nostro scenario, l’intent di storage utilizza automaticamente le VLAN 711 e 712 per il traffico SMB tra i nodi. Queste VLAN vengono configurate da Network ATC all’interno degli host Hyper-V del cluster, ma se le VM sono eseguite in modalità nested, il traffico deve passare anche attraverso la scheda di rete virtuale della VM e lo switch dell’host fisico.

Se le schede di rete delle VM non sono configurate in modalità trunk, le VLAN di storage non vengono inoltrate correttamente e il cluster può mostrare le reti di storage nello stato Partitioned, anche se gli intent risultano configurati con stato Success.

Per evitare questo comportamento, è necessario abilitare il trunk VLAN sulle schede di rete delle VM nested direttamente sull’host fisico.

Configurazione del trunk VLAN sull’host fisico

Eseguite i seguenti comandi sull’host Hyper-V che ospita le VM del cluster:

Con questa configurazione:

• Le VM vengono collegate allo switch in modalità trunk
• Tutte le VLAN, incluse 711 e 712, possono attraversare lo switch virtuale
• Il traffico di storage tra i nodi viene rilevato correttamente dal cluster

Dopo aver applicato questa configurazione, è possibile generare traffico SMB tra i nodi o semplicemente attendere alcuni minuti per vedere lo stato delle reti aggiornarsi nel Failover Cluster Manager.

Questa configurazione è necessaria solo negli ambienti di test basati su nested virtualization. In un’infrastruttura fisica, le VLAN di storage devono semplicemente essere consentite sugli switch di rete.

 

Copiare la configurazione degli intent con Copy-NetIntent

Il cmdlet Copy-NetIntent permette di replicare uno o più network intent da un cluster a un altro, senza dover ricreare manualmente l’intera configurazione. È particolarmente utile quando si gestiscono ambienti simili tra loro, ad esempio cluster di produzione, test o disaster recovery, dove si vuole mantenere la stessa configurazione di rete.

Lo scenario più comune è la copia completa della configurazione da un cluster sorgente a uno di destinazione. In questo modo tutti gli intent, comprese eventuali personalizzazioni e override, vengono replicati automaticamente.

In altri casi può essere necessario copiare solo un singolo intent, ad esempio quello di storage, dopo aver testato una nuova configurazione in un ambiente di laboratorio.

Lo stesso approccio può essere utilizzato anche durante il deployment di un nuovo cluster, partendo da un cluster “template” già configurato. In questo modo si ottiene rapidamente una configurazione coerente, riducendo il rischio di errori manuali.

Questo cmdlet diventa quindi uno strumento utile per standardizzare le configurazioni di rete e velocizzare le attività di distribuzione o migrazione tra cluster con architetture simili.

Configurazione di Network ATC da Windows Admin Center

Oltre alla configurazione tramite PowerShell, Network ATC può essere gestito anche da Windows Admin Center, che offre un’interfaccia grafica pensata per semplificare ulteriormente la creazione e la gestione degli intent nei cluster Hyper-V. Questa modalità è particolarmente utile nei laboratori, nelle fasi di test o quando si desidera avere una visione immediata dello stato della configurazione.

Dalla sezione dedicata alla rete del cluster, Windows Admin Center consente di creare nuovi intent selezionando direttamente le schede di rete e il tipo di traffico da associare, senza dover utilizzare i comandi PowerShell. L’interfaccia guida l’amministratore nella scelta degli adattatori e degli intent di management, compute e storage, applicando automaticamente le impostazioni consigliate.

Una volta creati gli intent, è possibile:

• visualizzare lo stato di provisioning su tutti i nodi
• controllare eventuali errori o warning
• verificare le schede di rete coinvolte
• monitorare le configurazioni applicate da Network ATC

Windows Admin Center permette inoltre di avere una visione centralizzata delle reti del cluster, degli switch virtuali e delle schede di rete, facilitando le attività di verifica senza dover passare da più strumenti o comandi.

In questo articolo abbiamo utilizzato la configurazione tramite PowerShell per mostrare in modo esplicito tutti i passaggi, ma in ambienti operativi o durante attività di troubleshooting, Windows Admin Center rappresenta un’alternativa grafica molto comoda per gestire gli intent di Network ATC e monitorarne lo stato.

Figura 18: Sezione Network ATC in Windows Admin Center: da qui è possibile installare il ruolo e creare gli intent di rete direttamente dall’interfaccia grafica del cluster

Figura 19: Vista degli intent configurati in Windows Admin Center: stato, nodi coinvolti e schede di rete assegnate per ogni tipologia di traffico

Quando facciamo clic su + New, Windows Admin Center apre la procedura guidata per la creazione di un nuovo network intent. Da questa schermata possiamo definire in modo grafico le stesse impostazioni che abbiamo configurato via PowerShell nei passaggi precedenti.

La procedura richiede innanzitutto un nome per l’intent, che verrà poi applicato a livello di cluster. Subito dopo possiamo selezionare uno o più tipi di traffico tra Compute, Management, Storage e Stretch, in base allo scenario che vogliamo implementare.

Nel campo Network adapters scegliamo invece le schede fisiche che dovranno essere associate a quell’intent. Anche in questo caso valgono le stesse regole viste nella documentazione Microsoft: le schede devono essere simmetriche tra i nodi del cluster, con stesso modello e stesse caratteristiche.

Espandendo la sezione Customize network settings possiamo applicare alcune personalizzazioni, come ad esempio la dimensione dei jumbo frame, senza dover ricorrere agli override via PowerShell.

Una volta completati i campi richiesti e confermata la creazione, Windows Admin Center invia la configurazione al cluster e Network ATC provvede automaticamente al provisioning delle impostazioni su tutti i nodi, esattamente come avviene con il comando Add-NetIntent. In pochi minuti verranno creati gli switch virtuali, le vNIC e tutte le ottimizzazioni di rete necessarie in base al tipo di intent selezionato.

Figura 20: Finestra di creazione di un nuovo intent in Windows Admin Center, con selezione del tipo di traffico e delle schede di rete da assegnare

Dalla sezione Network ATC cluster settings di Windows Admin Center possiamo gestire le impostazioni globali applicate a tutto il cluster.

Qui troviamo opzioni come:

• il naming automatico delle reti create da Network ATC,
• la selezione automatica delle reti per la Live Migration,
• i parametri di prestazioni delle migrazioni tra nodi, come numero massimo di migrazioni simultanee e banda SMB utilizzata.

Nella maggior parte dei casi è consigliabile lasciare le impostazioni predefinite, in quanto seguono le best practice Microsoft e garantiscono una configurazione coerente e ottimizzata.

Figura 21: Impostazioni globali di Network ATC in Windows Admin Center, tra naming automatico e parametri di Live Migration

Nella sezione Network ATC proxy settings è possibile configurare un server proxy a livello di cluster, utile negli ambienti aziendali dove l’accesso a Internet è filtrato.

Da qui possiamo:

• abilitare l’uso di un proxy per Network ATC,
• specificare uno o più indirizzi proxy,
• definire una bypass list per gli indirizzi che non devono passare dal proxy.

Questa configurazione è richiesta solo negli ambienti con restrizioni di rete o accesso controllato verso i servizi esterni; nei laboratori o nelle infrastrutture senza proxy può essere lasciata disattivata.

Figura 22: Configurazione del proxy per Network ATC in Windows Admin Center

La sezione Networks permette di visualizzare le reti del cluster rilevate automaticamente, il loro stato e l’utilizzo (Cluster Only, Cluster and Client). È utile per verificare rapidamente se le reti di management e storage sono state configurate correttamente da Network ATC.

Figura 23: Vista delle reti del cluster in Windows Admin Center, con stato e utilizzo per management e storage

Nella sezione Virtual switches di Windows Admin Center possiamo verificare gli switch virtuali creati da Network ATC su ciascun nodo.
Nel nostro esempio vediamo, per entrambi i nodi:

• ConvergedSwitch (mgmt): switch esterno condiviso con il sistema operativo di gestione.
• ComputeSwitch (compute): switch esterno dedicato al traffico delle macchine virtuali, non condiviso con il management OS.

La colonna Teamed-Interface indica che gli switch sono stati creati su un team di schede fisiche, configurato automaticamente da Network ATC.
Questa schermata consente quindi di confermare che gli intent di tipo management e compute hanno generato correttamente i virtual switch su tutti i nodi del cluster.

Figura 24: Elenco dei virtual switch creati automaticamente da Network ATC sui nodi del cluster

Conclusioni

Con Network ATC in Windows Server 2025 la configurazione della rete nei cluster Hyper-V diventa molto più semplice, coerente e soprattutto ripetibile. Invece di intervenire manualmente su team, vSwitch, QoS, RDMA e decine di parametri avanzati, è sufficiente definire l’intent desiderato e lasciare che il sistema applichi automaticamente le best practice validate da Microsoft.

Nel laboratorio abbiamo visto come, partendo da host con schede di rete simmetriche, sia possibile creare gli intent di management, compute e storage con pochi comandi PowerShell. Network ATC ha poi configurato automaticamente gli switch virtuali, le vNIC, le VLAN e le policy di rete necessarie, garantendo una configurazione uniforme su tutti i nodi del cluster.

Network ATC rappresenta quindi un passo importante verso un modello di gestione intent-based anche per la rete dei cluster Hyper-V, riducendo la complessità operativa e limitando il rischio di configuration drift tra i nodi. In scenari reali, questo si traduce in implementazioni più rapide, configurazioni più affidabili e una manutenzione decisamente più semplice nel tempo.