CSV Ownership Imbalance in Hyper-V Clusters: Causes and FixesCSV ownership onbalans in Hyper-V clusters: oorzaken en oplossingen
After every patch round, every Live Migration storm, every planned failover, Cluster Shared Volume ownership drifts apart. One node ends up owning all the CSVs, becomes coordinator for every metadata operation, and quietly caps read performance for the entire cluster. CSV ownership imbalance is a top three finding in CloudLabs Hyper-V Cluster Health Checks, and also one of the simplest to fix permanently.
This article explains what actually happens under the hood, how to detect it, and how to keep CSVs balanced without constant manual intervention.
- What CSV ownership actually means
- Why ownership drifts, three field patterns
- Performance impact, with numbers
- Diagnosing ownership and traffic
- Manual rebalance, the safe procedure
- Automating rebalance
- Three ways to rebalance: CSV ownership, VMM, and VM alignment
- CSV BlockCache and why it changes the math
- Preventing recurrence
1. What CSV ownership actually means
A Cluster Shared Volume is one NTFS or ReFS volume that all cluster nodes can read and write simultaneously. Behind that simple description sits a coordinator role. One node, the coordinator node, owns the metadata operations of the volume. Allocating space, extending a VHD, creating a snapshot, changing attributes, all of that runs through the coordinator. Other nodes do direct I/O for normal reads and writes, bypassing the coordinator entirely.
This works well when the cluster is balanced. The coordinator role for one CSV asks a small amount of CPU and memory on the owner, so the load spreads naturally. It works poorly when one node owns all CSVs at once. That node then handles metadata work for every workload in the cluster, and any operation that runs through redirected I/O (which happens automatically when direct I/O is impossible) goes through that node.
Two situations force redirected I/O. The local node has lost storage connectivity to the volume (the node has no direct path, so I/O routes over the cluster network to the coordinator, which does still have a path). Or the operation is one that always runs through the coordinator (most metadata operations, some snapshot work, backup software accessing the volume in certain modes).
Redirected I/O is supported and safe. It is also significantly slower than direct I/O and can saturate cluster networks if left unchecked.
2. Why ownership drifts, three field patterns
Pattern 1: the Patch Tuesday parade
CAU (Cluster Aware Updating) drains a node, patches it, brings it back, drains the next one. Each node hands its CSVs to whichever node has capacity at that moment, usually the just-patched node, which has the lowest load. At the end of the run, the last-patched node owns most or all CSVs.
Pattern 2: the midnight failover
An unplanned failover (usually a NIC firmware glitch, a flapping storage path, or a host briefly losing its quorum vote) moves all CSVs from the failing node to one other node. Nobody notices in the morning because workloads are running. The imbalance stays until the next intervention.
Pattern 3: the "I'll set it back later" debug session
An engineer pinned all CSVs to one node to rule out a node-specific issue during an incident, fixed the issue, and never undid the pin. We find PreferredOwners values on CSV resources months after the original incident, with the engineer who set them long gone from the company.
3. Performance impact, with numbers
On a four-node Hyper-V cluster running an average VDI workload, CloudLabs recently measured the impact during a Hyper-V Cluster Health Check.
Workload: 220 VDI desktops, mix of boot storm and steady state. Cluster: 4 × Dell R7625, S2D, all-NVMe, 25 GbE storage.
State A — CSVs balanced (3 per node, 12 CSVs total)
Average read latency: 0.62 ms
P99 read latency: 2.1 ms
Coordinator CPU: 5–8% per node
State B — One node owns all 12 CSVs (post-patch, no rebalance)
Average read latency: 1.08 ms
P99 read latency: 9.4 ms (4.5x worse)
Coordinator CPU: 22–28% on the owner
Storage cluster network: saturated during boot stormIn State B the cluster was technically healthy. Nothing alarmed. The only user-side symptom was complaints about login times, which the ops team was investigating under the working hypothesis of a network problem in the VDI farm. The fix took eight minutes.
A note on where these numbers come from: this was an S2D, all-NVMe cluster, and S2D is where imbalance hits hardest. On S2D the owner node also holds the CSV read cache and a large share of the storage-network routing, so piling every CSV onto one node concentrates metadata, cache locality and routing in the same place at once. On a classic SAN, every node keeps its own direct path to the LUN, so steady-state reads stay direct no matter who owns the CSV, and the read-latency penalty is usually a good deal smaller. What still hurts on SAN is the metadata load on the coordinator and anything that drops into redirected I/O, a node losing a storage path being the common trigger. The imbalance is worth correcting on both architectures, just expect it to surface in different places: steady-state read latency on S2D, metadata-heavy operations and path failures on SAN.
4. Diagnosing ownership and traffic
Three views give the full picture:
# Ownership distribution
Get-ClusterSharedVolume |
Select-Object Name, OwnerNode, State |
Group-Object OwnerNode |
Sort-Object Count -Descending |
Select-Object Name, Count
# Redirected I/O, anything not 'Direct' is suspect
Get-ClusterSharedVolume | ForEach-Object {
[PSCustomObject]@{
Name = $_.Name
Owner = $_.OwnerNode
IOMode = $_.SharedVolumeInfo.Partition.IsBlockIOMode # $true = direct
Redirected = $_.SharedVolumeInfo.RedirectedAccess
}
}
# Coordinator CPU per node, run during a normal workday
Get-Counter -Counter '\Cluster Shared Volume(*)\IO Read Bytes/sec' `
-SampleInterval 5 -MaxSamples 12The CloudLabs Health Check report includes a one-liner per CSV: owner, mode (direct or redirected), average read latency over the inventory window, and a flag if PreferredOwners is set to anything other than default.
5. Manual rebalance, the safe procedure
A manual rebalance is safe during business hours. Move-ClusterSharedVolume transfers the coordinator role without disrupting running VMs, the volume stays available. The only thing that happens is a brief pause in metadata operations on that CSV, measured in milliseconds.
# Identify which CSV to move
Get-ClusterSharedVolume |
Select-Object Name, OwnerNode |
Group-Object OwnerNode |
Where-Object Count -gt 3
# Move one CSV to a specific node
Move-ClusterSharedVolume -Name 'CSV-VDI-Pool-03' -Node 'HV02'
# Move and verify
Move-ClusterSharedVolume -Name 'CSV-VDI-Pool-03' -Node 'HV02' -PassThru |
Select-Object Name, OwnerNode, StateIf you want to drain a node, for example for maintenance, move its CSVs explicitly instead of relying on automatic balancing:
$sourceNode = 'HV01'
$targetNodes = (Get-ClusterNode |
Where-Object {$_.State -eq 'Up' -and $_.Name -ne $sourceNode}).Name
$i = 0
Get-ClusterSharedVolume | Where-Object OwnerNode -eq $sourceNode | ForEach-Object {
$target = $targetNodes[$i % $targetNodes.Count]
Write-Host "Moving $($_.Name) from $sourceNode to $target"
Move-ClusterSharedVolume -Name $_.Name -Node $target
$i++
}If your monitoring stack has never alerted on skewed CSV ownership and your cluster has been patched in the last six months, you are almost certainly out of balance right now. The five-line script above tells you in ten seconds.
A CloudLabs Hyper-V Cluster Health Check maps this alongside nine other quiet issues in two days.
Schedule a Health Check intro call →6. Automating rebalance
Microsoft introduced automatic CSV balancing in Windows Server 2016. It is on by default and works well in most environments. You can verify and tune it:
(Get-Cluster).CsvBalancer
# Values:
# 0 = off
# 1 = always balance (default)
# 2 = balance only when threshold exceeded
# Force immediate re-evaluation
(Get-Cluster).CsvBalancer = 1
$cluster = Get-Cluster
$cluster.CsvBalancer = $cluster.CsvBalancerTwo cases where automatic balancing does not do what you want. CSV resources with explicit PreferredOwners, the balancer respects them. And heterogeneous node sizing, the balancer treats nodes as equals, so if one node has half the RAM/CPU of the others, even balancing distributes the load poorly.
In both cases, a scheduled PowerShell rebalance after maintenance windows is the safer pattern. CloudLabs delivers this as part of the remediation report on every engagement where imbalance is a finding.
7. Three ways to rebalance: CSV ownership, VMM, and VM alignment
"Rebalancing" gets used for three different operations that solve different problems, and it is worth being precise about which one you mean.
- Native CSV balancing (
CsvBalancerandMove-ClusterSharedVolume, above) moves the coordinator role between nodes. It spreads metadata load and, on S2D, cache locality. It moves no VMs and has no opinion on where a VM runs relative to the CSV it lives on. - VMM Dynamic Optimization moves VMs between hosts to balance CPU and memory. It is compute-aware and storage-blind: it will live-migrate a VM onto a node that does not own the VM's CSV, which on S2D quietly adds redirected reads and cross-node storage traffic. Good for compute hotspots, but it can work against storage locality at the same time.
- Aligning VMs with their storage moves VMs the other way: onto the node that owns the CSV their disks live on, so reads stay direct and the coordinator path is short. This is the axis neither CsvBalancer nor VMM touches. CloudLabs runs it from a site-aware placement script built on Darryl van der Peijl's original align-VMs-with-storage idea, with WhatIf safety and a before/after view.
The three are complementary, not competing. A healthy pattern: let CsvBalancer keep coordinator ownership even, let VMM (if you run it) handle compute hotspots, and run an alignment pass after maintenance so VMs sit with their storage rather than wherever the last failover left them. The full write-up of our alignment approach is in Aligning VMs With Their Storage, and the original idea it builds on is Darryl van der Peijl's align VMs with storage script.
8. CSV BlockCache and why it changes the math
CSV BlockCache is a read-side memory cache on each node. When enabled, it dramatically lowers the cost of redirected reads because most are served from local RAM. It does not solve imbalance, but it softens the consequences.
(Get-Cluster).BlockCacheSize # value in MB, 0 = off
# Enable with 2 GB per node, tune to your RAM budget
(Get-Cluster).BlockCacheSize = 2048
# Verify per-CSV cache state
Get-ClusterSharedVolume | ForEach-Object {
$_ | Select-Object Name,
@{N='CacheEnabled';E={$_.SharedVolumeInfo.Partition.IsCsvCacheEnabled}}
}Size BlockCache from your steady-state RAM headroom, not from the N-1 evacuated state. Verify that VM density still fits comfortably under failover conditions. We typically recommend 1 to 4 GB per node on Hyper-V clusters, and 4 to 16 GB on storage-heavy workloads.
Full context on BlockCache trade-offs is in Hyper-V Cluster Health Check: Top 10 Issues We Find in 2026, issue 7.
9. Preventing recurrence
The CloudLabs remediation pattern for CSV ownership imbalance has four parts.
- Remove explicit
PreferredOwnerson every CSV unless there is a documented reason. Most that we find are debug session residue. - Enable CSV BlockCache at 1 to 4 GB per node, and verify enabled state on every CSV partition.
- Add a scheduled rebalance as a post-maintenance step in every runbook. CAU's post-update task list is the right place; if you do not use CAU, your patch automation has to handle it.
- Monitor the ownership distribution as a metric. We add a five-line script to ops dashboards: count of CSVs per node, alarm when one node owns more than
(total / nodes) + 1.
CSV ownership imbalance is the textbook example of a finding that monitoring tools miss because each individual component looks healthy. Surfacing it is exactly what an independent Hyper-V Cluster Health Check is for.
Schedule a Hyper-V Cluster Health Check intro call →
Frequently asked questions
After every patch round, every unplanned failover, and every node drain for maintenance. In practice that comes down to monthly or bi-monthly for most production clusters. Make it part of the standard post-maintenance checklist and nobody forgets.
No. It only transfers the coordinator role, not the volume itself. VMs on the CSV keep running without interruption. There is a brief pause in metadata operations during the handover, measured in milliseconds and invisible to workloads 99% of the time.
Limitedly. Direct writes go straight to storage and do not touch the coordinator. Metadata-heavy operations (VHD extension, snapshots, file creation) do hit the coordinator. On strongly metadata-heavy workloads (Exchange, some database engines with many small files) balancing has more impact than on read-heavy workloads.
Mode 2 balances only when imbalance exceeds an internal threshold, instead of continuously aiming for perfect distribution. Useful on clusters where VMs have PreferredOwners set and you want to avoid the balancer making constant small adjustments that PreferredOwners then undoes.
On Azure Local and Azure Stack HCI with Storage Spaces Direct, CSV BlockCache behaves differently because S2D has its own cache layer on the NVMe tier. For SAN-attached Hyper-V clusters, BlockCache is still very much worth using and is regularly forgotten.
Na elke patch-ronde, na elke Live Migration-storm, na elke geplande failover drijft Cluster Shared Volume ownership uit elkaar. Eén node bezit uiteindelijk alle CSV's, wordt coordinator voor elke metadata-operatie, en begrenst stilletjes de read-performance van het hele cluster. CSV ownership onbalans is een van de top drie bevindingen in CloudLabs Hyper-V Cluster Health Checks, en ook een van de eenvoudigste om permanent op te lossen.
Dit artikel legt uit wat er werkelijk gebeurt onder de motorkap, hoe je het detecteert, en hoe je CSV's gebalanceerd houdt zonder constante handmatige interventie.
- Wat CSV ownership werkelijk betekent
- Waarom ownership scheef raakt, drie praktijkpatronen
- De performance-impact, met cijfers
- Ownership en traffic diagnosticeren
- Handmatige rebalance, de veilige procedure
- Rebalance automatiseren
- Drie manieren om te rebalancen: CSV-ownership, VMM en VM-uitlijning
- CSV BlockCache en waarom dat de wiskunde verandert
- Herhaling voorkomen
1. Wat CSV ownership werkelijk betekent
Een Cluster Shared Volume is één NTFS- of ReFS-volume dat alle cluster-nodes gelijktijdig kunnen lezen en schrijven. Achter die simpele beschrijving zit een coordinator-rol. Eén node, de coordinator-node, bezit de metadata-operaties van het volume. Ruimte alloceren, een VHD uitbreiden, een snapshot maken, attributen wijzigen, dat loopt allemaal via de coordinator. Andere nodes doen direct I/O voor normale reads en writes, en omzeilen de coordinator daarmee volledig.
Dit werkt goed wanneer het cluster gebalanceerd is. De coordinator-rol voor één CSV vraagt een kleine hoeveelheid CPU en geheugen op de eigenaar, dus de load verdeelt zich vanzelf. Het werkt slecht wanneer één node alle CSV's tegelijk bezit. Die node doet dan metadata-werk voor elke workload in het cluster, en elke operatie die wél via redirected I/O loopt (wat automatisch gebeurt als direct I/O onmogelijk is) gaat via die node.
Twee situaties forceren redirected I/O. De storage-connectiviteit naar het volume is op de lokale node verloren (de node heeft geen direct pad, dus I/O wordt over het clusternetwerk gerouteerd naar de coordinator, die het pad nog wel heeft). Of de operatie is er een die altijd via de coordinator loopt (de meeste metadata-operaties, sommige snapshot-werkzaamheden, backup-software die het volume in bepaalde modi benadert).
Redirected I/O wordt ondersteund en is veilig. Het is ook significant trager dan direct I/O en kan cluster-netwerken verzadigen als je het laat lopen.
2. Waarom ownership scheef raakt, drie praktijkpatronen
Patroon 1: de Patch Tuesday-parade
CAU (Cluster Aware Updating) draint een node, patcht hem, brengt hem terug, draint de volgende. Elke node geeft zijn CSV's aan welke node op dat moment capaciteit heeft, meestal de net gepatchte node, die de laagste load heeft. Aan het eind van de run bezit de laatst-gepatchte node de meeste of alle CSV's.
Patroon 2: de middernachtelijke failover
Een ongeplande failover (meestal een NIC-firmware glitch, storage-pad dat flapt, of een host die kort zijn quorum-stem kwijt was) verplaatst alle CSV's van de falende node naar één andere node. Niemand merkt het 's ochtends, want de workloads draaien. De onbalans blijft staan tot de volgende interventie.
Patroon 3: de "ik zet 't later wel terug" debug-sessie
Een engineer pinde alle CSV's op één node om een node-specifiek probleem uit te sluiten tijdens een incident, loste het issue op, en heeft de pin nooit ongedaan gemaakt. We vinden PreferredOwners-waarden op CSV-resources maanden na het oorspronkelijke incident, met de engineer die ze instelde inmiddels niet meer in dienst.
3. De performance-impact, met cijfers
Op een four-node Hyper-V cluster met een gemiddelde VDI-workload heeft CloudLabs in een recente Hyper-V Cluster Health Check de impact gemeten.
Workload: 220 VDI-desktops, mix van boot storm en steady state. Cluster: 4 × Dell R7625, S2D, all-NVMe, 25 GbE storage.
State A — CSV's gebalanceerd (3 per node, 12 CSV's totaal)
Gemiddelde read-latency: 0.62 ms
P99 read-latency: 2.1 ms
Coordinator CPU: 5–8% per node
State B — Eén node bezit alle 12 CSV's (post-patch, geen rebalance)
Gemiddelde read-latency: 1.08 ms
P99 read-latency: 9.4 ms (4.5x slechter)
Coordinator CPU: 22–28% op de eigenaar
Storage-clusternetwerk: verzadigd tijdens boot stormHet cluster was in State B technisch gezond. Niets alarmeerde. Het enige symptoom aan gebruikerszijde was klachten over inlogtijden, die het ops-team aan het onderzoeken was onder de werkhypothese dat er een netwerkprobleem in de VDI-farm zat. De fix kostte acht minuten.
Een kanttekening bij waar deze cijfers vandaan komen: dit was een S2D-cluster, all-NVMe, en S2D is waar onbalans het hardst aankomt. Op S2D houdt de eigenaar-node ook de CSV read-cache en een groot deel van de storage-netwerk-routing vast, dus alle CSV's op één node stapelen concentreert metadata, cache-localiteit en routing tegelijk op dezelfde plek. Op een klassieke SAN houdt elke node zijn eigen directe pad naar de LUN, dus steady-state reads blijven direct ongeacht wie de CSV bezit, en de read-latency-straf is doorgaans een stuk kleiner. Wat op SAN wél pijn doet is de metadata-load op de coordinator en alles wat in redirected I/O belandt, met een node die een storage-pad verliest als veelvoorkomende trigger. De onbalans is op beide architecturen het corrigeren waard, verwacht alleen dat hij op verschillende plekken opduikt: steady-state read-latency op S2D, metadata-zware operaties en pad-failures op SAN.
4. Ownership en traffic diagnosticeren
Drie views geven het volledige beeld:
# Verdeling van ownership
Get-ClusterSharedVolume |
Select-Object Name, OwnerNode, State |
Group-Object OwnerNode |
Sort-Object Count -Descending |
Select-Object Name, Count
# Redirected I/O, alles wat niet 'Direct' is, is verdacht
Get-ClusterSharedVolume | ForEach-Object {
[PSCustomObject]@{
Name = $_.Name
Owner = $_.OwnerNode
IOMode = $_.SharedVolumeInfo.Partition.IsBlockIOMode # $true = direct
Redirected = $_.SharedVolumeInfo.RedirectedAccess
}
}
# Coordinator CPU per node, uitvoeren tijdens een normale werkdag
Get-Counter -Counter '\Cluster Shared Volume(*)\IO Read Bytes/sec' `
-SampleInterval 5 -MaxSamples 12Het CloudLabs Health Check-rapport bevat een one-liner per CSV: owner, mode (direct of redirected), gemiddelde read-latency over het inventarisatie-venster, en een vlag als PreferredOwners op iets anders dan default staat.
5. Handmatige rebalance, de veilige procedure
Een handmatige rebalance is veilig tijdens kantoortijden. Move-ClusterSharedVolume draagt de coordinator-rol over zonder verstoring van draaiende VM's, het volume blijft beschikbaar. Het enige wat gebeurt is een korte pauze in metadata-operaties op die CSV, in milliseconden gemeten.
# Bepaal welke CSV te verplaatsen
Get-ClusterSharedVolume |
Select-Object Name, OwnerNode |
Group-Object OwnerNode |
Where-Object Count -gt 3
# Verplaats één CSV naar een specifieke node
Move-ClusterSharedVolume -Name 'CSV-VDI-Pool-03' -Node 'HV02'
# Verplaatsen en verifiëren
Move-ClusterSharedVolume -Name 'CSV-VDI-Pool-03' -Node 'HV02' -PassThru |
Select-Object Name, OwnerNode, StateWil je een node drainen, bijvoorbeeld voor onderhoud, verplaats dan zijn CSV's expliciet, in plaats van te vertrouwen op automatische balancing:
$sourceNode = 'HV01'
$targetNodes = (Get-ClusterNode |
Where-Object {$_.State -eq 'Up' -and $_.Name -ne $sourceNode}).Name
$i = 0
Get-ClusterSharedVolume | Where-Object OwnerNode -eq $sourceNode | ForEach-Object {
$target = $targetNodes[$i % $targetNodes.Count]
Write-Host "Moving $($_.Name) from $sourceNode to $target"
Move-ClusterSharedVolume -Name $_.Name -Node $target
$i++
}Als jouw monitoring-stack nog nooit gealarmeerd heeft op scheve CSV-ownership en je cluster is in de afgelopen zes maanden gepatcht, dan ben je vrijwel zeker nu uit balans. Het vijfregelige script hierboven vertelt het je binnen tien seconden.
Een CloudLabs Hyper-V Cluster Health Check brengt het samen met negen andere stille issues in twee dagen in kaart.
Plan een Health Check kennismaking →6. Rebalance automatiseren
Microsoft introduceerde automatische CSV-balancing in Windows Server 2016. Het staat default aan en werkt in de meeste omgevingen goed. Je kunt het verifiëren en bijsturen:
(Get-Cluster).CsvBalancer
# Waarden:
# 0 = uit
# 1 = altijd balanceren (default)
# 2 = balanceren alleen bij overschrijden van threshold
# Direct herevalueren forceren
(Get-Cluster).CsvBalancer = 1
$cluster = Get-Cluster
$cluster.CsvBalancer = $cluster.CsvBalancerTwee gevallen waarin automatische balancing niet doet wat je wilt. CSV-resources met expliciete PreferredOwners, de balancer respecteert die. En heterogene node-sizing, de balancer behandelt nodes als gelijken, dus als één node de helft van RAM/CPU van de anderen heeft, verdeelt gelijk balanceren de load slecht.
Voor beide gevallen is een geplande PowerShell-rebalance na onderhoudsvensters het veiligere patroon. CloudLabs levert dit als onderdeel van het remediation-rapport bij elke opdracht waar onbalans een bevinding is.
7. Drie manieren om te rebalancen: CSV-ownership, VMM en VM-uitlijning
'Rebalancing' wordt gebruikt voor drie verschillende operaties die elk een ander probleem oplossen, en het loont om precies te zijn over welke je bedoelt.
- Native CSV-balancing (
CsvBalancerenMove-ClusterSharedVolume, hierboven) verplaatst de coordinator-rol tussen nodes. Het spreidt metadata-load en, op S2D, cache-localiteit. Het verplaatst geen VM's en heeft geen mening over waar een VM draait ten opzichte van de CSV waarop hij staat. - VMM Dynamic Optimization verplaatst VM's tussen hosts om CPU en geheugen te balanceren. Het is compute-bewust en storage-blind: het migreert een VM met Live Migration naar een node die de CSV van die VM niet bezit, wat op S2D stilletjes redirected reads en cross-node storage-verkeer toevoegt. Goed voor compute-hotspots, maar het kan tegelijk tegen storage-localiteit in werken.
- VM's uitlijnen met hun storage verplaatst VM's de andere kant op: naar de node die de CSV bezit waarop hun schijven staan, zodat reads direct blijven en het coordinator-pad kort is. Dit is de as die noch CsvBalancer noch VMM raakt. CloudLabs draait dit vanuit een site-bewust placement-script, gebouwd op het oorspronkelijke align-VMs-with-storage idee van Darryl van der Peijl, met WhatIf-veiligheid en een before/after-weergave.
De drie zijn complementair, niet concurrerend. Een gezond patroon: laat CsvBalancer de coordinator-ownership gelijk houden, laat VMM (als je het draait) compute-hotspots afhandelen, en draai na onderhoud een uitlijn-ronde zodat VM's bij hun storage staan in plaats van waar de laatste failover ze achterliet. De volledige uitwerking van onze uitlijn-aanpak staat in VMs uitlijnen met hun storage, en het oorspronkelijke idee waarop het voortbouwt is het align VMs with storage script van Darryl van der Peijl.
8. CSV BlockCache en waarom dat de wiskunde verandert
CSV BlockCache is een read-side memory-cache op iedere node. Aangezet, verlaagt het de kosten van redirected reads dramatisch, omdat de meeste vanuit lokaal RAM worden geserveerd. Het lost onbalans niet op, maar het verzacht wel de gevolgen ervan.
(Get-Cluster).BlockCacheSize # waarde in MB, 0 = uit
# Aanzetten met 2 GB per node, pas aan op je RAM-budget
(Get-Cluster).BlockCacheSize = 2048
# Per-CSV cache-status verifiëren
Get-ClusterSharedVolume | ForEach-Object {
$_ | Select-Object Name,
@{N='CacheEnabled';E={$_.SharedVolumeInfo.Partition.IsCsvCacheEnabled}}
}Dimensioneer BlockCache vanuit je steady-state RAM-headroom, niet vanuit de N-1 geëvacueerde toestand. Verifieer dat VM-dichtheid nog comfortabel past onder failover-condities. Wij adviseren typisch 1 tot 4 GB per node op Hyper-V clusters en 4 tot 16 GB op storage-zware workloads.
Volledige context over BlockCache trade-offs zit in Hyper-V Cluster Health Check: 10 issues die we steeds vinden in 2026, issue 7.
9. Herhaling voorkomen
Het CloudLabs remediation-patroon voor CSV ownership onbalans heeft vier delen.
- Verwijder expliciete
PreferredOwnersop elke CSV, tenzij er een gedocumenteerde reden is. De meeste die wij vinden zijn residu van debugsessies. - Zet CSV BlockCache aan op 1 tot 4 GB per node en verifieer enabled state op elke CSV-partitie.
- Voeg een geplande rebalance toe als post-maintenance stap in elk runbook. CAU's post-update tasklist is de juiste plek, gebruik je geen CAU, dan moet je patch-automatisering het regelen.
- Monitor de ownership-verdeling als metriek. We voegen een script van vijf regels toe aan ops-dashboards: aantal CSV's per node, alarm als één node meer dan
(totaal / nodes) + 1bezit.
CSV ownership onbalans is het schoolvoorbeeld van een bevinding die monitoring-tools missen omdat elk individueel onderdeel er gezond uitziet. Het zichtbaar maken is precies waar een onafhankelijke Hyper-V Cluster Health Check voor is.
Plan een Hyper-V Cluster Health Check kennismaking →
Veelgestelde vragen
Na elke patch-ronde, na elke ongeplande failover, en na elke node-drain voor onderhoud. In de praktijk komt dat neer op maandelijks tot tweemaandelijks in de meeste productie-clusters. Maak het onderdeel van de standaard post-maintenance checklist, dan vergeet niemand het.
Nee. Het verplaatst alleen de coordinator-rol, niet het volume zelf. VM's op het CSV blijven draaien zonder onderbreking. Wel is er een paar milliseconden pauze in metadata-operaties tijdens de overdracht, wat in 99% van de gevallen onzichtbaar is voor workloads.
Beperkt. Direct writes gaan rechtstreeks naar storage en raken de coordinator niet. Wel raken metadata-zware operaties (VHD-uitbreiding, snapshots, file-creatie) de coordinator. Bij sterk metadata-zware workloads (Exchange, sommige database-engines met veel kleine bestanden) heeft balancing meer impact dan bij read-heavy workloads.
Mode 2 balanceert alleen wanneer de onbalans een interne drempel overschrijdt, in plaats van continu te streven naar perfecte verdeling. Nuttig op clusters waar VM's met PreferredOwners zijn ingesteld en je wilt voorkomen dat de balancer constant kleine optimalisaties doet die door PreferredOwners weer worden ongedaan gemaakt.
Op Azure Local en Azure Stack HCI met Storage Spaces Direct werkt CSV BlockCache anders, omdat S2D zijn eigen cache-laag heeft op de NVMe-tier. Voor SAN-attached Hyper-V clusters is BlockCache nog steeds zinvol en wordt het regelmatig vergeten.