Ein anonymisierter Praxisbericht aus einem Hyper-V-Failovercluster: Mehrere virtuelle Maschinen meldeten kritische E/A-Zustände, Cluster Shared Volumes liefen dauerhaft im Modus „Online (Umgeleiteter Zugriff)“, und zunächst deutete vieles auf ein SAN- oder SAS-Problem hin. Die entscheidende Spur führte jedoch zu einem unerwartet geladenen Windows-Dateisystemfilter.

image-1024x682 Hyper-V CSV „Online (Umgeleiteter Zugriff)“: WIMMount als Ursache
Zwei anonymisierte Hyper-V-Knoten mit gemeinsamem Storage: fehlerhafter umgeleiteter Zugriff gegenüber gesundem direktem Datenpfad.

Transparenzhinweis: Dieser Beitrag basiert auf einem realen Praxisfall. Kunden-, Personen-, Host-, IP-, Standort-, Seriennummern- und Geräteinformationen wurden entfernt oder verallgemeinert. Einzelne technische Details wurden zur besseren Lesbarkeit vereinfacht.

Die Ausgangssituation

Die Umgebung bestand vereinfacht aus zwei Windows-Server-Hyper-V-Knoten, einem Failovercluster und einem dualen SAS-Storage-System. Die virtuellen Maschinen lagen auf zwei Cluster Shared Volumes, kurz CSV.

C:\ClusterStorage\Volume1
C:\ClusterStorage\Volume2

Beide CSV-Mountpunkte befanden sich als Partitionen auf derselben Storage-LUN. Damit waren die beiden sichtbaren Volumes keine unabhängigen Storage-Fehlerdomänen:

Shared Storage LUN
├── Partition 1 → CSV Volume1
└── Partition 2 → CSV Volume2

Ein Fehler der LUN, der Cluster-Datenträgerressource oder ihrer Persistent Reservation konnte somit beide CSV-Volumes und alle darauf gespeicherten virtuellen Maschinen gleichzeitig betreffen.

Die Symptome

Während des Incidents traten mehrere Auffälligkeiten auf:

  • Virtuelle Maschinen wechselten in kritische E/A-Zustände.
  • Einzelne VM-Ressourcen blieben vorübergehend in OnlinePending oder schlugen fehl.
  • Clusterrollen wurden verschoben oder neu gestartet.
  • Ein interner Clusterdienst-Vorgang überschritt seinen Timeout.
  • Das Freigeben einer SCSI Persistent Reservation schlug fehl.
  • Der CSV-Datenträger wurde als Online (Umgeleiteter Zugriff) angezeigt.

Die erste entscheidende Abfrage war:

Import-Module FailoverClusters

Get-ClusterSharedVolumeState |
    Sort-Object Node,VolumeFriendlyName |
    Format-List Node,
        VolumeFriendlyName,
        StateInfo,
        BlockRedirectedIOReason,
        FileSystemRedirectedIOReason

Die Ausgabe war auf beiden Knoten und beiden Volumes identisch:

StateInfo                    : FileSystemRedirected
BlockRedirectedIOReason      : NotBlockRedirected
FileSystemRedirectedIOReason : IncompatibleFileSystemFilter

Damit war klar: Der Redirected-Modus war keine bloße manuelle Administratoranforderung. Windows hatte einen Dateisystemfilter erkannt, der Direct I/O für CSV verhinderte.

Was bedeutet CSV Redirected I/O?

Im Normalzustand greift jeder Hyper-V-Knoten direkt über seinen Storagepfad auf das CSV zu:

Hyper-V-Knoten 1 ── SAS ── Shared Storage
Hyper-V-Knoten 2 ── SAS ── Shared Storage

Bei File-System-Redirected-I/O wird der Dateisystemzugriff über den koordinierenden CSV-Knoten geleitet:

Hyper-V-Knoten 1
        │
        │ Clusternetzwerk
        ▼
Hyper-V-Knoten 2
        │
        │ SAS
        ▼
Shared Storage

