• Guide, Sistemi Operativi
• 2 Febbraio 2026

Quando si parla di Hyper-V, il networking è spesso l’aspetto che viene configurato una volta e poi lasciato lì, finché non emergono problemi di performance, di isolamento o di sicurezza. Nella pratica quotidiana, però, sappiamo bene che la rete è uno dei componenti più critici di un’infrastruttura virtuale e che una configurazione superficiale prima o poi presenta il conto. Le funzionalità avanzate di virtual machine network non sono pensate per complicare le cose, ma per darvi strumenti concreti per governare scenari che vanno oltre il classico “una VM, una scheda, un vSwitch”.

Le funzionalità avanzate di virtual machine network di Hyper-V nascono proprio per rispondere a queste esigenze. Non sono opzioni “da laboratorio”, ma strumenti pensati per gestire infrastrutture reali, dove il traffico va controllato, le VM devono essere isolate correttamente e le prestazioni non possono essere lasciate al caso. Il problema è che spesso queste funzionalità vengono ignorate o utilizzate senza una reale comprensione di come funzionano e di quali effetti producono sull’host e sulle macchine virtuali.

In questo articolo entreremo nel merito del networking avanzato delle VM in Hyper-V, cercando di capire cosa c’è dietro le principali impostazioni e quando ha senso utilizzarle. L’obiettivo non è elencare tutte le opzioni disponibili, ma fornire una chiave di lettura pratica, utile a chi gestisce ambienti Hyper-V in produzione e vuole evitare configurazioni approssimative o soluzioni adottate solo dopo la comparsa dei problemi.

Hyper-V advanced virtual machine network configuration

La creazione di virtual switch e il collegamento delle macchine virtuali in Hyper-V è solo il punto di partenza. In ambienti di produzione, questa configurazione di base difficilmente è sufficiente per gestire in modo efficace traffico, prestazioni e controllo della rete. Hyper-V mette infatti a disposizione una serie di funzionalità avanzate di networking che permettono di intervenire in modo più mirato sul comportamento delle schede di rete virtuali e dell’host.

Queste impostazioni avanzate consentono di migliorare l’efficienza nell’uso delle risorse, aumentare il controllo sul traffico di rete e rispondere meglio a scenari complessi, tipici di infrastrutture con molte macchine virtuali attive. Nei paragrafi successivi vedremo come funzionano alcune di queste funzionalità e in quali casi ha senso utilizzarle all’interno di un’infrastruttura Hyper-V.

VLAN ID

L’impostazione VLAN ID consente di associare la scheda di rete virtuale di una macchina Hyper-V a una specifica VLAN 802.1Q, permettendo così l’integrazione diretta delle macchine virtuali con la segmentazione della rete fisica. Abilitando questa opzione, tutto il traffico in uscita dalla vNIC viene marcato con il VLAN ID configurato, mentre il traffico in ingresso viene accettato solo se appartiene alla stessa VLAN.

Dal punto di vista operativo, l’utilizzo del VLAN ID a livello di scheda di rete virtuale è utile quando si vuole mantenere una separazione logica tra ambienti diversi, come reti di produzione, management o test, senza dover creare virtual switch dedicati per ogni VLAN. È però fondamentale che il virtual switch Hyper-V e la rete fisica sottostante siano correttamente configurati per gestire il traffico VLAN tagged; in caso contrario, la macchina virtuale non avrà connettività di rete.

In pratica, Hyper-V inserisce un tag VLAN all’interno del frame Ethernet, che identifica a quale VLAN appartiene quel traffico. Questo tag viene aggiunto prima che il pacchetto lasci la macchina virtuale e attraversi il virtual switch, e viene mantenuto fino a quando raggiunge un dispositivo di rete (virtuale o fisico) in grado di interpretarlo.

Figura 1: Configurazione del VLAN ID

Bandwidth Management

La funzionalità Bandwidth Management consente di controllare l’utilizzo della banda di rete da parte di una singola scheda di rete virtuale, permettendo di definire limiti minimi e massimi di throughput. In ambienti condivisi, dove più macchine virtuali utilizzano lo stesso virtual switch e la stessa interfaccia fisica, questa opzione permette di evitare che una VM possa saturare la banda disponibile a discapito delle altre.

