Limite di banda in Hyper‑V Replica su Windows Server 2022: cause reali, tuning e soluzioni pratiche

Molti amministratori di Windows Server 2022 notano che l’inizializzazione della replica Hyper‑V di una singola VM non supera ~1 Gb/s su link a 10 GbE (≈10 % della NIC). Qui spieghiamo perché succede, come verificarlo e quali azioni concrete adottare per sfruttare meglio la banda durante l’initial seed e oltre.

Indice

Contesto e sintomo

Scenario tipico osservato su host Hyper‑V fisici con storage e CPU adeguati:

Una singola VM in initial replication usa ~10 % della NIC:
- su 10 GbE il trasferimento si ferma a ≈ 1 Gb/s;
- su 1 GbE si ferma a ≈ 100 Mb/s.
Avviando più VM in parallelo, la banda cresce in modo additivo (2 VM ≈ 2 Gb/s, 3 VM ≈ 3 Gb/s, ecc.).
Copie di file “raw” host‑to‑host arrivano a 7 Gb/s o oltre, escludendo colli di bottiglia di storage/CPU/rete.
Comportamento confermato da più ambienti indipendenti.

Perché accade in Hyper‑V Replica

Hyper‑V Replica invia i blocchi modificati di ciascuna VM attraverso un unico flusso HTTP/S compresso. Durante l’initial seed quel flusso deve trasferire l’intera base dei dischi virtuali. Un singolo flusso TCP, anche su una LAN veloce e a bassa latenza, spesso non riesce a saturare interfacce multigigabit: tra finestra TCP effettiva, compressione lato host, calcolo dei checksum e limiti di parallelismo interni del motore di replica, si osserva con regolarità un plateau attorno a ~1 Gb/s per VM.

Fattori già verificati sul campo

Fattore valutato	Esito
Storage (lettura/scrittura dischi)	Non limitante: le copie “raw” saturano il canale.
Rete condivisa	Non satura: la NIC resta intorno al 10 % con una sola VM.
Antivirus o altri agent	Disattivati per prova; nessun miglioramento sostanziale.
Impostazioni di QoS	Nessuna policy attiva o priorità limitante.
Compressione Replica	Abilitata per impostazione predefinita; disabilitarla può aumentare il throughput per VM, ma il cap per flusso resta evidente.

Dove si forma il collo di bottiglia

Flusso TCP singolo per VM

Una sola sessione per VM significa che tutta l’inizializzazione passa da un unico congestion window. Su reti locali con RTT basso, Windows gestisce bene la scalabilità, ma in molte combinazioni di drivers, offload e parametri di autotuning il throughput per singolo flusso tende ad assestarsi vicino a 1 Gb/s. Non è un limite “hard” della rete, ma un comportamento derivante da come TCP e il motore di replica dialogano.

Limiti di parallelismo del motore di replica

Per impostazione predefinita Hyper‑V Replica mantiene un numero limitato di “transfer thread” tra host primario e replica. Il valore che lo governa è MaximumActiveTransfers (chiave di registro), non esposto nella GUI. Se lasciato al valore standard, il sistema tende a sfruttare bene la banda solo quando ci sono più VM che replicano in parallelo. Aumentare questo valore consente più flussi concorrenti e, quindi, maggiore banda aggregata durante l’initial seed.

CPU e compressione

La compressione riduce i byte in transito, ma costa CPU. A ~1 Gb/s un algoritmo tipo LZ77 può consumare un core fisico per VM. Se il server ha molti core liberi, lanciare più repliche in parallelo “scala” bene; il singolo flusso, però, resta vincolato. Disabilitare la compressione durante l’initial seed spesso sposta il collo di bottiglia dalla CPU alla rete e può far guadagnare 50–100 % per singola VM.

Strategie efficaci per aumentare il throughput

