Live Migration over het verkeerde netwerk: de stille Hyper-V-valkuil

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 de eerste interface die reageert, 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 ruim 90% 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 de eerste bereikbare interface.

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 assessment bevinding is, en niet iets wat reactieve monitoring oppakt. Zie ook Hyper-V cluster assessment: 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 ClusterTriage tijdens een cluster assessment 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 HV02

Stap 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  # Cluster

2. 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
}

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 compatibiliteit.
• Compressie. TCP met on-the-fly memory compression. Goed wanneer CPU overvloedig is en het netwerk de bottleneck is. 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         # Sessiedetails

Op 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 ClusterTriage validatieprocedure:

1. Bouw een test-VM met 16 GB RAM, vervuil het grootste deel ervan (een memory-stress script werkt).
2. Start een packet counter op iedere NIC van de bron-host: Get-NetAdapter | Get-NetAdapterStatistics.
3. Migreer de VM en meet de tijd:

   Measure-Command { Move-ClusterVirtualMachineRole -Name 'TEST-LM' -Node HV02 }

4. 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.
5. Herhaal in omgekeerde richting om symmetrie te bevestigen.

Wij leggen dit vast in het .docx-rapport voor de klant met voor- en na-cijfers. Het is een van de meest tastbare metingen in een cluster assessment: 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. Het ClusterTriage remediation-runbook voor deze bevinding bevat:

• Een gedocumenteerde baseline van Get-VMMigrationNetwork, Get-VMHost-migratie-instellingen en Get-ClusterParameter-output, in source control opgeslagen.
• Een PowerShell-script van 10 regels dat de huidige status met de 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 het 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.

ClusterTriage levert dit als onderdeel van de standaard Hyper-V cluster assessment. De configuratie-baseline en het drift-detection script zitten in het remediation-rapport.

Plan een Hyper-V cluster assessment kennismaking →