Hyper-V cluster assessment: 10 issues die we steeds vinden in 2026

1. Live Migration over het verkeerde netwerk

De meest voorkomende bevinding. Live Migration valt terug op het management- of heartbeat-VLAN omdat het toegewezen migratienetwerk niet is aangezet voor clusterverkeer, of nooit is toegevoegd aan de expliciete Live Migration-lijst per Hyper-V host. Het symptoom is zelden een failure. Wel trage migraties tijdens patch-vensters en onverklaarbare latency op cluster-heartbeats wanneer meerdere VM's tegelijk verplaatsen.

Twee configuratie-vlakken zijn relevant. De Role per cluster-netwerk op clusterniveau, en de expliciete Live Migration-netwerklijst per host. Die zijn onafhankelijk. Wij vinden regelmatig dat het ene correct staat en het andere vergeten is. Volledige uitleg in Live Migration over het verkeerde netwerk: een veelvoorkomende Hyper-V valkuil.

Belangrijk detail bij diagnose: sinds Windows Server 2016 is de default-transportmodus voor Live Migration SMB, dus verkeer loopt over poort 445, niet over de oude TCP-poort 6600. Filteren op alleen 6600 levert op moderne clusters geen resultaat op.

Diagnose:

# Cluster-netwerkrollen
Get-ClusterNetwork | Select-Object Name, Role, Address, AutoMetric, Metric

# Live Migration-configuratie per host
Get-VMHost | Select-Object Name, VirtualMachineMigrationEnabled,
    VirtualMachineMigrationAuthenticationType,
    VirtualMachineMigrationPerformanceOption,
    @{N='MigrationNetworks';E={(Get-VMMigrationNetwork).Subnet -join ', '}}

# Effectief pad tijdens een test-move (SMB-modus: poort 445, TCP-modus: poort 6600)
Get-NetTCPConnection -RemotePort 445,6600 |
    Select-Object LocalAddress, RemoteAddress, OwningProcess

Voor de zekerheid: een korte pktmon-capture op de bron-NIC tijdens een handmatige Live Migration geeft uitsluitsel over welk fysiek pad daadwerkelijk wordt gebruikt.

Oplossen: beperk op iedere host de Live Migration-netwerklijst tot het subnet dat je daadwerkelijk wilt gebruiken, en zorg dat dat subnet op het clusterobject Role = ClusterAndClient (of alleen Cluster) heeft. Add-VMMigrationNetwork voegt een subnet toe, Remove-VMMigrationNetwork verwijdert ongewenste subnets. Valideer end-to-end met een handmatige Live Migration.

2. Witness verkeerd geconfigureerd of afwezig

Quorum is het onzichtbare stuk dat een cluster overeind houdt als nodes verdwijnen. We vinden regelmatig two-node clusters zonder witness, File Share Witnesses op een single-node, single-disk fileserver zonder UPS, en Disk Witnesses op dezelfde SAN-LUN als de CSV's die ze moeten beschermen.

Over Dynamic Quorum: op Windows Server 2016 en hoger combineert Dynamic Quorum met Dynamic Witness, en het cluster past de votes dynamisch aan om enkelvoudige failures te overleven. Dat is geen vervanging voor een witness. Bij een gelijktijdige netwerkpartitie of dubbele uitval zonder externe tiebreaker is split-brain niet betrouwbaar opgelost. Een witness blijft vereist voor elke productieconfiguratie.

Get-ClusterQuorum | Format-List *

Get-ClusterResource | Where-Object {$_.OwnerGroup -eq 'Cluster Group'} |
    Format-Table Name, State, OwnerNode, ResourceType

Beslissingsmatrix als vuistregel:

• Single-site twee nodes: Cloud Witness, per definitie buiten je failure domain.
• Single-site drie of meer nodes: Cloud Witness, tenzij Azure-connectivity geen optie is, anders File Share Witness op infrastructuur die echt onafhankelijk is.
• Two-site stretched: Cloud Witness, of een File Share Witness in een derde site, nooit in een van de twee cluster-sites.
• Disconnected of air-gapped: File Share Witness op gedocumenteerd onafhankelijke storage en voeding.

Volledige vergelijking in File Share Witness vs Cloud Witness vs Disk Witness: welk type kies je?.

3. CSV ownership-onbalans

Cluster Shared Volume-eigendom stapelt zich op één node na een patch-ronde, een failover, of een node-drain die niemand achteraf herbalanceerd heeft. Het symptoom is ongelijke CPU op de coordinator-node en read-heavy workloads die latency-pieken ervaren die er random uitzien, totdat je ze correleert met CSV-ownership.

# Huidige verdeling
Get-ClusterSharedVolume | Select-Object Name, OwnerNode, State |
    Group-Object OwnerNode | Select-Object Name, Count

# Rebalance round-robin over actieve nodes, met korte pauze per move
$nodes = (Get-ClusterNode | Where-Object State -eq 'Up').Name
$i = 0
Get-ClusterSharedVolume | ForEach-Object {
    Move-ClusterSharedVolume -Name $_.Name -Node $nodes[$i % $nodes.Count]
    Start-Sleep -Seconds 5
    $i++
}