Abilitando il Bandwidth Management è possibile impostare un valore di Minimum Bandwidth, che garantisce una quota minima di banda alla macchina virtuale, e un valore di Maximum Bandwidth, che limita il consumo massimo espresso in Mbps. In questo modo Hyper-V può gestire in modo più prevedibile il traffico di rete, soprattutto in scenari in cui alcune VM svolgono ruoli critici e altre generano traffico intenso ma non prioritario.

Figura 2: Bandwidth Management

Virtual Machine Queue (VMQ)

La Virtual Machine Queue (VMQ) è una funzionalità pensata per migliorare le prestazioni di rete delle macchine virtuali riducendo il carico sulla CPU dell’host. In assenza di VMQ, l’host Hyper-V deve gestire direttamente i flussi di rete destinati alle diverse VM, con un impatto evidente sull’utilizzo del processore in presenza di traffico elevato.

Abilitando VMQ, il traffico in ingresso viene indirizzato in modo più efficiente verso le code associate alle singole macchine virtuali, riducendo il lavoro della CPU e migliorando le prestazioni complessive. Il beneficio è più evidente in ambienti con molte VM e carichi di rete significativi.

VMQ può essere gestita anche tramite PowerShell, ad esempio a livello di virtual switch o dell’adapter di gestione dell’host, utilizzando il cmdlet Set-VMNetworkAdapter, che consente di abilitarla, disabilitarla o modificarne il comportamento in base alle esigenze dell’ambiente. Ad esempio, potete utilizzare il comando

Figura 3: Virtual Machine Queue (VMQ)

IPsec Task Offload

L’IPsec Task Offload consente a Hyper-V di delegare alla scheda di rete fisica l’elaborazione delle operazioni crittografiche legate a IPsec. Senza questa funzionalità, tutte le operazioni di cifratura e decifratura del traffico IPsec vengono gestite dalla CPU dell’host, con un impatto diretto sulle prestazioni, soprattutto in scenari in cui il traffico protetto è elevato.

Abilitando l’offload, una parte significativa di questo carico viene spostata sull’hardware di rete, liberando risorse CPU che possono essere utilizzate dalle macchine virtuali o da altri servizi dell’host. Questo approccio è particolarmente utile in ambienti in cui IPsec viene utilizzato in modo estensivo, ad esempio per la protezione delle comunicazioni tra server o tra siti diversi.

Come per altre funzionalità avanzate, l’utilizzo di IPsec Task Offload ha senso solo se l’hardware e i driver di rete lo supportano correttamente. In caso contrario, è preferibile lasciare l’elaborazione a carico del sistema operativo, evitando configurazioni che non portano benefici concreti.

Il parametro Offloaded SA indica il numero massimo di Security Association IPsec che possono essere elaborate in hardware dalla scheda di rete quando è attivo l’IPsec Task Offloading. È un limite massimo: se l’hardware non è in grado di gestire tutte le associazioni, Hyper-V utilizza automaticamente l’elaborazione software. Nella maggior parte dei casi il valore predefinito è sufficiente.

Per abilitare la funzionalità tramite PowerShell, potete utilizzare il comando:

Figura 4: IPsec Task Offload

SR-IOV

Single Root I/O Virtualization (SR-IOV) è una tecnologia che consente a una macchina virtuale di accedere in modo più diretto alle risorse della scheda di rete fisica, riducendo l’intermediazione dello stack di rete virtuale di Hyper-V. Il risultato è una latenza inferiore e prestazioni di rete più elevate, particolarmente utili in scenari ad alte prestazioni.

In pratica, Single Root I/O Virtualization (SR-IOV) serve a far “saltare” una parte dello stack di rete virtuale di Hyper-V e permettere a una macchina virtuale di usare direttamente la scheda di rete fisica.

Normalmente il traffico di una VM passa dal virtual switch di Hyper-V, viene elaborato dall’host e poi inviato alla NIC. Con SR-IOV, invece, la scheda di rete fisica espone delle funzioni virtuali che vengono assegnate direttamente alle VM. Il traffico di rete entra ed esce dalla macchina virtuale senza passare dal vSwitch, con una riduzione significativa di latenza e overhead CPU.

L’utilizzo di SR-IOV richiede il supporto a livello di hardware, BIOS/UEFI e sistema operativo, e comporta alcune limitazioni nella gestione della rete virtuale. Proprio per questo motivo non è una funzionalità da abilitare indiscriminatamente, ma va valutata in base alle reali esigenze delle macchine virtuali e al tipo di carico di lavoro.