Der Zugriff bleibt dadurch grundsätzlich möglich. Gleichzeitig steigen jedoch die Abhängigkeit vom koordinierenden Knoten und die Last auf dem Clusternetzwerk. Der Redirected-Modus ist eine vorgesehene Schutz- und Kompatibilitätsfunktion, sollte aber nicht dauerhaft und unbemerkt bestehen bleiben.

[Vorher-Nachher-Grafik hier einfügen: 2f15688b92.png]

Vorher: CSV-I/O wird wegen eines inkompatiblen Dateisystemfilters umgeleitet. Nachher: Der direkte Zugriff auf das Shared Storage ist wieder möglich.

Die erste Verdachtsrichtung: SAN, SAS und MPIO

Durch kritische E/A-Zustände und einen Fehler beim Freigeben der Persistent Reservation lag zunächst ein Problem im Storagepfad nahe. Deshalb wurde der Datenträgerzustand auf beiden Knoten geprüft:

Get-Disk |
    Format-Table Number,
        FriendlyName,
        BusType,
        OperationalStatus,
        HealthStatus,
        IsOffline -Auto

Der gemeinsame SAS-Datenträger wurde auf beiden Knoten als online und gesund angezeigt.

Zusätzlich fiel auf, dass Multipath I/O nicht installiert war:

Get-WindowsFeature Multipath-IO

Das war in der vorhandenen Verkabelung nicht automatisch falsch, denn pro Host war nur ein SAS-Pfad angeschlossen. Für eine spätere redundante Kreuzverkabelung zu beiden Storage-Controllern müsste MPIO jedoch vor dem Anschluss zusätzlicher SAS-Pfade eingerichtet und validiert werden.

Der fehlende zweite Pfad erklärte aber nicht die konkrete Meldung IncompatibleFileSystemFilter. Damit rückte der Windows-Filterstack in den Mittelpunkt.

Den verursachenden Filter identifizieren

Die erste Übersicht lieferte fltmc:

fltmc filters

Auf den Hosts waren erwartungsgemäß mehrere Filter aktiv, darunter Windows-, Backup- und Security-Komponenten. Die bloße Filterliste zeigte jedoch noch nicht, welchen Filter CSV konkret ablehnte.

Deshalb wurden die Clusterlogs erzeugt:

New-Item -Path C:\Temp -ItemType Directory -Force | Out-Null

Get-ClusterLog `
    -UseLocalTime `
    -TimeSpan 60 `
    -Destination C:\Temp

Anschließend erfolgte die gezielte Suche:

Select-String `
    -Path C:\Temp\*.log `
    -Pattern "IncompatibleFileSystemFilter",
             "active filter drivers",
             "Gefundene aktive Filtertreiber" `
    -Context 0,4

Das Ergebnis war eindeutig:

Gefundene aktive Filtertreiber:
WIMMount (HSM)

Die entscheidende Falle: CSVFS ist nicht das NTFS-Unterbauvolume

Eine Abfrage gegen den sichtbaren CSV-Mountpunkt zeigte WIMMount zunächst nicht:

fltmc instances -v C:\ClusterStorage\Volume1

Das hätte leicht zur falschen Schlussfolgerung führen können, dass WIMMount nicht beteiligt sei. Entscheidend war die Unterscheidung zwischen dem sichtbaren CSVFS-Pseudovolume und dem darunterliegenden NTFS-Volume.

CSV-Mountpunkt
        ↓
CSVFS-Pseudovolume
        ↓
NTFS-Unterbauvolume
        ↓
Storage-LUN

Mit:

fltmc volumes

wurden die CSVFS- und NTFS-Ebenen sichtbar. Anschließend ließ sich WIMMount direkt auf den NTFS-Unterbauvolumes nachweisen:

fltmc instances -v \Device\HarddiskVolumeX
fltmc instances -v \Device\HarddiskVolumeY

Die beispielhafte Filterreihenfolge enthielt:

CsvFlt
ResumeKeyFilter
VeeamFCT
WIMMount
bfs
svhdxflt

Damit passten Clusterlog und Filterstack zusammen.

Was ist WIMMount?

WIMMount ist ein Windows-Dateisystemtreiber zum Bereitstellen von Windows Imaging Format-Dateien. Auf beiden Clusterknoten war der Treiber geladen, obwohl keine regulär eingebundenen WIM-Images ermittelt wurden:

