• Guide, Sistemi Operativi
• 3 Febbraio 2026

Negli ultimi anni il networking in ambiente Hyper-V è cambiato in modo sostanziale. Se lavorate con host e cluster moderni, il termine SET (Switch Embedded Teaming) vi sarà sicuramente capitato sottomano, spesso presentato come il naturale successore del vecchio NIC Teaming. In realtà SET non è un semplice rimpiazzo, ma un cambio di approccio a come il teaming viene integrato nello stack di virtualizzazione.

A partire da Windows Server 2016, Microsoft ha spostato il teaming direttamente all’interno del virtual switch di Hyper-V. Questo elimina la separazione tra rete fisica dell’host e rete virtuale delle macchine, riducendo gli strati e rendendo il comportamento della rete più coerente e prevedibile, soprattutto negli scenari moderni ad alta densità.

In questo articolo vedremo come funziona realmente Switch Embedded Teaming e perché oggi rappresenta la scelta di riferimento in ambienti Hyper-V.

Cos’è Switch Embedded Teaming (SET)

Con Switch Embedded Teaming il teaming delle schede di rete non viene più creato a livello di host, ma è parte integrante del virtual switch. Quando create uno switch SET, assegnate direttamente più NIC fisiche e Hyper-V le gestisce come un unico insieme, occupandosi di bilanciamento e ridondanza.

Il concetto di team come oggetto separato semplicemente scompare. Non esiste più una NIC logica da collegare allo switch: è lo switch stesso a inglobare le schede fisiche. Questo rende lo stack di rete più semplice e allineato al modello di Hyper-V.

Tutto ruota attorno al virtual switch: le VM vi sono collegate e anche l’host, se condivide la rete, utilizza una vNIC come qualsiasi altra macchina virtuale.

Prerequisiti e considerazioni iniziali

SET richiede qualche attenzione in più rispetto al NIC Teaming tradizionale. La prima è banale ma fondamentale: le schede di rete devono essere identiche. Stesso modello e stessi driver.

SET non richiede configurazioni particolari lato switch fisico. Non viene utilizzato LACP e le schede possono essere collegate anche a switch diversi, purché facciano parte della stessa rete.

Va infine deciso come gestire la rete dell’host. Se scegliete di condividerla, l’host utilizzerà una vNIC collegata al virtual switch, esattamente come una VM. È un dettaglio che influisce direttamente su come progettate separazione dei traffici e VLAN.

Scenario di riferimento

Lo scenario da cui partiamo è volutamente semplice. L’host Hyper-V dispone di quattro schede di rete fisiche identiche, tutte collegate alla stessa rete e senza alcuna configurazione particolare. Non è presente NIC Teaming, non ci sono virtual switch già creati e le interfacce sono ancora gestite direttamente dal sistema operativo.

In questa fase le schede sono semplici NIC “stand-alone”. Ognuna è visibile tra le connessioni di rete di Windows e, se necessario, potrebbe avere una propria configurazione IP. Dal punto di vista di Hyper-V, però, non esiste ancora alcun legame con il networking virtuale.

Figura 1: Situazione iniziale: quattro schede di rete fisiche identiche, senza NIC Teaming e senza virtual switch configurati

Creazione dello switch SET da PowerShell

Partiamo dall’idea più semplice: avete 4 NIC fisiche identiche, e volete creare uno switch esterno che le inglobi tutte in Switch Embedded Teaming. Con PowerShell è una riga, ma conviene farlo con un minimo di metodo, così sapete sempre cosa state toccando.

Per prima cosa identificate le schede che userete (nomi e stato):

A questo punto create il virtual switch usando tutte e quattro le NIC. Nell’esempio sotto lo switch si chiama vSwitch-SET e le schede si chiamano Ethernet, Ethernet 2, Ethernet 3, Ethernet 4:

Con -EnableEmbeddedTeaming $true state dicendo esplicitamente a Hyper-V che quello switch deve usare SET.
Con -AllowManagementOS $true permettete all’host di usare lo switch creando la relativa vNIC di management (la scelta più comune in lab e in molti ambienti reali, poi eventualmente si rifinisce con VLAN/QoS).