Azione	Come si fa	Effetto atteso
Aumentare la concorrenza di Hyper‑V Replica	Impostare la chiave `HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication\MaximumActiveTransfers` (DWORD) al numero di trasferimenti desiderati e riavviare il servizio VMMS. `reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" ^ /v MaximumActiveTransfers /t REG_DWORD /d 8 /f powershell -NoProfile -Command "Restart-Service vmms -Force"` Regola pratica: imposta un valore ≈ `banda disponibile (Gb/s) ÷ throughput medio per VM (Gb/s)`, poi affina con misure reali.	Più flussi simultanei → banda complessiva più alta durante l’initial seed.
Disabilitare la compressione per l’initial seed	Da PowerShell o durante la procedura guidata di abilitazione. `Set-VMReplication -VMName "NomeVM" -CompressionEnabled $false` Ricorda di riattivarla per la replica continua se il link è costoso o WAN.	Più throughput per VM (spendendo più rete). In molti ambienti si osservano 1,5–2 Gb/s per VM.
Ottimizzare il comportamento TCP	Verifica l’attuale profilo TCP e, se le policy aziendali lo consentono, prova un provider di congestione più adatto alle reti a bassa latenza ad alta velocità. Esempi: `netsh int tcp show global netsh int tcp show supplemental :: facoltativo, se supportato dal sistema e dopo test controllati netsh int tcp set supplemental template=internet congestionprovider=ctcp` Se il comando non è supportato o il sistema usa già un provider moderno, limita l’intervento alla misurazione. L’obiettivo è migliorare la crescita della finestra TCP nei primi secondi.	Miglior tempo di “ramp‑up” del flusso per VM su LAN a basso RTT.
Replica “seed” fuori banda	Esportare la VM su disco esterno e importarla sul nodo replica; al momento di abilitare la replica scegliere “Usa VM esistente come copia iniziale”. `Export-VM -Name "NomeVM" -Path "E:\Seed" Import-VM -Path "E:\Seed\NomeVM" poi: Enable-VMReplication con "Use existing VM as initial copy"` `</td> <td>Evita completamente il collo di bottiglia di rete su inizializzazioni multi‑TB.</td> </tr> <tr> <td>Dedicare una NIC alla replica</td> <td> <p>Isolare una porta fisica senza vSwitch/VMQ e assegnarla esclusivamente al traffico di replica (IP dedicato, esclusione QoS, nessun altro carico).</p> </td> <td>Elimina contese e sorprese QoS; non rimuove il limite per flusso, ma stabilizza le misure.</td> </tr>`

Procedura passo‑passo consigliata

Misura il baseline per ogni VM e per l’host:
- Measure-VMReplication per avere throughput e stima tempi;
- Performance Monitor: Network Interface\Bytes Total/sec; Processor\% Processor Time per vmms.exe e vmwp.exe coinvolti.
- Eventi Hyper‑V Replica per errori di ritrasmissione o time‑out.
Measure-VMReplication -VMName "NomeVM" | Format-Table -Auto
Aggiorna driver e firmware NIC, abilitando funzionalità moderne (RSS/RSC, checksum/LSO, Receive Queue). Verifica che RSS sia attivo e con coda sufficiente: netsh int tcp show global Get-NetAdapterAdvancedProperty -Name "Ethernet*" | Sort-Object Name
Valuta la compressione per l’initial seed. Se l’host ha CPU vicina al 60–80 % durante la replica, disabilita la compressione solo per il seed iniziale; su WAN o link contesi riattivala per la sincronizzazione incrementale.
Aumenta la concorrenza con MaximumActiveTransfers. Parti da un valore pari a 2–3 volte il numero di dischi virtuali che stai inizializzando in parallelo, poi affina: reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" ^ /v MaximumActiveTransfers /t REG_DWORD /d 10 /f powershell -NoProfile -Command "Restart-Service vmms -Force" Nota: la chiave è a livello host. Documenta il valore nei runbook di DR: in caso di reinstallazione del ruolo/host potresti doverla reimpostare.
Isola la replica su una NIC dedicata con IP statico e, se usi QoS a livello switch, crea una classe esplicita per la replica. Evita di competere con traffico VM‑to‑VM sullo stesso vSwitch.
Rivaluta e itera ogni cambiamento con Measure-VMReplication e PerfMon. In assenza di errori, il grafico di utilizzo NIC dovrebbe salire in modo apprezzabile con più trasferimenti attivi.

Come dimensionare il grado di parallelismo

Un modello pratico per l’initial seed:

Stima per‑VM: misura il throughput stabile di una singola VM (es. 1 Gb/s su 10 GbE).
Target host: definisci la banda che vuoi avvicinare (es. 7–9 Gb/s dei 10 Gb/s disponibili senza impattare altro carico).
Calcolo iniziale: MaximumActiveTransfers ≈ ceil(targetGbps ÷ perVMGbps). Con target 8 Gb/s e 1 Gb/s per VM → imposta 8.
Aggiusta in funzione di CPU, latenza disco, e presenza di altre repliche.

Scenario	Throughput per VM	Target host	Valore iniziale consigliato
10 GbE, LAN, compressione attiva	≈ 1 Gb/s	8 Gb/s	8
10 GbE, LAN, compressione disattiva	1,5–2 Gb/s	8 Gb/s	4–6
1 GbE, LAN	≈ 100 Mb/s	0,8 Gb/s	8
WAN, RTT > 5 ms, compressione attiva	forte variabilità	uso “best effort”	inizia da 4–6 e misura

Verifiche di rete e TCP consigliate