Elke move veroorzaakt een korte I/O-pauze op de betrokken CSV. Plan rebalance in een rustig venster of na een patch-ronde, niet midden op de dag. Wij behandelen dit als een doorlopende operationele taak; de post-patch checklist in onze remediation-rapporten eindigt altijd met een CSV-rebalance. Diepere uitleg in CSV ownership-onbalans: oorzaken en oplossingen.

4. Firmware- en driver-drift tussen nodes

Cluster-nodes komen identiek uit de doos en drijven langzaam uit elkaar. Eén host krijgt een NIC-firmware update tijdens een incident, een andere een nieuwe HBA-driver tijdens een gepland onderhoudsvenster, een derde geen van beide. Zes maanden later faalt het cluster op subtiele manieren: Live Migration duurt drie keer zo lang over een Intel X710 versus een Mellanox CX-4, of storage-timeouts treden alleen op één host op.

Dit is de voornaamste oorzaak van intermitterende cluster-instabiliteit die wij onderzoeken. Firmware-drift is onzichtbaar voor de meeste monitoring-tools, omdat de waarden in de BMC of NIC-EEPROM zitten, niet in Windows.

# NIC driver-versie per node (firmware via Windows is vendor-afhankelijk)
Invoke-Command -ComputerName (Get-ClusterNode).Name {
    Get-NetAdapter | Select-Object PSComputerName, Name, InterfaceDescription,
        DriverVersion, DriverDate
} | Sort-Object PSComputerName, Name

# Storport en MPIO driver-versies
Invoke-Command -ComputerName (Get-ClusterNode).Name {
    Get-CimInstance Win32_PnPSignedDriver |
        Where-Object DeviceClass -in 'SCSIADAPTER','SYSTEM' |
        Select-Object PSComputerName, DeviceName, DriverVersion, DriverDate
}

Voor betrouwbare firmware-inventarisatie van NIC's, HBA's en BIOS zijn vendor-tools nodig: Dell iDRAC (racadm), HPE iLO (ilorest of SUM), Lenovo XClarity Controller, Supermicro IPMI. Windows-cmdlets zoals Get-NetAdapterAdvancedProperty -RegistryKeyword '*FirmwareVersion' werken voor sommige Mellanox- en Intel-drivers, maar niet universeel.

Oplossen: behandel firmware als configuratie. Zet een baseline (vendor solution profile van Dell, HPE of Lenovo), documenteer het in je runbook, en upgrade het cluster als geheel tijdens een gepland venster.

5. Verschillende Windows Server build-nummers

De Cluster Service tolereert kortdurende mixed-builds tijdens een rolling patch, maar wij vinden regelmatig clusters die al een half jaar mid-patch staan. Het resultaat zijn functionele regressies: een fix in een latere CU is intermitterend omdat de helft van de nodes hem mist, en het gedrag hangt af van welke node een resource bezit op het moment van falen.

Invoke-Command -ComputerName (Get-ClusterNode).Name {
    [PSCustomObject]@{
        Node     = $env:COMPUTERNAME
        OS       = (Get-CimInstance Win32_OperatingSystem).Caption
        Build    = (Get-CimInstance Win32_OperatingSystem).BuildNumber
        UBR      = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').UBR
        LastBoot = (Get-CimInstance Win32_OperatingSystem).LastBootUpTime
    }
} | Sort-Object Node

Als de UBR-kolom verschillende waarden toont over nodes, staat het cluster in een toestand die Microsoft Support eerst gerepareerd wil zien voor zij escaleren. Patch het cluster als geheel, valideer met Test-Cluster, en behandel de post-patch toestand als de nieuwe known-good.

6. Geen anti-affinity voor DC's en management-VM's

Na een node-drain belanden alle domain controllers vrolijk op dezelfde overlevende host. Eén host-crash legt dan tegelijk alle DC's stil, en daarmee de authenticatie voor de hele omgeving, inclusief de management-plane die je nodig hebt om het cluster te herstellen.

# Clustered VM's zonder anti-affinity
Get-ClusterGroup | Where-Object GroupType -eq 'VirtualMachine' |
    Select-Object Name, OwnerNode, AntiAffinityClassNames |
    Where-Object {-not $_.AntiAffinityClassNames}

# Anti-affinity instellen voor alle DC's
Get-ClusterGroup | Where-Object Name -like 'DC*' | ForEach-Object {
    $g = Get-ClusterGroup -Name $_.Name
    $g.AntiAffinityClassNames.Clear()
    $g.AntiAffinityClassNames.Add('DomainControllers') | Out-Null
}

Anti-affinity is soft: het wordt geschonden als er geen andere geldige host is. Dat is precies het juiste gedrag. Het cluster houdt de DC's draaiend; het stapelt ze alleen niet standaard op.

7. CSV BlockCache uit of te klein

CSV BlockCache was jarenlang opt-in en veel oudere clusters staan nog op nul. Aanzetten voor read-heavy workloads (VDI, fileserver-clusters, OLTP-databases met hoge cache-locality) kan read-latency een orde van grootte verlagen zonder risico voor data-integriteit. Het is een read-side cache, geen write buffer.

