Hyper-V Cluster Health Check: 10 issues we keep finding in 2026

After years of Hyper-V Health Checks across Windows Server 2016, 2019, 2022 and 2025 environments, ten findings keep coming back. Across industries, scales and operations teams. None of them are exotic. Most stay quiet until a patch round, a hardware refresh or a single switch reboot turns them into a Sev-1 incident at 03:00 in the morning.

This article is the practical list. For each issue: root cause, the PowerShell to diagnose it, and the remediation we document in the customer report. Recognise three or more in your own environment? That is not an outlier, that is the average.

1. Live Migration over the wrong network

The most common finding. Live Migration falls back to the management or heartbeat VLAN because the dedicated migration network has not been enabled for cluster traffic, or has never been added to the explicit Live Migration network list per Hyper-V host. The symptom is rarely a failure. What you see is slow migrations during patch windows and unexplained latency on cluster heartbeats when multiple VMs move at the same time.

Two configuration planes matter. The Role per cluster network at cluster level, and the explicit Live Migration network list per host. They are independent. We regularly find one configured correctly and the other forgotten. Full detail in Live Migration on the wrong network: a common Hyper-V pitfall.

Diagnostic detail: since Windows Server 2016 the default Live Migration transport is SMB, so traffic uses port 445, not the older TCP port 6600. Filtering only on 6600 returns nothing on modern clusters.

Diagnosis:

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

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

# Effective path during a test move (SMB mode: port 445, TCP mode: port 6600)
Get-NetTCPConnection -RemotePort 445,6600 |
    Select-Object LocalAddress, RemoteAddress, OwningProcess

For certainty, a short pktmon capture on the source NIC during a manual Live Migration confirms which physical path is actually used.

Remediation: on each host, constrain the Live Migration network list to the subnet you actually want to use, and ensure that subnet has Role = ClusterAndClient (or Cluster only) on the cluster object. Add-VMMigrationNetwork adds a subnet; Remove-VMMigrationNetwork removes unwanted ones. Validate end-to-end with a manual Live Migration.

2. Witness misconfigured or absent

Quorum is the invisible piece that keeps a cluster alive when nodes disappear. We regularly find two-node clusters without a witness, File Share Witnesses on a single-node, single-disk file server without a UPS, and Disk Witnesses on the same SAN LUN as the CSVs they are supposed to protect.

On Dynamic Quorum: on Windows Server 2016 and later, Dynamic Quorum combines with Dynamic Witness and the cluster adjusts votes dynamically to survive single failures. This is not a replacement for a witness. In a simultaneous network partition or double failure without an external tiebreaker, split-brain is not reliably resolved. A witness remains required for any production configuration.

Get-ClusterQuorum | Format-List *

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

Decision matrix as a rule of thumb:

• Single-site two nodes: Cloud Witness, by definition outside your failure domain.
• Single-site three or more nodes: Cloud Witness, unless Azure connectivity is not an option, otherwise File Share Witness on infrastructure that is genuinely independent.
• Two-site stretched: Cloud Witness, or a File Share Witness in a third site, never in one of the two cluster sites.
• Disconnected or air-gapped: File Share Witness on documented independent storage and power.

Full comparison in File Share Witness vs Cloud Witness vs Disk Witness: which to choose.

3. CSV ownership imbalance

Cluster Shared Volume ownership piles up on one node after a patch round, a failover, or a node drain that nobody rebalanced afterwards. The symptom is uneven CPU on the coordinator node and read-heavy workloads experiencing latency spikes that look random until you correlate them with CSV ownership.

# Current distribution
Get-ClusterSharedVolume | Select-Object Name, OwnerNode, State |
    Group-Object OwnerNode | Select-Object Name, Count

# Rebalance round-robin over active nodes, with a brief pause 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++
}

Every move causes a short I/O pause on the CSV concerned. Schedule rebalance in a quiet window or after a patch round, not in the middle of the day. We treat this as an ongoing operational task; the post-patch checklist in our remediation reports always ends with a CSV rebalance. Deep dive in CSV ownership imbalance: causes and fixes.

4. Firmware and driver drift between nodes

Cluster nodes leave the factory identical and slowly drift apart. One host gets a NIC firmware update during an incident, another a new HBA driver during a planned maintenance window, a third neither. Six months later the cluster fails in subtle ways: Live Migration takes three times as long over an Intel X710 versus a Mellanox CX-4, or storage timeouts occur only on one host.

This is the leading cause of intermittent cluster instability we investigate. Firmware drift is invisible to most monitoring tools because the values sit in the BMC or NIC EEPROM, not in Windows.

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

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

For reliable firmware inventory of NICs, HBAs and BIOS, vendor tooling is required: Dell iDRAC (racadm), HPE iLO (ilorest or SUM), Lenovo XClarity Controller, Supermicro IPMI. Windows cmdlets such as Get-NetAdapterAdvancedProperty -RegistryKeyword '*FirmwareVersion' work for some Mellanox and Intel drivers, but not universally.

Remediation: treat firmware as configuration. Set a baseline (vendor solution profile from Dell, HPE or Lenovo), document it in your runbook, and upgrade the cluster as a whole during a planned window.

5. Mismatched Windows Server build numbers

The Cluster Service tolerates short-lived mixed builds during a rolling patch, but we regularly find clusters that have been mid-patch for half a year. The result is functional regressions: a fix in a later CU is intermittent because half the nodes lack it, and behaviour depends on which node owns a resource at the moment of failure.

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