Il parametro -MinimumBandwidthMode Weight è fondamentale in scenari di converged networking. La modalità Weight definisce una QoS basata su pesi relativi tra le vNIC ed è la modalità consigliata da Microsoft per questo tipo di configurazioni. Questo parametro deve essere specificato al momento della creazione dello switch: se viene omesso, Hyper-V inizializza lo switch in modalità Absolute e, una volta creato, si rimane vincolati a quella scelta.

Definire correttamente la modalità QoS fin dall’inizio evita la necessità di ricreare lo switch in seguito e consente di utilizzare senza limitazioni i parametri MinimumBandwidthWeight sulle vNIC dell’host e delle macchine virtuali.

Figura 2: Creazione dello switch SET da PowerShell

Verifica dello switch SET

Dopo la creazione dello switch, la prima cosa da fare è verificare cosa Hyper-V ha realmente configurato. Il comando Get-VMSwitch -Name “vSwitch-SET” | Format-List in formato esteso è fondamentale, perché vi permette di capire se state davvero lavorando con Switch Embedded Teaming e quali NIC sono state inglobate.

L’elemento chiave da controllare è EmbeddedTeamingEnabled, che deve risultare impostato su True. È anche utile osservare NetAdapterInterfaceDescriptions, dove vengono elencate tutte le schede fisiche associate allo switch: in questo scenario vedete chiaramente le quattro NIC che avete assegnato.

Un altro parametro interessante è AllowManagementOS. Se è impostato su True, significa che l’host utilizza una vNIC collegata allo switch. Questo è il comportamento più comune, ma è bene ricordare che da questo momento l’host non comunica più direttamente tramite le schede fisiche, bensì attraverso un’interfaccia virtuale.

Questa schermata è importante anche per un altro motivo: rende evidente che non esiste alcun “team” visibile. Non troverete un oggetto di teaming separato né riferimenti a LBFO. Tutto è inglobato nel virtual switch ed è Hyper-V a gestire internamente la distribuzione del traffico sulle NIC fisiche.

Figura 3: Verifica dello switch SET appena creato tramite PowerShell

Cosa cambia nelle interfacce di rete

Dopo la creazione dello switch SET, le quattro schede fisiche sono ancora presenti, ma ora risultano gestite da Hyper-V e non sono più il punto in cui configurare la rete.

La vera interfaccia utilizzata dall’host è vEthernet (vSwitch-SET). È questa vNIC che eredita il ruolo di interfaccia di management e su cui, da questo momento in poi, vanno configurati indirizzi IP, VLAN e qualsiasi altra impostazione di rete dell’host.

Le NIC fisiche continuano a trasportare il traffico, ma in modo completamente trasparente. Non hanno più una configurazione propria e non vanno toccate: tutto passa dal virtual switch, che distribuisce i flussi sulle quattro interfacce in base alle logiche interne di SET.

Questo è uno dei punti chiave da capire quando si lavora con SET. Se provate a “ragionare come con LBFO” e cercate di configurare le schede fisiche, state andando nella direzione sbagliata. Con SET il virtual switch è l’unico punto di controllo.

NOTA: LBFO è l’acronimo di Load Balancing and Failover ed è il meccanismo di NIC Teaming tradizionale introdotto da Microsoft a partire da Windows Server 2012. Con LBFO il teaming delle schede di rete viene creato a livello di sistema operativo, prima di Hyper-V.

Figura 4: Cosa cambia nelle interfacce di rete

Anche se la creazione dello switch è avvenuta tramite PowerShell, una verifica dal Virtual Switch Manager aiuta a chiarire ulteriormente il comportamento di SET.

Aprendo le proprietà dello switch si nota subito che non è possibile modificare o selezionare singole schede di rete. Lo switch risulta associato al Microsoft Hyper-V Network Adapter (io sto usando la nested virtualization nel mio lab) e non a una NIC fisica specifica. Questo è coerente con il modello SET: il teaming è interno allo switch e non esiste un legame diretto, visibile o modificabile, con una singola interfaccia.

Un altro dettaglio interessante è che molte opzioni risultano non modificabili. Non è un limite dello strumento grafico, ma una conseguenza diretta dell’architettura di SET. Alcune scelte, come l’uso di SR-IOV o il tipo di connessione, possono essere fatte solo in fase di creazione dello switch e non successivamente.