Autotuning della finestra ricezione: controlla il livello con netsh int tcp show global. Lascia “normal” salvo requisiti particolari.
Provider di congestione: verifica l’attuale provider. In molte installazioni recenti i provider moderni funzionano bene; in reti LAN molto “pulite” testare CTCP può dare vantaggi. Valuta con misure prima/dopo.
Offload NIC: mantieni abilitati LSO/LSO‑v2, checksum offload, RSS e valuta RSC a seconda del driver. Disabilitare indiscriminatamente gli offload spesso peggiora i risultati.
Jumbo frame: opzionale. Porta MTU coerente end‑to‑end (host, switch, storage) se intendi abilitarli; non forzano da soli l’incremento del throughput per flusso, ma riducono l’overhead CPU.

Quando il limite resta un vincolo

Poche VM molto grandi su 10 GbE: il modo più rapido è un seed offline oppure avviare più repliche in parallelo (impostando una concorrenza più alta).
Link WAN con RTT > 5 ms: la finestra TCP diventa col collo di bottiglia prima del “10 %”. Mantieni la compressione attiva e valuta tunnel/VPN che moltiplicano il numero di flussi.

Strumenti di diagnostica rapida

PowerShell # Stato e direzione della replica Get-VMReplication -VMName "NomeVM" | Format-List * Misura throughput stimato e tempi Measure-VMReplication -VMName "NomeVM" Abilita/Disabilita compressione Set-VMReplication -VMName "NomeVM" -CompressionEnabled $false Numero trasferimenti attivi a livello host (registro) reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" /v MaximumActiveTransfers
Performance Monitor
- Network Interface\Bytes Total/sec sulla NIC dedicata;
- Processor\% Processor Time su vmms.exe/vmwp.exe;
- TCPv4\Segments Retransmitted/sec per individuare ritrasmissioni.

Domande frequenti

La chiave MaximumActiveTransfers è supportata?
È una impostazione utilizzata dal motore di replica ma non esposta nella GUI. Impostarla correttamente permette di incrementare la parallelizzazione. Come per ogni parametro di basso livello, applica modifiche con cautela e monitora l’effetto su CPU, memoria e rete.

Aumentare il valore può essere controproducente?
Sì. Un valore eccessivo può causare competizione sullo storage o saturare la CPU (soprattutto con compressione attiva). Procedi a piccoli passi, misurando l’impatto su latenza VM I/O e carichi concorrenti.

Disabilitare la compressione è sicuro?
Sì per l’initial seed su LAN affidabili: riduci il lavoro CPU e guadagni throughput, al prezzo di più traffico. Per la replica continua su WAN la compressione è di norma consigliata.

È un bug di Windows Server 2022?
No: è un effetto “di design” della replica per VM con un solo flusso per inizializzazione. La rete e lo storage possono essere ottimi, ma il singolo stream raramente scala come un trasferimento file multistream.

Checklist operativa

Aggiorna firmware e driver NIC su entrambi gli host.
Verifica RSS/RSC/LSO attivi e coerenti.
Isola la replica su NIC dedicata e classe QoS esplicita.
Misura il baseline con Measure-VMReplication e PerfMon.
Valuta compressione: disattiva solo per l’initial seed su LAN.
Imposta MaximumActiveTransfers e riavvia VMMS.
Aumenta gradualmente la concorrenza finché la NIC si avvicina al target desiderato senza impattare le VM in produzione.
Documenta nel runbook di DR le impostazioni applicate; ricontrolla dopo aggiornamenti di ruolo/host.

Nota sui riferimenti

Le linee guida qui descritte si allineano con la documentazione tecnica ufficiale su ottimizzazioni e considerazioni di performance per Hyper‑V Replica, inclusi i consigli sull’aumento dei trasferimenti concorrenti e sull’uso o meno della compressione durante l’inizializzazione.

Conclusioni

Non esiste al momento un’impostazione ufficiale che “sblocchi” il cap apparente del ~10 % per singola VM durante l’initial seed su Windows Server 2022. Il limite nasce dalla combinazione di flusso TCP unico per VM, parallelismo interno contenuto e costo CPU della compressione. Le azioni che funzionano davvero sono tre:

Incrementare i trasferimenti concorrenti con MaximumActiveTransfers per sfruttare più flussi in parallelo;
Gestire con criterio la compressione (disabilitarla per il seed su LAN, riattivarla per la replica continua dove serve);
Ricorrere al seed offline per VM molto grandi o su link che non possono essere impattati.

Con un ciclo disciplinato di misurazione → modifica → misurazione, questi interventi permettono di avvicinarsi alla saturazione della rete in modo controllato, senza rischiare la coerenza dei log di replica né penalizzare i carichi in produzione.