Kompatibilität der VirtIO-Win-Treiber mit MS-SQL-Server-Workloads

Bekanntes Kompatibilitätsproblem mit VirtIO-Win-Treibern bei Windows-VMs mit MS SQL Server unter hoher I/O-Last, einschließlich empfohlener Version, Prüfschritten und eines sauberen Downgrade-Verfahrens.

Überblick

Wichtige Punkte

• virtio-win v0.1.285 und v0.1.292 enthalten eine Race Condition in den vioscsi und viostor Speichertreiber, die sich auf stark ausgelasteten MS SQL Server-VMs bemerkbar machen
• v0.1.271 ist die letzte Version vor dem betroffenen Commit und die empfohlene Version für Windows-Gäste mit Datenbank-Workloads
• Die Symptome sind am stärksten ausgeprägt auf Windows Server 2025 Gästen unter anhaltenden parallelen I/O-Operationen
• Der Upstream-Fix wurde im Januar 2026 übernommen; spätere virtio-win-Versionen, die ihn enthalten, sollten ebenfalls sicher sein — prüfen Sie den Build, bevor Sie ihn breit ausrollen
• Erstellen Sie einen Snapshot der VM und stoppen Sie die SQL Server-Dienste, bevor Sie die Speichertreiber ändern

Windows-VMs, auf denen MS SQL Server unter VergeOS läuft, können einen Strom von SQL Server-"read-retry"-Protokolleinträgen erzeugen — und in einigen Fällen nach einigen Tagen anhaltender Last einen hängenden SQL Server-Dienst — wenn der Gast virtio-win v0.1.285 oder v0.1.292. Die Grundursache ist eine nicht-atomare SRB-ID-Zuweisung in den vioscsi/viostor Storport-Miniports, die doppelte IDs zulassen, wenn Windows I/O parallel über mehrere CPUs verteilt wird (upstream als virtio-win issue #1453).

Das Verhalten lässt sich am zuverlässigsten auf Windows Server 2025 weil seine Storport-Implementierung StartIo aggressiver parallelisiert als frühere Windows Server-Versionen. Ältere Windows-Gäste sind von demselben Fehler betroffen, lösen ihn aber seltener aus.

Ein Downgrade der virtio-win-Treiber des Gasts auf v0.1.271 ist ein stabiler Workaround. Ein Fix für die zugrunde liegende Race Condition wurde upstream zusammengeführt und in neueren virtio-win-Builds ausgeliefert, daher sollten auch spätere Releases, die ihn enthalten, sicher sein — bestätigen Sie vor einem Upgrade während des Vorfalls mit dem VergeOS-Support, welche Builds in Ihrer Umgebung als vertrauenswürdig gelten.

Symptome

Wenn Sie dieses Problem auf einer VergeOS-Windows-VM vermuten, suchen Sie im Anwendung Ereignisprotokoll und im SQL Server-Fehlerprotokoll:

• nach Read-retry-Meldungen, bei denen die erwarteten und tatsächlichen Werte identisch sind, zum Beispiel:

  Ein Lesezugriff auf die Datei '*.mdf' bei Offset 0x... war nach 1 fehlgeschlagenen Versuch(en) mit Fehler erfolgreich: falsche Prüfsumme (erwartet: 0xad4c6778; tatsächlich: 0xad4c6778)

  Ein Lesezugriff auf die Datei '*.mdf' bei Offset 0x... war nach 1 fehlgeschlagenen Versuch(en) mit Fehler erfolgreich: falsche PageID (erwartet 1:29669944; tatsächlich 1:29669944)

• Kein SRB für ID gefunden Einträgen aus der vioscsi Quelle
• Hängende SQL Server-Dienste nach mehreren Tagen anhaltender hoher Last

Diese Meldungen können wie eine Beschädigung aussehen, sind es aber in der Regel nicht

SQL Server meldet das Retry Ergebnis, das beim zweiten Versuch erfolgreich ist. DBCC CHECKDB ist in der Regel sauber — die Datenbankseiten auf der Festplatte sind intakt. Der Treiber liefert beim ersten Lesevorgang aufgrund der doppelten SRB-ID den falschen Puffer, und der zweite Lesevorgang gibt die korrekten Daten zurück. Dauerhafte Wiederholungen weisen dennoch auf ein echtes Problem hin und sollten behoben werden, auch wenn keine Beschädigung erkannt wird.

Voraussetzungen

• Eine Windows-VM, auf der MS SQL Server (oder eine ähnlich I/O-intensive Datenbank-Workload) auf VergeOS läuft
• Administrativer Zugriff auf den Windows-Gast
• Ein Snapshot der VM, der vor dem Ändern von Treibern erstellt wurde
• Der virtio-win v0.1.271 ISO in Ihre VergeOS-Umgebung unter Dateien. Archivierte ISOs sind verfügbar im stable-virtio-Archiv bei Fedora People

Die installierte VirtIO-Treiberversion ermitteln

Bevor Sie etwas ändern, bestätigen Sie, welchen virtio-win-Build der Gast derzeit verwendet.

1. Geräte-Manager öffnen

   • Klicken Sie mit der rechten Maustaste auf das Startmenü und wählen Sie Geräte-Manager.
2. VirtIO-Speichercontroller suchen

   • Erweitern Sie Speichercontroller.
   • Klicken Sie mit der rechten Maustaste auf Red Hat VirtIO SCSI-Controller (für vioscsi) oder Red Hat VirtIO SCSI Pass-through-Controller / Red Hat VirtIO SCSI-Festplattengerät (für viostor) und wählen Sie Eigenschaften.
3. Treiberversion und -datum prüfen

   • Wechseln Sie zur Treiber Registerkarte.
   • Notieren Sie die Treiberversion und Treiberdatum Felder.
4. Mit dem Quell-ISO abgleichen

   • Der Versionsstempel des Treibers folgt dem 100.<minor>.<build>.<revision> Format, wobei die abschließende Revisionskomponente aus der virtio-win-ISO-Version erstellt wird. Beispielsweise endet ein vioscsi Treiber von virtio-win 0.1.285 endet normalerweise auf .28500; 0.1.271 endet normalerweise auf .27100.
   • Wenn Sie unsicher sind, welche ISO den installierten Treiber erzeugt hat, binden Sie die in Frage kommende ISO im Gast ein und vergleichen Sie ihre vioscsi.inf / viostor.inf DriverVer Zeile mit dem in Geräte-Manager angezeigten Wert.

Sowohl vioscsi als auch viostor prüfen

Der Upstream-Fehler betrifft sowohl die vioscsi (Virtio SCSI) und viostor (Virtio-Block)-Treiber. Wenn die VM für die OS-Disk einen Bustyp und für die Datenträger den anderen verwendet, prüfen Sie beide Controller.

Empfohlene Versionen

Version	Status
v0.1.271	Empfohlener Workaround. Letzte Version vor dem betroffenen Commit; unter hoher SQL-Last als stabil bestätigt.
v0.1.285	Vermeiden. Enthält den vioscsi/viostor SRB-ID-Race; erzeugt Read-retry-Fehler auf stark ausgelasteten SQL-VMs.
v0.1.292	Vermeiden. Der gleiche Fehler wie v0.1.285.
Builds nach dem Upstream-Fix (ab Jan. 2026)	Sollte grundsätzlich sicher sein. Bestätigen Sie den konkreten Build mit dem VergeOS-Support, bevor Sie ihn bereitstellen.

Die Downloads der stabilen virtio-win-ISOs sind verfügbar im Fedora People stable-virtio-Repository, und ältere Versionen im archive-virtio-Verzeichnis.

Downgrade auf virtio-win v0.1.271

Erstellen Sie zuerst einen Snapshot

Bevor Sie im Gast einen virtio-Treiber ändern, erstellen Sie einen VergeOS-Snapshot der VM. Der Storage-Stack ist bootkritisch — der Snapshot ist Ihr Rücksetzpunkt, falls der Treibertausch dazu führt, dass Windows seine Datenträger nicht mehr einhängen kann.

1. MS SQL Server-Dienste im Gast stoppen

   • Stoppen Sie in einer erhöhten PowerShell oder der Dienste-Konsole den SQL Server (MSSQLSERVER) Dienst und alle abhängigen Dienste (SQL-Agent, Volltextsuche, Reporting Services usw.), um I/O vor dem Ändern des Speichertreibers zu beruhigen.
2. Mounten Sie die virtio-win-v0.1.271-ISO

   • Bearbeiten Sie in VergeOS die VM und hängen Sie virtio-win-0.1.271.iso als CD/DVD-Gerät ein.
   • Bestätigen Sie, dass die ISO in Windows sichtbar ist (typischerweise der nächste verfügbare Laufwerksbuchstabe).
3. Aktuelle virtio-win-Gasttools deinstallieren

   • Öffnen Sie Einstellungen → Apps & Features (oder Programme und Features in der Systemsteuerung) im Gast.
   • Suchen Sie Virtio-win-guest-tools und wählen Sie Deinstallieren. Folgen Sie den Anweisungen und starten Sie neu, falls dazu aufgefordert wird.
   • Wenn die Deinstallation fehlschlägt oder mit Fehler 0x80070643 (ein bekanntes Problem beim Entfernen von virtio-win-guest-tools), verwenden Sie Microsofts Programminstallations- und -Deinstallations-Problembehandlung um die Registrierung zu bereinigen, bevor Sie fortfahren.
4. Starten Sie die VM neu

   • Starten Sie Windows neu, damit alle gerade verwendeten Treiberdateien freigegeben werden. Die VM sollte weiterhin booten — Windows behält die Storage-Treiber-Binärdateien, bis das neue Paket installiert ist.
5. Installieren Sie virtio-win-guest-tools von der v0.1.271-ISO

   • Führen Sie von der eingehängten v0.1.271-ISO aus virtio-win-guest-tools.exe (oder virtio-win-gt-x64.msials Administrator aus.
   • Schließen Sie die Installation mit der Standardauswahl der Komponenten ab. Dadurch werden vioscsi, viostor, NetKVM und der Gast-Agent mit dem Build v0.1.271 neu installiert.
6. Starten Sie die VM erneut neu

   • Starten Sie Windows neu, damit die Storage- und Netzwerkschichten mit den heruntergestuften Treibern neu geladen werden.
7. Neue Treiberversion überprüfen

   • Zurück zu Geräte-Manager → Speichercontroller, öffnen Sie die Eigenschaften → Treiber Registerkarte und bestätigen Sie, dass die Treiberversion nun den Build v0.1.271 widerspiegelt (typischerweise endend auf .27100).
   • Wiederholen Sie dies für alle anderen VirtIO-Controller und für den Red Hat VirtIO Ethernet-Adapter unter Netzwerkadapter.
8. Starten Sie die MS SQL Server-Dienste

   • Starten Sie den SQL Server-Dienst und alle abhängigen Dienste und bestätigen Sie, dass die Datenbanken sauber online kommen.
9. Unter Last überwachen

   • Nehmen Sie die normalen Workloads wieder auf und beobachten Sie das SQL Server-Fehlerprotokoll und das Windows-Anwendungsprotokoll auf die oben beschriebenen Read-retry-Meldungen. Ein stabiler Betrieb ohne Retries ist das Erfolgskriterium.

Fehlerbehebung

Häufige Probleme

• Installer meldet „neuere Version bereits installiert“ — Das virtio-win-MSI führt kein In-Place-Downgrade durch. Schließen Sie den Deinstallationsschritt ab (und starten Sie neu), bevor Sie den v0.1.271-Installer ausführen.
• Deinstallation schlägt mit Fehler 0x80070643 fehl — Eine bekannte Eigenheit von virtio-win-guest-tools. Verwenden Sie Microsofts Programminstallations- und -Deinstallations-Problembehandlung um den fehlgeschlagenen Installer-Zustand zu bereinigen, starten Sie neu und versuchen Sie die v0.1.271-Installation erneut.
• VM bootet nach Treiberänderung nicht mehr — Stellen Sie den in den Voraussetzungen erstellten Snapshot wieder her und wiederholen Sie den Vorgang, nachdem die SQL Server-Dienste zuvor vollständig beendet wurden.
• Speichercontroller zeigt ein gelbes Ausrufezeichen im Geräte-Manager — Der Treiber wurde nicht sauber geladen. Klicken Sie mit der rechten Maustaste auf den Controller und wählen Sie Treiber aktualisieren → Auf meinem Computer suchen, und verweisen Sie auf den Ordner auf der v0.1.271-ISO, der zu Ihrer Windows-Version passt (z. B. vioscsi\\2k25\\amd64 für Windows Server 2025).
• Read-retry-Meldungen bleiben nach dem Downgrade bestehen — Überprüfen Sie, dass beide vioscsi und viostor (je nachdem, was die VM verwendet) jetzt im Geräte-Manager den Build v0.1.271 anzeigen. Wenn das der Fall ist und die Meldungen weiterhin auftreten, erfassen Sie einen frischen Ausschnitt des Anwendungsprotokolls und des SQL Server-Fehlerprotokolls und wenden Sie sich an den VergeOS-Support.
• Eine neuere virtio-win-Version ist verfügbar — Veröffentlichungen nach Januar 2026 können den Upstream-Fix enthalten und langfristig die bessere Wahl sein, als auf v0.1.271 zu bleiben. Bestätigen Sie den konkreten Build mit dem VergeOS-Support, bevor Sie ihn auf produktiven Datenbank-VMs ausrollen.

Zusätzliche Ressourcen

• Virtio-Treiber in der Windows-Wiederherstellungskonsole laden
• Best Practices für Datenbanken
• VM-Snapshots und Wiederherstellungen
• virtio-win issue #1453 — Upstream-Meldung über das SRB-ID-Race
• Stabile virtio-win-ISO-Downloads
• Archivierte virtio-win-ISO-Downloads

Feedback

Brauchen Sie Hilfe?

Wenn Sie auf einer Windows-MS-SQL-VM Read-retry-Meldungen oder Instabilität sehen und unsicher sind, welche virtio-win-Version installiert ist — oder auf welchen Build Sie aktualisieren sollten — wenden Sie sich bitte an VergeOS-Support-Team bevor Sie in der Produktion Treiberänderungen vornehmen.