Questa schermata è utile soprattutto per confermare che lo switch esiste ed è operativo, ma la configurazione reale e il controllo fine restano demandati a PowerShell. È un aspetto coerente con l’evoluzione di Hyper-V, dove le funzionalità più avanzate sono pensate per essere gestite principalmente via riga di comando. E so che questo non a tutti piace…

Figura 5: Verifica grafica dello switch SET dal Virtual Switch Manager di Hyper-V

Come SET gestisce il traffico

Con SET il bilanciamento del traffico è gestito direttamente dal virtual switch e non è configurabile come avveniva con LBFO. Ogni flusso viene assegnato a una delle NIC fisiche e rimane su quella scheda per tutta la durata della comunicazione.

Il bilanciamento diventa efficace quando sono presenti più flussi contemporanei, tipicamente generati da più macchine virtuali.

In caso di guasto di una NIC, il traffico viene riallocato automaticamente sulle schede rimanenti. Per l’host e per le VM il failover è trasparente.

Algoritmi di bilanciamento in SET

Con Switch Embedded Teaming è possibile intervenire sull’algoritmo di bilanciamento del traffico tramite PowerShell. Le opzioni realmente rilevanti sono Dynamic e HyperVPort.

L’algoritmo Dynamic è la scelta consigliata nella maggior parte degli scenari. Combina un bilanciamento basato sui flussi con la possibilità di ridistribuire il traffico nel tempo, evitando che una singola NIC rimanga sovraccarica mentre altre restano inutilizzate. È l’opzione più flessibile e adatta a host con molte VM e carichi variabili.

L’algoritmo HyperVPort, che è quello predefinito, assegna invece ogni macchina virtuale (o vNIC) a una specifica scheda fisica. Tutto il traffico generato da quella VM passa sempre dalla stessa NIC. È un comportamento più prevedibile, ma meno efficiente in presenza di carichi sbilanciati.

Per verificare quale algoritmo di bilanciamento è attualmente in uso su un team SET, potete utilizzare il seguente comando:

L’output mostra, tra le altre informazioni, il valore di LoadBalancingAlgorithm, che può essere come abbiamo già detto Dynamic o HyperVPort.

In questo caso l’algoritmo configurato è HyperVPort, quindi ogni macchina virtuale (o vNIC) viene mappata in modo statico su una specifica scheda fisica. È una scelta legittima, ma meno flessibile rispetto a Dynamic.

Per modificare l’algoritmo, è sufficiente usare Set-VMSwitchTeam. Il cambio è immediato e non richiede la ricreazione dello switch.

Non è necessario riavviare l’host o le macchine virtuali. Il virtual switch applica la nuova logica di bilanciamento in modo trasparente.

NOTA: Con il comando Get-VMSwitchTeam -Name “vSwitch-SET” potete anche verificare quali schede fisiche sono associate al SET

Figura 6: Verifica dell’algoritmo di bilanciamento configurato sul team SET tramite PowerShell

Converged networking con Switch Embedded Teaming

Una volta creato il virtual switch con SET, il passo successivo naturale è sfruttarlo per implementare un converged networking. L’idea è semplice: utilizzare un unico switch virtuale, basato su più schede fisiche, e separare i diversi tipi di traffico a livello logico, invece che fisico.

Con SET questo modello funziona particolarmente bene, perché il virtual switch è già il punto centrale di tutto il traffico. Le schede fisiche diventano puro trasporto e la gestione avviene tramite vNIC collegate allo switch, sia per le macchine virtuali sia per l’host.

Nel caso dell’host Hyper-V, il converged networking si realizza creando più vNIC di management, ognuna dedicata a un ruolo specifico: rete di management, Live Migration, traffico di storage (tipicamente SMB), traffico di cluster. Tutte queste interfacce virtuali insistono sullo stesso switch SET e condividono la stessa fabric fisica.

La separazione dei traffici avviene tramite VLAN, assegnate alle singole vNIC, e tramite QoS, che permette di dare priorità ai flussi più critici in caso di congestione. Dal punto di vista operativo, questo approccio riduce drasticamente il numero di schede fisiche necessarie e rende la configurazione più coerente e replicabile su più host.