If the UBR column shows different values across nodes, the cluster is in a state Microsoft Support will want repaired before they escalate. Patch the cluster as a whole, validate with Test-Cluster, and treat the post-patch state as the new known-good.

6. No anti-affinity for DCs and management VMs

After a node drain all domain controllers cheerfully end up on the same surviving host. One host crash then takes down all DCs simultaneously, and with them authentication for the entire environment, including the management plane you need to recover the cluster.

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

# Set anti-affinity for all DCs
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: it is violated if no other valid host exists. That is exactly the right behaviour. The cluster keeps the DCs running; it just does not stack them by default.

7. CSV BlockCache disabled or undersized

CSV BlockCache was opt-in for years and many older clusters are still set to zero. Enabling it for read-heavy workloads (VDI, file server clusters, OLTP databases with high cache locality) can lower read latency by an order of magnitude with no risk to data integrity. It is a read-side cache, not a write buffer.

# Current value
(Get-Cluster).BlockCacheSize

# Enable on a five-node cluster, 2 GB per node
(Get-Cluster).BlockCacheSize = 2048

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

Important: the new BlockCache value only takes effect on a CSV after it goes offline and back online, or after a cluster restart. In production this means a phased rebalance, not instant activation. Plan for it.

The trade-off is RAM. Size against your VM density and confirm in real workloads that the node has headroom for VM consolidation under N-1 conditions. Do not size BlockCache from the failover-evacuated state.

8. Cluster network on a single physical path

Cluster heartbeats running over a single switch or single uplink. We see this mostly in lift-and-shift cluster builds where the original two-switch design was stripped down in the procurement phase. Result: a switch reboot, a stack split or a failing SFP partitions the cluster, and the surviving partition arbitrates poorly because the witness is reachable over the same path.

Cluster networks require redundancy at Layer 1, not just at IP level. Two NICs in the same switch is not redundancy. Teamed NICs across two switches is the minimum for production.

On teaming technology: LBFO (Load Balancing and Failover) is not supported under the Hyper-V virtual switch on Windows Server 2022 and 2025. SET (Switch Embedded Teaming) is the only supported option for new deployments. Existing LBFO teams still attached to the Hyper-V vSwitch on these OS versions are a hard remediation item, not a recommendation.

During a Hyper-V Cluster Health Check we always trace cluster heartbeat traffic to the physical port, not just the logical NIC name.

9. Unsupported or unvalidated storage configurations

The catch-all. Examples we have documented:

• SMB Direct paths presented as RDMA-capable because the NIC supports RoCEv2, but DCB and PFC are not configured on the switch side. Silent fallback to TCP without warning. iWARP does not have this switch dependency; RoCEv2 does.
• SMB Multichannel over dissimilar NICs (one 25 GbE, one 10 GbE), where the cluster picks the slower path for half the sessions.
• MPIO with Round Robin on an active/passive array that strongly prefers one controller.
• S2D deployments where one node, after a hardware swap, has a deviating drive bay configuration, invisible to the cluster but visible in Storage Spaces health.

Validate with the native tools, production-safe variant without storage disruption:

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

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

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

A full storage validation including the Storage category requires a maintenance window or a separate test LUN that is not in use by a clustered role.

10. No documented DR validation

Stretched or multisite clusters that have never been failed over end-to-end. The runbook exists, the storage replication dashboard is green, and nobody has ever actually tried it in production. A Health Check often surfaces the gap between runbook and reality: DNS TTLs that are too long, application-layer connection strings hardcoded to one site, witness placement that does not survive the test.

We recommend at minimum an annual planned failover, treated as production impact and rehearsed in a maintenance window.

The pattern behind the list

Nine of these ten findings have nothing to do with workload performance. It is silent configuration debt that accumulates over patch cycles, hardware refreshes and staff turnover. It is also exactly the type of finding that monitoring tools miss, because in isolation each setting looks correct: a witness exists, a Live Migration network is configured, CSV ownership is valid. The drift sits in the relationship between settings, and the only reliable way to surface that is a structured external review.

Recognise three or more issues above? You are not alone, and the fix usually costs no more than a single weekly maintenance window.

Plan a Hyper-V Cluster Health Check introduction →

Hyper-V Cluster Health Check: 10 issues die we steeds vinden in 2026

Na jaren van Hyper-V Health Checks in Windows Server 2016, 2019, 2022 en 2025 omgevingen komen tien bevindingen telkens terug. Over branches, schaalgroottes en beheerteams heen. Geen ervan is exotisch. De meeste blijven stil totdat een patch-ronde, een hardware-refresh of één switch-reboot ze om 03:00 's nachts tot een Sev-1 incident maakt.

Dit artikel is de praktijklijst. Per issue de oorzaak, de PowerShell om het te diagnosticeren, en de remediation die wij in het klantgerichte rapport documenteren. Herken je drie of meer in je eigen omgeving? Dat is geen uitschieter, dat is het gemiddelde.

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 één correct staat en de 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 stemt votes dynamisch af 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, tenzij 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 nooit één 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 leidende 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 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 tegen 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-switch ontwerp 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, niet een advies.

Tijdens een Hyper-V Cluster Health Check traceren wij cluster-heartbeat verkeer 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 één controller voorkeurt.
• 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 HealthCheck

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 Health Check 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 Health Check kennismaking →