Get-WindowsImage -Mounted

Die Abfrage lieferte auf beiden Knoten keine aktiven Bereitstellungen. Trotzdem hing WIMMount auf den produktiven NTFS-Unterbauvolumes der CSVs.

Das bedeutete nicht automatisch, dass der Treiber defekt war. Für diesen konkreten CSV-Stack wurde der aktive Filter jedoch vom Cluster als inkompatibel bewertet und Direct I/O deshalb verhindert.

Der kontrollierte Lösungsweg

Wichtig: Die folgenden Schritte wurden in einem abgestimmten Wartungsfenster mit ausgeschalteten VMs durchgeführt. Ein Dateisystemfilter auf produktiven CSV-Unterbauvolumes sollte nicht unkontrolliert im laufenden Betrieb entladen oder deaktiviert werden.

1. Wartungsfenster vorbereiten

  • Backup-Jobs anhalten.
  • Virtuelle Maschinen kontrolliert herunterfahren.
  • Kritische Infrastruktur-VMs zuletzt stoppen.
  • Storage- und Clusterzustand dokumentieren.
  • Immer nur einen Clusterknoten gleichzeitig behandeln.

2. Sicherstellen, dass keine WIM-Images gemountet sind

Invoke-Command -ComputerName HVNODE01,HVNODE02 {
    [pscustomobject]@{
        ComputerName  = $env:COMPUTERNAME
        MountedImages = @(
            Get-WindowsImage -Mounted -ErrorAction SilentlyContinue
        ).Count
    }
}

Erwarteter Wert:

MountedImages : 0

3. WIMMount kontrolliert stoppen

Zuerst auf dem Nicht-Eigentümerknoten, danach auf dem CSV-Eigentümerknoten:

Invoke-Command -ComputerName HVNODE01 {
    sc.exe stop WIMMount
}

Invoke-Command -ComputerName HVNODE02 {
    sc.exe stop WIMMount
}

Danach kontrollieren:

Invoke-Command -ComputerName HVNODE01,HVNODE02 {
    sc.exe query WIMMount
    fltmc.exe instances -f WIMMount
}

Der Treiber war anschließend gestoppt und nicht mehr im Filter-Manager vorhanden. Der CSV-Zustand blieb zunächst trotzdem auf FileSystemRedirected. Das bloße Stoppen hatte also noch keine vollständige Neubewertung des CSV-Stacks ausgelöst.

4. Erneutes Laden beim Neustart verhindern

Invoke-Command -ComputerName HVNODE01,HVNODE02 {
    sc.exe config WIMMount start= disabled
}

Kontrolle:

Invoke-Command -ComputerName HVNODE01,HVNODE02 {
    sc.exe qc WIMMount
    sc.exe query WIMMount
}

Erwarteter Zustand:

START_TYPE : DISABLED
STATE      : STOPPED

5. Rolling Restart durchführen

Zuerst wurde der Nicht-Eigentümerknoten neu gestartet. Nach dessen Rückkehr wurden Clusterbeitritt, Filterstatus und Storagezustand geprüft.

Restart-Computer -ComputerName HVNODE01 -Force

Nach der Rückkehr:

Get-ClusterNode |
    Format-Table Name,State -Auto

Invoke-Command -ComputerName HVNODE01 {
    sc.exe qc WIMMount
    sc.exe query WIMMount
    fltmc.exe filters

    Get-Disk |
        Format-Table Number,
            FriendlyName,
            BusType,
            OperationalStatus,
            HealthStatus,
            IsOffline -Auto
}

6. Direct I/O validieren

Die erneute CSV-Prüfung zeigte den entscheidenden Unterschied:

StateInfo                    : Direct
BlockRedirectedIOReason      : NotBlockRedirected
FileSystemRedirectedIOReason : NotFileSystemRedirected

Der Zielzustand galt für beide CSV-Volumes auf beiden Clusterknoten.

7. CSV-Eigentümerschaft testen

Move-ClusterSharedVolume `
    -Name "Cluster Disk 1" `
    -Node HVNODE01