È importante sottolineare che, in un modello converged, non si configurano mai le NIC fisiche. Tutto avviene sulle vNIC: indirizzi IP, gateway, VLAN, priorità. Le schede fisiche restano completamente astratte e vengono gestite dal virtual switch, che si occupa di distribuire il traffico sulle interfacce disponibili. L’ho già scritto diverse volte

Creazione delle vNIC per il converged networking

Partendo dallo switch SET già creato, il converged networking sull’host Hyper-V si realizza aggiungendo più interfacce virtuali di management, ognuna con un ruolo ben preciso. In questo modo tutti i traffici condividono la stessa fabric fisica, ma restano separati dal punto di vista logico.

Se lo switch è stato creato consentendo l’uso da parte del Management OS, l’host dispone già di una vNIC collegata allo switch. È buona pratica rinominarla, così da renderne subito chiaro il ruolo:

Rename-NetAdapter -Name “vEthernet (vSwitch-SET)” -NewName “vEthernet (Mgmt)”

A questo punto possiamo creare le altre vNIC necessarie. In uno scenario tipico aggiungiamo una vNIC per Live Migration, una per lo storage (SMB) e, se l’host fa parte di un cluster, una per il traffico di cluster.

Da questo momento l’host dispone di più interfacce virtuali, tutte collegate allo stesso switch SET. È su queste vNIC che andremo a configurare VLAN, indirizzi IP e, se necessario, policy di QoS. Le schede fisiche restano completamente fuori da qualsiasi configurazione.

Figura 7: Creazione delle vNIC per il converged networking

Separazione dei traffici con VLAN e indirizzamento IP

Una volta create le vNIC, il passo successivo è separare logicamente i diversi tipi di traffico. In un modello converged questo avviene quasi sempre tramite VLAN, lasciando allo switch fisico il semplice compito di trasportarle.

Ogni vNIC dell’host viene associata alla VLAN corretta. Nell’esempio seguente utilizziamo VLAN diverse per management, cluster, storage e Live Migration:

È importante ricordare che, in questo scenario, le porte dello switch fisico devono essere configurate in trunk e consentire il passaggio di tutte le VLAN utilizzate. SET non richiede configurazioni particolari lato switch, ma le VLAN devono ovviamente essere raggiungibili.

A questo punto si passa all’indirizzamento IP. Anche qui la regola è semplice: IP e gateway solo sulle vNIC, mai sulle schede fisiche. Di norma, gateway e DNS vengono configurati esclusivamente sulla vNIC di management; le reti dedicate restano senza gateway.

Con questa configurazione l’host utilizza un’unica fabric fisica per tutti i traffici, ma ogni flusso rimane isolato e facilmente identificabile.

    Figura 8: Separazione dei traffici con VLAN e indirizzamento IP

QoS di base nel converged networking

In uno scenario di converged networking, la QoS serve a gestire i momenti di congestione, non a limitare artificialmente la banda. L’obiettivo è evitare che carichi molto intensivi, come lo storage o le Live Migration, saturino il link e penalizzino traffici più critici, come il management o il cluster.

Con SET la QoS si applica alle vNIC, non alle schede fisiche. Questo è coerente con tutto il modello: il virtual switch è il punto di controllo e le NIC fisiche restano trasparenti.

L’approccio più semplice è basato sui MinimumBandwidthWeight. Non si imposta una velocità massima, ma una priorità relativa tra le interfacce quando lo switch è sotto carico. Ad esempio, è normale assegnare un peso più alto allo storage e alle Live Migration, e più basso al management:

In condizioni normali, senza congestione, tutti i traffici possono usare liberamente la banda disponibile. I pesi entrano in gioco solo quando più flussi competono per le stesse risorse (in caso di congestione del virtual switch). I valori di MinimumBandwidthWeight sono pesi relativi. La loro somma non deve fare 100 e non rappresenta una percentuale di banda.

Una QoS semplice e coerente è spesso sufficiente. L’importante è che sia applicata in modo chiaro e replicabile su tutti gli host, senza introdurre eccezioni difficili da gestire nel tempo.

I valori di MinimumBandwidthWeight assegnati alle vNIC possono essere verificati tramite PowerShell interrogando le interfacce di rete del Management OS.

Figura 9: QoS di base nel converged networking

Condivisione dello switch tra host e macchine virtuali