In ambienti specifici, come quelli che richiedono throughput elevato o latenza minima, SR-IOV può rappresentare una soluzione efficace. In altri casi, le funzionalità di networking tradizionali di Hyper-V risultano più che sufficienti e più semplici da gestire.

Qui di seguito alcuni comandi utili per verificare ed abilitare la funzionalità di SR-IOV sulle schede delle VM:

Figura 5: Single Root I/O Virtualization (SR-IOV) deve essere abilitato sul vSwitch al momento della creazione dello stesso

Figura 6: Single Root I/O Virtualization (SR-IOV) abilitata sulla scheda di rete della VM

Protezione e monitoraggio del traffico di rete

Hyper-V include anche diverse funzionalità pensate per aumentare il controllo e la sicurezza del traffico di rete delle macchine virtuali. Tra queste rientrano DHCP Guard, Router Guard, Protected Network e Port Mirroring, strumenti che permettono di prevenire configurazioni errate, intercettare comportamenti anomali o monitorare il traffico a fini di troubleshooting.

Queste impostazioni operano direttamente a livello della scheda di rete virtuale della VM e consentono di intervenire in modo puntuale senza modificare l’infrastruttura di rete fisica. Utilizzate correttamente, aiutano a rendere l’ambiente Hyper-V più prevedibile e controllabile, soprattutto in contesti multi-tenant o con requisiti di sicurezza più stringenti.

DHCP Guard

DHCP Guard serve a impedire che una macchina virtuale possa rispondere alle richieste DHCP sulla rete. In un ambiente Hyper-V è una protezione semplice ma efficace contro errori di configurazione o comportamenti indesiderati, come una VM che avvia accidentalmente un servizio DHCP e inizia a distribuire indirizzi IP non corretti.

Dal punto di vista operativo, DHCP Guard va abilitato su tutte le macchine virtuali che non devono svolgere il ruolo di server DHCP. In questo modo si evita che una singola VM possa compromettere il funzionamento della rete virtuale, soprattutto in ambienti condivisi o con molte macchine gestite da team diversi. L’impatto sulle prestazioni è trascurabile e il beneficio in termini di stabilità è immediato.

Per abilitare la funzionalità tramite PowerShell, potete utilizzare il comando:

Figura 7: Abilitazione del DHCP Guard

MAC Address Spoofing

Il MAC Address Spoofing consente a una macchina virtuale di inviare traffico di rete utilizzando indirizzi MAC diversi da quello assegnato alla sua scheda di rete virtuale. Per impostazione predefinita, Hyper-V blocca questo comportamento per evitare che una VM possa impersonarne un’altra sulla rete.

Dal punto di vista operativo, questa funzionalità diventa necessaria in scenari specifici, ad esempio quando all’interno di una macchina virtuale vengono eseguite altre VM o servizi che generano traffico con MAC differenti. Senza MAC Address Spoofing abilitato, questo traffico viene semplicemente scartato dal virtual switch.

Un caso tipico è quello della nested virtualization: quando eseguite Hyper-V (o un altro hypervisor) all’interno di una macchina virtuale, le VM “nidificate” generano traffico con indirizzi MAC propri. In questo scenario, l’abilitazione del MAC Address Spoofing sulla VM “host” è un prerequisito indispensabile affinché la connettività di rete funzioni correttamente.

L’abilitazione è semplice e può essere gestita direttamente sulla scheda di rete virtuale:

Come per le altre funzionalità avanzate, il MAC Address Spoofing va abilitato solo quando necessario. In ambienti standard non è richiesto e lasciarlo disabilitato contribuisce a mantenere un livello di isolamento e sicurezza più elevato all’interno della rete virtuale.

Figura 8: Abilitazione del MAC Address spoofing

Router Guard

Router Guard ha un obiettivo simile a quello del DHCP Guard, ma applicato al routing. Questa funzionalità impedisce a una macchina virtuale di annunciare se stessa come router sulla rete, bloccando l’invio di messaggi di routing non autorizzati. È una protezione utile per evitare che una VM, intenzionalmente o per errore, inizi a instradare traffico che non le compete.