Die Ressource blieb online und es traten keine neuen Storage-, CSVFS- oder Persistent-Reservation-Fehler auf.

[Troubleshooting-Flow hier einfügen: 23005dced1.png]

Vom Symptom über Clusterlog- und Filteranalyse bis zur kontrollierten Wiederherstellung von CSV Direct I/O.

Vorher und nachher

Vorher

WIMMount auf NTFS-Unterbauvolume aktiv
        ↓
Cluster erkennt inkompatiblen Dateisystemfilter
        ↓
Direct I/O wird verhindert
        ↓
CSV arbeitet mit FileSystemRedirected
        ↓
I/O kann über das Clusternetzwerk laufen

Nachher

WIMMount gestoppt und vorübergehend deaktiviert
        ↓
Nicht-Eigentümerknoten kontrolliert neu gestartet
        ↓
CSV- und Filterstack neu initialisiert
        ↓
IncompatibleFileSystemFilter verschwindet
        ↓
Volume1 und Volume2 arbeiten wieder mit Direct I/O

Kompakte PowerShell-Checkliste

CSV-Zustand

Import-Module FailoverClusters

Get-ClusterSharedVolume |
    Format-Table Name,State,OwnerNode -Auto

Get-ClusterSharedVolumeState |
    Sort-Object Node,VolumeFriendlyName |
    Format-List Node,
        VolumeFriendlyName,
        StateInfo,
        BlockRedirectedIOReason,
        FileSystemRedirectedIOReason

Filter

fltmc filters
fltmc instances -f WIMMount
fltmc volumes

Clusterlogs

Get-ClusterLog `
    -UseLocalTime `
    -TimeSpan 60 `
    -Destination C:\Temp

Select-String `
    -Path C:\Temp\*.log `
    -Pattern "IncompatibleFileSystemFilter",
             "active filter drivers",
             "WIMMount" `
    -Context 0,4

Datenträger auf beiden Knoten

Invoke-Command -ComputerName HVNODE01,HVNODE02 {
    Get-Disk |
        Format-Table Number,
            FriendlyName,
            BusType,
            OperationalStatus,
            HealthStatus,
            IsOffline -Auto
}

Relevante Ereignisse

Get-WinEvent -LogName System -MaxEvents 500 |
    Where-Object {
        $_.TimeCreated -gt (Get-Date).AddMinutes(-30) -and
        (
            $_.ProviderName -match
                "FailoverClustering|CsvFs|Disk|StorPort" -or
            $_.Id -in 5120,5121,5142,5144,1069,1205,1795
        )
    } |
    Sort-Object TimeCreated |
    Format-List TimeCreated,
        ProviderName,
        Id,
        LevelDisplayName,
        Message

Was diese Lösung nicht automatisch behebt

Persistent Reservations

Der ursprüngliche Incident enthielt auch einen Fehler beim Freigeben einer SCSI Persistent Reservation. Das kann ein Folgefehler der Clusterstörung gewesen sein, muss aber unabhängig auf Controller-, Treiber-, SAS- und Storageebene bewertet werden. Aus dem erfolgreichen WIMMount-Test allein folgt nicht, dass sämtliche Storageereignisse dieselbe Ursache hatten.

Fehlende SAS-Pfadredundanz

Ein einzelner SAS-Pfad pro Host stellt keine echte Pfadredundanz dar. Ein zukünftiges Zielbild sollte redundante Verbindungen zu beiden Storage-Controllern, MPIO und einen kontrollierten Pfad- und Controller-Failovertest umfassen.

Fehlender Quorumzeuge

Ein Zwei-Knoten-Cluster sollte einen geeigneten Witness besitzen. Infrage kommen je nach Umgebung Cloud Witness, File Share Witness oder ein dedizierter Disk Witness auf einer eigenen LUN. Das produktive CSV-Storage sollte nicht zugleich als Quorum-Datenträger zweckentfremdet werden.

Gemeinsame Fehlerdomäne

Zwei Partitionen derselben LUN sind organisatorisch zwei CSV-Mountpunkte, aber keine getrennten Storage-Fehlerdomänen. Kritische Workloads sollten perspektivisch auf getrennte LUNs und Cluster-Datenträgerressourcen verteilt werden.