In una configurazione basata su Switch Embedded Teaming è del tutto normale utilizzare lo stesso virtual switch sia per l’host Hyper-V sia per le macchine virtuali. Non si tratta di una forzatura né di una configurazione “ibrida”, ma del modello di riferimento su cui si basa il converged networking.

Ovviamente nessuno vi vieta di creare del SET dedicati solo alle VM

L’host accede allo switch tramite una o più vNIC, utilizzate per il traffico di management e, se necessario, per altri ruoli come storage o Live Migration. Le macchine virtuali, invece, si collegano allo stesso switch con le proprie schede di rete virtuali. Dal punto di vista fisico tutto il traffico passa dalla stessa fabric, ma questo non significa che host e VM condividano la stessa rete logica.

La separazione avviene infatti a livello di scheda di rete, tramite VLAN e, quando serve, QoS. Ogni vNIC dell’host può essere associata a una VLAN diversa, così come ogni macchina virtuale può utilizzare la propria VLAN. Lo switch diventa quindi un punto di aggregazione comune, mentre l’isolamento dei traffici resta completo e controllato.

La configurazione va fatta macchina per macchina, perché la VLAN non è una proprietà dello switch ma della scheda di rete della singola VM. È una distinzione importante da tenere a mente: lo switch fornisce solo il punto di collegamento, mentre l’isolamento del traffico viene definito a livello di adapter virtuale.

Questa operazione può essere eseguita senza problemi anche dal wizard grafico di creazione della macchina virtuale. Durante la creazione della VM si sceglie semplicemente il virtual switch a cui collegarla; la VLAN non viene impostata in quella fase. Una volta completata la procedura, è sufficiente aprire le impostazioni della VM, selezionare la scheda di rete e configurare il VLAN ID desiderato.

Figura 10: Configurazione della VM per l’utilizzo dello switch SET

Considerazioni operative e best practice

A questo punto il converged networking è completo e funzionante. Prima di chiudere la configurazione, vale la pena fissare alcuni concetti chiave che evitano problemi nel tempo.

La prima regola è non mescolare modelli. Con SET e converged networking non ha senso mantenere NIC dedicate “per sicurezza” o configurazioni ibride. Tutto deve passare dal virtual switch e dalle vNIC. Se iniziate a fare eccezioni, la configurazione diventa difficile da leggere e ancora più difficile da mantenere.

La seconda riguarda il gateway. In quasi tutti gli scenari il gateway va configurato solo sulla vNIC di management. Aggiungerlo anche sulle reti di storage, cluster o Live Migration porta solo a routing ambiguo e comportamenti imprevedibili.

Per quanto riguarda la QoS, conviene restare conservativi. Meglio partire con pesi semplici e sensati, piuttosto che introdurre limiti aggressivi. In ambienti converged, la QoS serve a garantire priorità in caso di congestione, non a “strozzare” il traffico.

Un altro punto spesso sottovalutato è la coerenza tra host. In cluster Hyper-V, tutti gli host dovrebbero avere:

• lo stesso numero di vNIC
• gli stessi nomi
• le stesse VLAN
• la stessa logica di QoS

Questo rende più semplice il troubleshooting e riduce drasticamente gli errori operativi.

Infine, ricordate che il converged networking è una scelta architetturale. Funziona molto bene nella maggior parte degli scenari, ma non è obbligatorio usarlo ovunque. In ambienti con requisiti particolari (storage estremamente sensibile o reti fisicamente isolate) può ancora avere senso separare le fabric. L’importante è che la scelta sia consapevole, non dettata dall’abitudine.

Conclusioni

Switch Embedded Teaming rappresenta oggi il modello di riferimento per il networking in ambienti Hyper-V. Spostando il teaming all’interno del virtual switch, SET semplifica l’architettura, riduce la complessità operativa e si integra in modo naturale con il converged networking.

Rispetto a LBFO, l’approccio è più lineare e coerente: le schede fisiche diventano puro trasporto, mentre il controllo del traffico avviene tramite vNIC, VLAN e QoS. Questo rende la configurazione più prevedibile e facilmente replicabile, sia su host singoli sia in scenari più articolati.

Una volta compreso il modello, SET permette di progettare infrastrutture Hyper-V più pulite e moderne, evitando configurazioni ibride e soluzioni legacy che nel tempo diventano difficili da mantenere.