Operativamente, Router Guard è consigliabile su tutte le VM che non svolgono funzioni di routing o firewalling. In questo modo si riduce il rischio di alterare i percorsi di rete e si mantiene un comportamento prevedibile dell’infrastruttura virtuale, senza dover intervenire sulla rete fisica.

Per abilitare la funzionalità tramite PowerShell, potete utilizzare il comando:

Figura 9: Abilitazione del Router guard

Protected Network

La funzionalità Protected Network è pensata per migliorare la resilienza delle macchine virtuali in caso di problemi di connettività. Quando una VM è collegata a una rete protetta e l’host perde la connettività di rete, Hyper-V può intervenire automaticamente per gestire la situazione, ad esempio spostando la VM su un altro host in un contesto di cluster.

Dal punto di vista operativo, Protected Network è particolarmente utile in ambienti clusterizzati, dove la continuità del servizio è un requisito fondamentale. Abilitandola sulle VM critiche, si aggiunge un ulteriore livello di protezione contro fault di rete che potrebbero altrimenti causare downtime o disservizi.

Per abilitare la funzionalità tramite PowerShell, potete utilizzare il comando:

Figura 10: Abilitazione della Protected nertwork

Port Mirroring

Port Mirroring consente di copiare il traffico di rete di una macchina virtuale verso un’altra VM designata come destinazione. Questa funzionalità è estremamente utile per attività di troubleshooting, analisi del traffico o integrazione con sistemi di monitoraggio e sicurezza.

In pratica, una VM viene configurata come sorgente del traffico e un’altra come destinazione. Quest’ultima può eseguire strumenti di analisi o di ispezione senza interferire con il funzionamento della macchina monitorata. Port Mirroring permette quindi di osservare cosa accade sulla rete virtuale senza dover modificare la topologia o intervenire sulla rete fisica.

Per abilitare la funzionalità tramite PowerShell, potete utilizzare i comandi:

Figura 11: Configurazione del Port Mirroring sulle macchine virtuali

Perché il Port Mirroring funzioni correttamente in Hyper-V è necessario che sul virtual switch sia abilitata l’estensione Microsoft NDIS Capture. Questa estensione consente al virtual switch di intercettare e duplicare il traffico di rete delle macchine virtuali configurate come sorgente, rendendolo disponibile alla VM di destinazione. Se l’estensione non è attiva, la configurazione del mirroring a livello di scheda di rete virtuale non produce alcun effetto. Prima di utilizzare il Port Mirroring è quindi buona pratica verificare, dal Virtual Switch Manager, che l’estensione Microsoft NDIS Capture sia abilitata sullo switch interessato.

Figura 12: Estensione Microsoft NDIS Capture attiva sul virtual switch

Sulla VM VMMonitor, sulla scheda di rete che userete come Destination per il Port Mirroring, conviene disabilitare tutti i protocolli e lasciare attivo solo Npcap Packet Driver (NPCAP). In questo modo l’interfaccia viene utilizzata esclusivamente per la cattura dei pacchetti in Wireshark, evitando che Windows provi a usare quella scheda per traffico normale (client Microsoft Networks, IPv4/IPv6, QoS, ecc.) e riducendo rumore e possibili interferenze durante l’analisi.

Figura 13: Configurazione della scheda di rete su VMMonitor

Avviando Wireshark su VMMonitor è possibile verificare in tempo reale il traffico generato da VM01, confermando il corretto funzionamento del Port Mirroring e l’efficacia dell’approccio per attività di troubleshooting e analisi senza impattare sulle macchine monitorate.

Figura 14: Verifica del Port Mirroring con Wireshark – Avvio del monitoraggio

Su VMMonitor, Wireshark cattura i pacchetti replicati sull’interfaccia dedicata al mirroring, mostrando sia le richieste che le risposte ICMP, con indirizzi IP sorgente e destinazione coerenti con il traffico generato da VM01.

Figura 15: : Verifica del Port Mirroring con Wireshark – Il monitoraggio avviene con successo

NIC Teaming

L’opzione NIC Teaming consente di permettere alla macchina virtuale di creare un team di schede di rete all’interno del sistema operativo guest. A differenza del teaming configurato sull’host Hyper-V, questa funzionalità è utile in scenari specifici in cui si vuole gestire direttamente dal guest l’aggregazione di banda o la ridondanza delle interfacce di rete. Va utilizzata con attenzione, perché se il teaming viene creato nel guest e questa opzione viene successivamente disabilitata, la macchina virtuale può perdere connettività. Nella maggior parte degli ambienti standard il teaming a livello di host rimane la scelta preferibile.

