Live Migration on the Wrong Network: The Silent Hyper-V Pitfall
Live Migration quietly using the wrong network is the single most common finding in CloudLabs Hyper-V Cluster Health Checks. It is the kind of misconfiguration that does not fail, it just runs slow, competes with cluster heartbeats during patch windows, and produces incidents that look like switch problems when they are really mis-routed VM memory transfers.
This article walks through the three configuration layers, the PowerShell to verify the actual path being used, and the remediation we apply on every engagement.
1. The three configuration layers
Network selection for Live Migration runs across three independent configuration layers. We regularly find clusters where two are correct and the third silently breaks the whole thing.
Cluster network role. Each cluster network (subnet) has a Role: None, Cluster, or ClusterAndClient. The cluster only considers networks with role Cluster or ClusterAndClient for internal traffic, including Live Migration.
Cluster Live Migration priority. Inside the cluster object sits an ordered list of networks the cluster prefers for Live Migration. Set it through Set-ClusterParameter or through the GUI under Networks → Live Migration Settings.
Per-host VM Migration network list. Each Hyper-V host has its own VMMigrationNetwork list. That is what vmms actually uses to bind to a source IP when starting a migration. If the cluster says "use 10.10.20.0/24" but the host has no VMMigrationNetwork entry for that subnet, the host falls back to whichever interface responds, usually the management network.
2. What "wrong network" actually looks like
The classic symptoms in production:
- Migrations take 4 to 6 minutes where 30 to 45 seconds should be achievable. Usually because LM is going over a 1 GbE management network instead of the 25 GbE storage network.
- Cluster heartbeat drops during CAU runs. If LM and heartbeat share a NIC, big memory transfers can saturate the link and mark heartbeats as missing.
- Switch port utilisation on the management VLAN peaks at 90% plus during patching. Network ops notices and opens a ticket. The Hyper-V team makes no connection to LM.
- SMB Multichannel sessions in unexpected places. If LM is on SMB (default since WS2016) but has no clean RDMA path, it falls back to plain TCP-over-SMB on whatever interface is reachable.
The cluster is healthy in all these scenarios by standard monitoring criteria. Test-Cluster passes. Failover Cluster Manager is green. The only correlation is timing. That is precisely why this is a typical Hyper-V Cluster Health Check finding, not something reactive monitoring catches. See Hyper-V Cluster Health Check: Top 10 Issues We Find in 2026 for the wider pattern.
3. Verifying the path in use
Verification requires a live test. Inspecting configuration alone is not enough because the three layers interact in non-obvious ways. The procedure CloudLabs uses during a Health Check:
Step 1, snapshot all three configuration layers:
# Cluster networks and their roles
Get-ClusterNetwork |
Select-Object Name, Address, Role, AutoMetric, Metric |
Sort-Object Metric
# Cluster Live Migration priority
$lmNetworks = (Get-ClusterResourceType -Name 'Virtual Machine' |
Get-ClusterParameter -Name MigrationNetworkOrder).Value
$lmExcluded = (Get-ClusterResourceType -Name 'Virtual Machine' |
Get-ClusterParameter -Name MigrationExcludeNetworks).Value
Write-Host "LM order: $lmNetworks"
Write-Host "LM excluded: $lmExcluded"
# Per-host VM migration network configuration
Invoke-Command -ComputerName (Get-ClusterNode).Name {
[PSCustomObject]@{
Node = $env:COMPUTERNAME
Enabled = (Get-VMHost).VirtualMachineMigrationEnabled
AuthType = (Get-VMHost).VirtualMachineMigrationAuthenticationType
PerfMode = (Get-VMHost).VirtualMachineMigrationPerformanceOption
Networks = (Get-VMMigrationNetwork | Select-Object -Expand Subnet) -join ', '
}
}Step 2, start an actual Live Migration of a VM with at least 8 GB of active memory:
Move-ClusterVirtualMachineRole -Name 'TEST-LM-VM' -Node HV02Step 3, on the source host during the migration, capture the active TCP connections of the VMMS process:
$vmms = Get-Process vmms | Select-Object -First 1 -ExpandProperty Id
Get-NetTCPConnection -OwningProcess $vmms |
Where-Object {$_.State -eq 'Established'} |
Select-Object LocalAddress, RemoteAddress, LocalPort, RemotePort
# Live Migration uses TCP/6600 (or 445 in SMB mode); we want
# to see the expected storage/migration subnet on both sides.If the local address comes back as a management subnet IP, or worse, the heartbeat IP, the configuration is broken regardless of what the three layers report.
4. The fix, explicit and validated configuration
The remediation pattern is the same on every engagement. We make all three layers explicit and consistent, and validate with a test migration.
1. Set cluster network roles correctly:
# Identify subnets by IP range first, names vary per deployment
Get-ClusterNetwork | Select-Object Name, Address, Role
# Storage network, typically Cluster only (not available for client traffic)
(Get-ClusterNetwork 'Storage1').Role = 1 # Cluster
# Management network, ClusterAndClient
(Get-ClusterNetwork 'Management').Role = 3 # ClusterAndClient
# Heartbeat network if separate, Cluster only
(Get-ClusterNetwork 'Heartbeat').Role = 1 # Cluster2. Set the cluster Live Migration priority:
# Build the priority list, IDs not names
$preferred = Get-ClusterNetwork | Where-Object {
$_.Name -in 'Storage1','Storage2'
}
$excluded = Get-ClusterNetwork | Where-Object {
$_.Name -in 'Management','Heartbeat'
}
Get-ClusterResourceType -Name 'Virtual Machine' |
Set-ClusterParameter -Name MigrationNetworkOrder -Value ($preferred.ID -join ';')
Get-ClusterResourceType -Name 'Virtual Machine' |
Set-ClusterParameter -Name MigrationExcludeNetworks -Value ($excluded.ID -join ';')3. Set per-host migration networks explicitly on every node:
Invoke-Command -ComputerName (Get-ClusterNode).Name {
# Remove all existing entries first, start clean
Get-VMMigrationNetwork | Remove-VMMigrationNetwork
# Add only the subnets we want to use
Add-VMMigrationNetwork -Subnet '10.20.0.0/24' -Priority 10
Add-VMMigrationNetwork -Subnet '10.21.0.0/24' -Priority 20
}Slow Live Migration is not a capacity problem, it is almost always a routing problem. The three layers above are validated as standard in every CloudLabs Hyper-V Cluster Health Check, with before-and-after numbers in the report.
Schedule a Hyper-V Cluster Health Check intro call →5. Performance options: TCP, Compression, SMB, RDMA
Hyper-V supports three Live Migration performance modes. Choosing the right one matters as much as choosing the right network.
- TCP/IP. One TCP stream per migration, oldest option, lowest throughput on modern hardware. Avoid except for compatibility.
- Compression. TCP with on-the-fly memory compression. Good when CPU is abundant and the network is the bottleneck. Default in Windows Server 2012 R2.
- SMB. Uses SMB Multichannel, supports RDMA, scales automatically across multiple NICs. The right choice on any modern cluster with multiple NICs or RDMA-capable hardware. Default since Windows Server 2016.
Invoke-Command -ComputerName (Get-ClusterNode).Name {
# SMB is what you want on modern hardware
Set-VMHost -VirtualMachineMigrationPerformanceOption SMB
# And concurrent migration limits, tuned to your bandwidth
Set-VMHost -MaximumVirtualMachineMigrations 4
Set-VMHost -MaximumStorageMigrations 2
}When SMB mode is selected and NICs support RDMA with DCB/PFC switch-side, Live Migration automatically runs over RDMA. Verify with:
Get-SmbClientNetworkInterface | Select-Object FriendlyName, RdmaCapable, Speed
Get-SmbConnection # During an active migration
Get-SmbMultichannelConnection # Session detailOn Windows Server 2025 you can layer dynamic CPU compatibility on top of this, enabling Live Migration between hosts with different CPU generations without VM shutdown. For heterogeneous clusters spanning multiple hardware refreshes, that is a noticeable operational win.
6. End-to-end validation
Configuration is not validation. The only way to be sure is to run an actual migration and confirm the path. The CloudLabs validation procedure:
- Build a test VM with 16 GB RAM and dirty most of it (a memory stress script works).
- Start a packet counter on every NIC of the source host:
Get-NetAdapter | Get-NetAdapterStatistics. - Migrate the VM and time it:
Measure-Command { Move-ClusterVirtualMachineRole -Name 'TEST-LM' -Node HV02 } - Read NIC statistics again. The bytes-per-second delta on the intended migration NIC should account for nearly the entire VM RAM size. Other NICs should stay essentially flat.
- Repeat in the reverse direction to confirm symmetry.
We capture this in the customer-facing .docx report with before-and-after numbers. It is one of the most tangible measurements in a Health Check: the cluster goes from "migrations take 4 minutes and saturate management" to "migrations take 28 seconds and are invisible on management".
7. Preventing regression
Live Migration configuration drift usually happens during three operations: NIC replacement, virtual switch reconfiguration, and node reimaging. The CloudLabs remediation runbook for this finding includes:
- A documented baseline of
Get-VMMigrationNetwork,Get-VMHostmigration settings, andGet-ClusterParameteroutput, stored in source control. - A 10-line PowerShell script that compares current state to baseline and returns non-zero exit on drift. Hooked into the monthly maintenance window.
- A two-line validation step in the post-patch checklist: run a test migration, confirm the path.
- A note in the node build runbook: every new node must explicitly remove default
VMMigrationNetworkentries before joining the cluster.
The fix for Live Migration on the wrong network is not configuration, it is the discipline to validate that configuration end to end after every change.
CloudLabs delivers this as part of the standard Hyper-V Cluster Health Check. The configuration baseline and drift detection script ship with the remediation report.
Schedule a Hyper-V Cluster Health Check intro call →
Frequently asked questions
Because from the cluster's perspective there is no fallback to see. The host had no VMMigrationNetwork entry for the intended subnet, so vmms picked an interface that worked. From the Cluster Service's view that is a successful migration. It is a design limitation, not a bug, and the only defence is verification of the actual path.
On a cluster with multiple NICs or RDMA-capable hardware, yes. On a single-NIC cluster without RDMA, Compression can occasionally be slightly faster because it leans harder on CPU. In production we have not seen a scenario in the last three years where Compression was the right choice; SMB is the modern default.
The cluster level influences which networks the cluster prefers when it coordinates a Live Migration. The per-host list is what vmms actually uses to bind a source IP. Both must be consistent. When they disagree, the per-host list wins in practice, because that is what actually establishes the TCP connection.
On 25 GbE with SMB and RDMA, 4 to 8 parallel migrations is common. On 10 GbE without RDMA, 2 to 4. Test it during a maintenance window with your actual VM mix, because VMs with heavy active memory can bottleneck each other even on fast networks.
Yes, partially. Storage Live Migration uses SMB and shares the MaximumStorageMigrations setting. Network selection happens through SMB Multichannel, so the priority lives in SMB configuration rather than Live Migration-specific settings. The core principle still holds: know which path the traffic is actually taking.
Live Migration over het verkeerde netwerk: de stille Hyper-V valkuil
Live Migration die stilletjes het verkeerde netwerk gebruikt is de meest voorkomende bevinding in CloudLabs Hyper-V Cluster Health Checks. Het is precies het type misconfiguratie dat niet faalt, het draait gewoon traag, concurreert met cluster-heartbeats tijdens patch-vensters, en veroorzaakt incidenten die er als switch-problemen uitzien terwijl het in werkelijkheid verkeerd gerouteerde VM-memory transfers zijn.
Dit artikel doorloopt de drie configuratielagen, de PowerShell om het werkelijk gebruikte pad te verifiëren, en de remediation die wij in elke opdracht toepassen.
1. De drie configuratielagen
Netwerkselectie voor Live Migration loopt over drie onafhankelijke configuratielagen. Wij vinden regelmatig clusters waarvan twee correct staan en de derde het geheel stilletjes breekt.
Cluster network-rol. Elk cluster-netwerk (subnet) heeft een Role: None, Cluster, of ClusterAndClient. Het cluster overweegt alleen netwerken met rol Cluster of ClusterAndClient voor intern verkeer, inclusief Live Migration.
Cluster Live Migration prioriteit. Binnen het clusterobject zit een geordende lijst van netwerken die het cluster voor Live Migration prefereert. Stel deze in via Set-ClusterParameter of via de GUI onder Networks → Live Migration Settings.
Per-host VM Migration network-lijst. Elke Hyper-V host heeft zijn eigen VMMigrationNetwork-lijst. Dat is wat vmms daadwerkelijk gebruikt om aan een bron-IP te binden bij het starten van een migratie. Zegt het cluster "gebruik 10.10.20.0/24" maar heeft de host geen VMMigrationNetwork-entry voor dat subnet, dan valt de host terug op welke interface dan ook antwoordt, meestal het management-netwerk.
2. Hoe "verkeerde netwerk" er in werkelijkheid uitziet
De klassieke symptomen in productie:
- Migraties duren 4 tot 6 minuten waar 30 tot 45 seconden zou moeten kunnen. Meestal omdat LM via een 1 GbE management-netwerk gaat in plaats van het 25 GbE storage-netwerk.
- Cluster-heartbeat-drops tijdens CAU-runs. Als LM en heartbeat een NIC delen, kunnen grote memory transfers de link verzadigen en de heartbeat als missing markeren.
- Switch-port utilisatie op management-VLAN piekt naar 90% plus tijdens patching. Netwerk-ops merkt het en opent een ticket. Het Hyper-V team legt geen relatie met LM.
- SMB Multichannel-sessies op onverwachte plekken. Als LM op SMB staat (default vanaf WS2016) maar geen schoon RDMA-pad heeft, valt het terug op gewone TCP-over-SMB op welke interface dan ook bereikbaar is.
Het cluster is in al deze scenario's gezond volgens reguliere monitoring-criteria. Test-Cluster komt door. Failover Cluster Manager staat groen. De enige correlatie is timing. Dat is precies waarom dit een typische Hyper-V Cluster Health Check bevinding is, en niet iets wat reactieve monitoring oppakt. Zie ook Hyper-V Cluster Health Check: 10 issues die we steeds vinden in 2026 voor het bredere patroon.
3. Het gebruikte pad verifiëren
Verificatie vraagt een live test. Alleen configuratie inspecteren is niet voldoende omdat de drie lagen op niet-evidente manieren op elkaar inwerken. De procedure die CloudLabs tijdens een Health Check gebruikt:
Stap 1, snapshot alle drie configuratielagen:
# Cluster-netwerken en hun rollen
Get-ClusterNetwork |
Select-Object Name, Address, Role, AutoMetric, Metric |
Sort-Object Metric
# Cluster Live Migration prioriteit
$lmNetworks = (Get-ClusterResourceType -Name 'Virtual Machine' |
Get-ClusterParameter -Name MigrationNetworkOrder).Value
$lmExcluded = (Get-ClusterResourceType -Name 'Virtual Machine' |
Get-ClusterParameter -Name MigrationExcludeNetworks).Value
Write-Host "LM order: $lmNetworks"
Write-Host "LM excluded: $lmExcluded"
# Per-host VM migratie-netwerkconfiguratie
Invoke-Command -ComputerName (Get-ClusterNode).Name {
[PSCustomObject]@{
Node = $env:COMPUTERNAME
Enabled = (Get-VMHost).VirtualMachineMigrationEnabled
AuthType = (Get-VMHost).VirtualMachineMigrationAuthenticationType
PerfMode = (Get-VMHost).VirtualMachineMigrationPerformanceOption
Networks = (Get-VMMigrationNetwork | Select-Object -Expand Subnet) -join ', '
}
}Stap 2, start een werkelijke Live Migration van een VM met minstens 8 GB actief geheugen:
Move-ClusterVirtualMachineRole -Name 'TEST-LM-VM' -Node HV02Stap 3, op de bron-host, tijdens de migratie, leg de actieve TCP-verbindingen van het VMMS-proces vast:
$vmms = Get-Process vmms | Select-Object -First 1 -ExpandProperty Id
Get-NetTCPConnection -OwningProcess $vmms |
Where-Object {$_.State -eq 'Established'} |
Select-Object LocalAddress, RemoteAddress, LocalPort, RemotePort
# Live Migration gebruikt TCP/6600 (of 445 in SMB-mode); we willen
# het verwachte storage/migratie-subnet aan beide kanten zien.Komt het local address terug als een management-subnet IP, of erger, het heartbeat-IP, dan is de configuratie kapot, ongeacht wat de drie lagen rapporteren.
4. De oplossing, expliciete en gevalideerde configuratie
Het remediation-patroon is in elke opdracht gelijk. We maken alle drie de lagen expliciet en consistent, en valideren met een test-migratie.
1. Stel cluster network-rollen correct in:
# Identificeer subnetten op IP-range eerst, namen wisselen per deployment
Get-ClusterNetwork | Select-Object Name, Address, Role
# Storage-netwerk, typisch alleen Cluster (niet beschikbaar voor client-verkeer)
(Get-ClusterNetwork 'Storage1').Role = 1 # Cluster
# Management-netwerk, ClusterAndClient
(Get-ClusterNetwork 'Management').Role = 3 # ClusterAndClient
# Heartbeat-netwerk indien apart, alleen Cluster
(Get-ClusterNetwork 'Heartbeat').Role = 1 # Cluster2. Stel de cluster Live Migration-prioriteit in:
# Bouw de prioriteitenlijst, ID's, geen namen
$preferred = Get-ClusterNetwork | Where-Object {
$_.Name -in 'Storage1','Storage2'
}
$excluded = Get-ClusterNetwork | Where-Object {
$_.Name -in 'Management','Heartbeat'
}
Get-ClusterResourceType -Name 'Virtual Machine' |
Set-ClusterParameter -Name MigrationNetworkOrder -Value ($preferred.ID -join ';')
Get-ClusterResourceType -Name 'Virtual Machine' |
Set-ClusterParameter -Name MigrationExcludeNetworks -Value ($excluded.ID -join ';')3. Stel per-host migratie-netwerken expliciet in op iedere node:
Invoke-Command -ComputerName (Get-ClusterNode).Name {
# Eerst alle bestaande entries verwijderen, schoon beginnen
Get-VMMigrationNetwork | Remove-VMMigrationNetwork
# Voeg alleen de subnetten toe die we willen gebruiken
Add-VMMigrationNetwork -Subnet '10.20.0.0/24' -Priority 10
Add-VMMigrationNetwork -Subnet '10.21.0.0/24' -Priority 20
}Trage Live Migration is geen capaciteitsprobleem, het is bijna altijd een routeringsprobleem. De drie lagen hierboven valideren we standaard in elke CloudLabs Hyper-V Cluster Health Check, met voor- en na-cijfers in het rapport.
Plan een Hyper-V Cluster Health Check kennismaking →5. Performance-opties: TCP, Compressie, SMB, RDMA
Hyper-V ondersteunt drie Live Migration performance-modi. De juiste kiezen telt net zo zwaar als het juiste netwerk kiezen.
- TCP/IP. Eén TCP-stream per migratie, oudste optie, laagste throughput op moderne hardware. Vermijd, behalve voor compatibility.
- Compressie. TCP met on-the-fly memory compression. Goed wanneer CPU overvloedig is en netwerk de bottleneck. Default in Windows Server 2012 R2.
- SMB. Gebruikt SMB Multichannel, ondersteunt RDMA, schaalt automatisch over meerdere NIC's. De juiste keuze op elk modern cluster met meerdere NIC's of RDMA-capable hardware. Default vanaf Windows Server 2016.
Invoke-Command -ComputerName (Get-ClusterNode).Name {
# SMB is wat je wilt op moderne hardware
Set-VMHost -VirtualMachineMigrationPerformanceOption SMB
# En gelijktijdige migraties, afstemmen op je bandbreedte
Set-VMHost -MaximumVirtualMachineMigrations 4
Set-VMHost -MaximumStorageMigrations 2
}Wanneer SMB-mode is gekozen en de NIC's RDMA ondersteunen met DCB/PFC op switchzijde, draait Live Migration automatisch over RDMA. Verifieer met:
Get-SmbClientNetworkInterface | Select-Object FriendlyName, RdmaCapable, Speed
Get-SmbConnection # Tijdens een actieve migratie
Get-SmbMultichannelConnection # SessiedetailsOp Windows Server 2025 kun je daar bovenop dynamic CPU compatibility activeren, wat Live Migration tussen hosts met verschillende CPU-generaties mogelijk maakt zonder VM-shutdown. Voor heterogene clusters die over een paar hardware-refreshes heen reiken, is dat een merkbare operationele winst.
6. End-to-end valideren
Configuratie is geen validatie. De enige manier om zeker te zijn, is een werkelijke migratie draaien en het pad bevestigen. De CloudLabs validatieprocedure:
- Bouw een test-VM met 16 GB RAM, vervuil het grootste deel ervan (een memory-stress script werkt).
- Start een packet counter op iedere NIC van de bron-host:
Get-NetAdapter | Get-NetAdapterStatistics. - Migreer de VM en meet de tijd:
Measure-Command { Move-ClusterVirtualMachineRole -Name 'TEST-LM' -Node HV02 } - Lees de NIC-statistieken opnieuw. De bytes-per-second delta op de beoogde migratie-NIC moet bijna de hele VM-RAM-grootte verklaren. Andere NIC's moeten in wezen vlak blijven.
- Herhaal in omgekeerde richting om symmetrie te bevestigen.
Wij leggen dit vast in het klantgerichte .docx-rapport met voor- en na-cijfers. Het is een van de meest tastbare metingen in een Health Check: het cluster gaat van "migraties duren 4 minuten en verzadigen management" naar "migraties duren 28 seconden en zijn niet zichtbaar op management".
7. Regressie voorkomen
Live Migration-configuratiedrift gebeurt meestal bij drie operaties: NIC-vervanging, virtuele-switch herconfiguratie, en node re-imaging. De CloudLabs remediation-runbook voor deze bevinding bevat:
- Een gedocumenteerde baseline van
Get-VMMigrationNetwork,Get-VMHost-migratie-instellingen enGet-ClusterParameter-output, in source control opgeslagen. - Een PowerShell-script van 10 regels dat huidige status met baseline vergelijkt en non-zero exit geeft bij drift. Wordt ingehaakt in het maandelijkse onderhoudsvenster.
- Een tweeregelige validatiestap in de post-patch checklist: voer een test-migratie uit, bevestig het pad.
- Een notitie in de node-build runbook: elke nieuwe node moet default
VMMigrationNetwork-entries expliciet verwijderen vóór toetreding tot het cluster.
De fix voor Live Migration over het verkeerde netwerk is niet configuratie, het is de discipline om die configuratie na elke wijziging end-to-end te valideren.
CloudLabs levert dit als onderdeel van de standaard Hyper-V Cluster Health Check. De configuratie-baseline en het drift-detection script zitten in het remediation-rapport.
Plan een Hyper-V Cluster Health Check kennismaking →
Veelgestelde vragen
Omdat het cluster vanuit zijn perspectief geen fallback ziet. De host had geen VMMigrationNetwork-entry voor het gewenste subnet, dus vmms koos een interface die wel werkte. Vanuit de Cluster Service is dat een succesvolle migratie. Het is een ontwerpbeperking, niet een bug, en de enige verdediging is verificatie van het werkelijke pad.
Op een cluster met meerdere NIC's of RDMA-capable hardware, ja. Op een single-NIC cluster zonder RDMA is Compressie soms iets sneller omdat het zwaarder leunt op CPU. In productie hebben we de afgelopen drie jaar geen scenario meer gezien waar Compressie de juiste keuze was; SMB is de moderne default.
Het cluster-niveau beïnvloedt welke netwerken het cluster prefereert wanneer hij een Live Migration coördineert. De per-host lijst is wat vmms daadwerkelijk gebruikt om een bron-IP te binden. Beide moeten consistent zijn. Als ze afwijken wint in de praktijk de per-host lijst, omdat dat is wat de TCP-verbinding daadwerkelijk opzet.
Op 25 GbE met SMB en RDMA: 4 tot 8 parallelle migraties is gangbaar. Op 10 GbE zonder RDMA: 2 tot 4. Test het tijdens een onderhoudsvenster met je werkelijke VM-mix, want VM's met veel actief geheugen kunnen elkaar bottlenecken zelfs op snelle netwerken.
Ja, deels. Storage Live Migration gebruikt SMB en deelt de MaximumStorageMigrations-instelling. De netwerkselectie loopt langs SMB Multichannel, dus de prioriteit zit eerder in SMB-configuratie dan in de Live Migration-specifieke instellingen. Maar het basisprincipe blijft: weet welk pad het verkeer daadwerkelijk neemt.