Clusterkommunikation

Während der Wartung wurde zusätzlich ein instabiles Direct-Link-Netzwerk sichtbar. Heartbeat, Live Migration, Management und möglicher Redirected-I/O-Verkehr sollten klar geplant, ausreichend dimensioniert und sinnvoll redundant ausgelegt werden.

Datenintegrität

Nach kritischen E/A-Zuständen genügt es nicht, nur den Cluster wieder online zu bringen. Zusätzlich sollten Dateisystemereignisse, Datenbankkonsistenz, Anwendungslogs, fehlende Dateien, Backupkonsistenz und der erste vollständige Sicherungslauf nach der Wiederherstellung geprüft werden.

Lessons Learned

Nicht jeder Redirected Access ist ein SAN-Ausfall

Online (Redirected) beschreibt zunächst den E/A-Modus. Der konkrete Grund steht in Get-ClusterSharedVolumeState. IncompatibleFileSystemFilter führt in eine andere Richtung als ein fehlender Storagepfad oder eine bewusste Administratoranforderung.

Die Clusterlogs liefern oft den entscheidenden Namen

fltmc filters zeigt alle geladenen Filter. Die Clusterlogs können jedoch konkret benennen, welcher Filter CSV zur Umleitung veranlasst.

CSVFS und NTFS-Unterbau getrennt prüfen

Ein Filter kann auf dem darunterliegenden NTFS-Volume aktiv sein, ohne bei einer Abfrage gegen den sichtbaren CSVFS-Mountpunkt aufzutauchen.

Jeder Schritt braucht ein messbares Erfolgskriterium

In diesem Fall war das eindeutige Ziel:

StateInfo                    : Direct
BlockRedirectedIOReason      : NotBlockRedirected
FileSystemRedirectedIOReason : NotFileSystemRedirected

Infrastrukturänderungen nicht vermischen

Firmwareupdate, MPIO, SAS-Verkabelung, Quorum, Filtertreiber und Netzwerkumbau sollten nicht gleichzeitig verändert werden. Kleine, kontrollierte Schritte mit Prüfung und Abbruchkriterien erleichtern Ursachenanalyse und Rollback.

Fazit

Der Fall begann mit kritischen VM-E/A-Zuständen und dem Verdacht auf ein Storageproblem. Der dauerhaft sichtbare Fehler wurde jedoch durch einen unerwartet geladenen Windows-Dateisystemfilter verursacht.

Die Kombination aus:

Online (Redirected)
FileSystemRedirected
IncompatibleFileSystemFilter
WIMMount (HSM)

führte zur eigentlichen Ursache des permanenten Redirected-I/O.

Das Stoppen des Filters allein genügte nicht. Erst das vorübergehende Deaktivieren von WIMMount und die kontrollierte Neuinitialisierung des betroffenen Knotens stellten Direct I/O wieder her.

Bei dauerhaftem CSV Redirected Access nicht vorschnell ausschließlich SAN, HBA oder Netzwerk verdächtigen. Get-ClusterSharedVolumeState, die NTFS-Unterbauvolumes und die Clusterlogs liefern häufig die entscheidende Spur.

Nach der Maßnahme arbeiteten beide CSV-Volumes auf beiden Clusterknoten wieder im direkten E/A-Modus. Die Storage-LUN war online und gesund, und die CSV-Eigentümerschaft ließ sich ohne neue Storagefehler verschieben.

Der Incident war damit stabilisiert, aber noch nicht architektonisch abgeschlossen. Quorum, MPIO, redundante SAS-Pfade, getrennte Storage-Fehlerdomänen, ein belastbares Clusternetzwerk und eine dokumentierte Langzeitstrategie für WIMMount bleiben wichtige Folgemaßnahmen.

Weiterführende Quellen

Alle technischen Bezeichnungen der ursprünglichen Kundenumgebung wurden anonymisiert. Die gezeigten Befehle sind Beispiele und müssen vor dem Einsatz in einer produktiven Umgebung geprüft werden.
Dieser Beitrag wurde unter Verwendung von KI-Tools erstellt und redaktionell geprüft.