Figura 16: Opzione Nic Teaming

Device naming

La funzionalità Device naming consente a Hyper-V di propagare nel sistema operativo guest il nome assegnato alla scheda di rete virtuale (vNIC) a livello di host. Questo è particolarmente utile in macchine virtuali con più interfacce di rete, dove distinguere le schede solo in base all’ordine di enumerazione o al MAC address rende più complessa la gestione e il troubleshooting.

È importante chiarire che Hyper-V Manager non permette di rinominare graficamente il nome interno della vNIC. Il nome visualizzato nell’interfaccia grafica (“LAN”, “iSCSI”, ecc.) indica il virtual switch a cui la scheda è collegata, non il nome della vNIC stessa. Per assegnare un nome reale alla scheda di rete virtuale, che possa poi essere propagato nel guest, è necessario utilizzare PowerShell.

La procedura operativa prevede quindi due passaggi: prima si rinomina la vNIC tramite il cmdlet Rename-VMNetworkAdapter, poi si abilita il device naming. Entrambe le operazioni si possono fare anche a macchina virtuale accesa, ma le modifiche saranno effettive solo dopo il riavvio del sistema operativo guest.

In ambienti strutturati, l’uso combinato di naming coerente delle vNIC e Device naming semplifica notevolmente la gestione di scenari con traffico separato per ruoli diversi, come management, backup o port mirroring.

Quando una macchina virtuale dispone di più schede di rete collegate allo stesso virtual switch, Hyper-V assegna per default lo stesso nome interno a tutte le vNIC. In questi casi, per rinominare correttamente le interfacce ed utilizzare il Device Naming, è necessario identificarle tramite MAC address e intervenire con PowerShell.

Figura 17: Individuazione del MAC address delle schede di rete

Figura 18: Cambio nome delle schede di rete

Figura 19: Cambio nome effettuato con successo

Figura 20: Abilitazione del Device Naming

Una volta rinominate le vNIC lato Hyper-V e abilitato il Device Naming, l’effetto nel sistema operativo guest non è immediatamente visibile nell’elenco delle connessioni di rete, che continuano a essere mostrate come Ethernet ed Ethernet 2. Il nome configurato sull’host viene invece propagato come proprietà dell’adapter, ed è consultabile nelle impostazioni avanzate della scheda di rete, nel campo Hyper-V Network Adapter Name. In questo modo è possibile verificare con certezza a quale vNIC Hyper-V corrisponde ciascuna interfaccia del guest, ad esempio distinguendo chiaramente una scheda dedicata alla rete aziendale da una utilizzata esclusivamente per il port mirroring.

Questo comportamento è coerente con il design di Hyper-V: il Device Naming non ha l’obiettivo di rinominare graficamente le connessioni di rete nel sistema operativo, ma di mantenere un collegamento logico e persistente tra la configurazione dell’host e le interfacce viste dal guest. Nei contesti con più schede di rete, questa informazione diventa particolarmente utile per evitare ambiguità, ridurre errori di configurazione e semplificare le attività di troubleshooting.

Figura 21: Proprietà avanzate della scheda di rete: Hyper-V Network Adapter Name

Conclusioni

Il networking in Hyper-V offre molte più possibilità rispetto alla semplice creazione di un virtual switch. Le funzionalità avanzate delle schede di rete virtuali permettono di intervenire in modo mirato su prestazioni, sicurezza e visibilità del traffico, a patto di conoscerne il reale funzionamento e i limiti operativi.

Tecnologie come VMQ, offload hardware, Port Mirroring e Device Naming non vanno viste come opzioni da abilitare indiscriminatamente, ma come strumenti da usare quando il contesto lo richiede. Comprendere cosa fanno davvero, e soprattutto cosa non fanno, consente di evitare configurazioni errate e di progettare ambienti Hyper-V più ordinati, prevedibili e semplici da gestire nel tempo.

In scenari di produzione, un approccio consapevole al networking avanzato delle macchine virtuali fa spesso la differenza tra un’infrastruttura che funziona “per caso” e una che funziona perché è stata progettata correttamente.