# Huidige waarde
(Get-Cluster).BlockCacheSize

# Aanzetten op een vijf-node cluster, 2 GB per node
(Get-Cluster).BlockCacheSize = 2048

# Per-CSV cache-status verifiëren
Get-ClusterSharedVolume | ForEach-Object {
    $_ | Select-Object Name,
        @{N='CacheEnabled';E={$_.SharedVolumeInfo.Partition.IsCsvCacheEnabled}}
}

Belangrijk: de nieuwe BlockCache-waarde wordt pas actief per CSV nadat die offline en weer online gaat, of na een cluster-restart. In productie betekent dit een gefaseerde rebalance, niet een directe activatie. Plan dat in.

De trade-off is RAM. Dimensioneer op basis van je VM-dichtheid en bevestig in echte workloads dat de node nog headroom heeft voor VM-consolidatie onder N-1 condities. Dimensioneer BlockCache niet vanuit de failover-geëvacueerde toestand.

8. Cluster-netwerk op één fysiek pad

Cluster-heartbeats die via één switch of één uplink lopen. Wij zien dit vooral in lift-and-shift cluster-builds waar het oorspronkelijke twee-switchontwerp in de inkoopfase is uitgekleed. Resultaat: een switch-reboot, een stack-split of een falende SFP partitioneert het cluster, en de overlevende partitie arbitreert slecht omdat de witness ook via datzelfde pad bereikbaar is.

Cluster-netwerken vereisen redundantie op laag 1, niet alleen op IP-niveau. Twee NIC's in dezelfde switch is geen redundantie. Geteamde NIC's over twee switches is het minimum voor productie.

Over teaming-technologie: LBFO (Load Balancing and Failover) wordt op Windows Server 2022 en 2025 niet ondersteund onder de Hyper-V virtuele switch. SET (Switch Embedded Teaming) is de enige ondersteunde optie voor nieuwe deployments. Bestaande LBFO-teams die nog onder Hyper-V vSwitch hangen op deze OS-versies zijn een hard remediation-punt, geen advies.

Tijdens een Hyper-V cluster assessment traceren wij cluster-heartbeatverkeer altijd tot de fysieke poort, niet alleen de logische NIC-naam.

9. Niet-ondersteunde of niet-gevalideerde storage-configuraties

De vergaarbak. Voorbeelden die wij hebben opgeschreven:

• SMB Direct-paden gepresenteerd als RDMA-capable omdat de NIC RoCEv2 ondersteunt, maar DCB en PFC zijn niet ingericht op switch-zijde. Stille terugval naar TCP zonder waarschuwing. iWARP heeft deze switch-afhankelijkheid niet, RoCEv2 wel.
• SMB Multichannel over ongelijksoortige NIC's (één 25 GbE, één 10 GbE), waar het cluster voor de helft van de sessies het tragere pad kiest.
• MPIO met Round Robin op een active/passive array die sterk de voorkeur geeft aan één controller.
• S2D-deployments waar één node na een hardware-swap een afwijkende drive bay-configuratie heeft, onzichtbaar voor het cluster maar zichtbaar in Storage Spaces health.

Valideren met de native tools, productie-veilige variant zonder storage-disruptie:

Test-Cluster -Include 'Inventory','Network','System Configuration','Cluster Configuration' `
             -ReportName Cluster Assessment

Get-SmbClientNetworkInterface | Select-Object FriendlyName, RdmaCapable, Speed, IpAddress

Get-PhysicalDisk | Group-Object MediaType, OperationalStatus, FirmwareVersion

Een volledige storage-validatie inclusief de Storage-categorie vereist een onderhoudsvenster of een aparte test-LUN die niet door een clusterrol wordt gebruikt.

10. Geen gedocumenteerde DR-validatie

Stretched- of multisite-clusters die nog nooit end-to-end zijn omgeklapt. Het runbook bestaat, het storage-replicatie dashboard staat groen, en niemand heeft het ooit in productie daadwerkelijk geprobeerd. Een Cluster Assessment brengt vaak het verschil tussen runbook en werkelijkheid aan het licht: DNS-TTL's die te lang zijn, applicatielaag-connectionstrings die hardcoded naar één site verwijzen, witness-plaatsing die de test niet overleeft.

We adviseren minimaal een jaarlijkse geplande failover, behandeld als productie-impact en gerepeteerd in een onderhoudsvenster.

Het patroon achter de lijst

Negen van deze tien bevindingen hebben niets met workload-performance te maken. Het is stille configuration debt die zich opbouwt over patch-cycli, hardware-refreshes en personeelswissels. Het is óók precies het type bevinding dat monitoring-tools missen, omdat ze in isolatie correct lijken: een witness bestaat, een Live Migration-netwerk is geconfigureerd, CSV-ownership is valide. De drift zit in de relatie tussen instellingen, en de enige betrouwbare manier om dat boven water te krijgen is een gestructureerd extern onderzoek.

Herken je drie of meer issues hierboven? Je staat niet alleen, en de fix kost meestal niet meer dan één wekelijks onderhoudsvenster.

Plan een Hyper-V cluster assessment kennismaking →