> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/knowledge-base/de/virtual-machines/virtio-win-mssql-compatibility.md).

# Kompatibilität des VirtIO-Win-Treibers mit MS-SQL-Server-Workloads

## Überblick

{% hint style="info" %}
**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
  {% endhint %}

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](https://github.com/virtio-win/kvm-guest-drivers-windows/issues/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

{% hint style="info" %}
**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.
{% endhint %}

## 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](https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/)

## 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.

{% hint style="success" %}
**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.
{% endhint %}

## 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](https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/), und ältere Versionen im [archive-virtio-Verzeichnis](https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/).

## Downgrade auf virtio-win v0.1.271

{% hint style="warning" %}
**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.
{% endhint %}

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](https://support.microsoft.com/topic/fix-problems-that-block-programs-from-being-installed-or-removed-cca7d1b6-65a9-3d98-426b-e9f927e1eb4d) 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.msi`als 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

{% hint style="warning" %}
**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.
  {% endhint %}

## Zusätzliche Ressourcen

* [Virtio-Treiber in der Windows-Wiederherstellungskonsole laden](/knowledge-base/de/virtual-machines/loading-virtio-drivers-in-windows-recovery-console.md)
* [Best Practices für Datenbanken](/knowledge-base/de/system-administration/database-best-practices.md)
* [VM-Snapshots und Wiederherstellungen](/automate-protect-and-extend/backup-and-dr/vm-snapshots-restores.md)
* [virtio-win issue #1453 — Upstream-Meldung über das SRB-ID-Race](https://github.com/virtio-win/kvm-guest-drivers-windows/issues/1453)
* [Stabile virtio-win-ISO-Downloads](https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/)
* [Archivierte virtio-win-ISO-Downloads](https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/)

## Feedback

{% hint style="info" %}
**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](broken://spaces/RDqjqiAbPZD7nK9rjfqU/pages/8c8d3dd8447f3e6289926e29d315a800b2153b50) bevor Sie in der Produktion Treiberänderungen vornehmen.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.verge.io/knowledge-base/de/virtual-machines/virtio-win-mssql-compatibility.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
