virtio-win 0.1.302 ist stabil: Lohnt sich das Upgrade?

virtio-win 0.1.302 wird offiziell als stabil eingestuft, doch das bedeutet nicht, dass jede Windows-VM unter Proxmox dieses Update sofort erhalten sollte. Das Release folgt auf eine unruhige Phase bei Windows-Speichertreibern, einschließlich einer gravierenden vioscsi-Regression unter Windows Server 2025 in Version 0.1.285. Die Debatten rund um 0.1.302 verdeutlichen, wie viel Kontext das Wort stabil in der Praxis verlangt.

Das Paket erschien am 27. August 2026 im stabilen Download-Pfad von Fedora virtio-win. Administratoren begannen umgehend mit Tests unter Windows Server 2025, Windows 11, SQL Server, ZFS-basierten Proxmox-VMs und Backup-Abläufen. Einige erzielten saubere Ergebnisse. Andere stellten fest, dass andere Speicherfunktionen wie TRIM weiterhin Workarounds erforderten. Ein Treiber-Release kann vom Projekt als stabil deklariert werden, lange bevor es sich für Ihre spezifischen Workloads bewährt hat, und 0.1.302 ist dafür ein anschauliches Beispiel.

Was sich mit virtio-win 0.1.302 geändert hat

Ende August 2026 rückte 0.1.302 zum aktuellen stabilen Fedora-Paket auf und löste 0.1.285 im regulären Release-Verzeichnis ab.

Der Eintrag im Fedora-Changelog, auf den sich erste Tester bezogen, datiert auf den 27. August und kennzeichnete das Paket als 0.1.302-1. Das Paket enthielt das ISO-Image, RPM-Dateien, Windows-Gastwerkzeuge sowie die MSI-Installer für x64 und x86.

Für Proxmox-Anwender ist dies von zentraler Bedeutung, da virtio-win die Windows-Gasttreiber für wichtige virtuelle Hardware liefert: VirtIO SCSI, VirtIO Block, VirtIO-Netzwerkadapter, Speicher-Ballooning, serielle Schnittstellen und verwandte Komponenten. Das Upstream-Projekt beschreibt virtio-win als paravirtualisiertes Windows-Treiberpaket für QEMU und KVM. Unter Proxmox sitzen diese Treiber direkt im I/O-Pfad zwischen Windows und der von QEMU emulierten virtuellen Hardware.

Ein fehlerhafter Speichertreiber wiegt daher ungleich schwerer als ein kleiner Schönheitsfehler in den Gastwerkzeugen. Ein Speicherfehler kann Datenbanken, Auslagerungsdateien, Backup-Prozesse, Lesezugriffe, TRIM oder die generelle Stabilität der VM unter Last gefährden.

Wenn Sie Windows-Gäste auf Proxmox einrichten und betreiben, bieten die umfassenden Mr.PlanB Proxmox-Ressourcen praktische Orientierung für Gastkonfiguration und Hostarchitektur.

Warum Administratoren nach 0.1.285 vorsichtig waren

Der Grund für die Skepsis liegt in den Erfahrungen mit 0.1.285. Ein dokumentierter vioscsi-Fehler betraf I/O-intensive Workloads unter Windows Server 2025, insbesondere mit SQL Server. Der GitHub-Bericht zu Issue 1453 beschrieb auffällige Lesewiederholungen: SQL Server meldete beim ersten Leseversuch Prüfsummen- oder Page-ID-Fehler, während der wiederholte Versuch gelang.

Der Tester führte diese Regression auf eine konkrete Treiberänderung in neueren Versionen zurück und betonte, dass 0.1.271 dieses Verhalten unter demselben Workload nicht zeigte. Das Problem wog so schwer, dass die offizielle Proxmox-Dokumentation für Windows VirtIO 0.1.285 als bekanntes Problem für VirtIO SCSI und VirtIO Block auf I/O-lastigen VMs mit Windows Server 2025 auswies.

Diese Vorgeschichte prägte den Empfang von 0.1.302. Ein Administrator brachte es in der Diskussion auf den Punkt: Nach den Erfahrungen mit 0.1.285 gelte es, erst gründlich zu testen und abzuwarten. Ein anderer berichtete von identischen Problemen bei eigenen SQL Server-Systemen. Ein dritter Teilnehmer schilderte sogar unbemerkte Datenbeschädigungen in einer produktiven Datenbank, bevor die Ursache verstanden wurde. Letzterer Bericht ist ein Einzelfall, verdeutlicht jedoch, warum erfahrene Administratoren die Kennzeichnung stabil nicht als Freibrief für ein flächendeckendes Update ansahen.

Version 0.1.285 war nicht für alle Setups unbrauchbar. Die Schwierigkeit besteht darin, dass ein Release herkömmliche Funktionstests bestehen und dennoch unter speziellen Lastmustern, Betriebssystemversionen, Nebenläufigkeiten oder Speicherpfaden versagen kann.

Wurde das Leseproblem unter Windows Server 2025 mit 0.1.302 behoben?

Erste Rückmeldungen deuten darauf hin, dass der spezifische vioscsi-Lesefehler behoben wurde, wenngleich andere Speicherfragen offenbleiben. Der ursprüngliche Bericht zu Windows Server 2025 unter GitHub Issue 1453 wurde schließlich geschlossen. Community-Mitglieder, die 0.1.302 früh erprobten, verwiesen auf die Entwicklungsarbeit und meldeten, dass der I/O-Fehler im neuen Build beseitigt sei.

Praxistests im Labor lieferten ermutigende Resultate. Ein Nutzer aktualisierte mehrere VMs mit Windows 11 sowie Windows Server 2025 und beobachtete keine unmittelbaren Störungen. Ein weiterer Tester unterzog eine SQL-ERP-Testdatenbank mehrstündigen Belastungstests und berichtete, dass die früheren Lesefehler unter SQL Server nicht wieder auftraten. Das sind wertvolle Hinweise, aber noch keine langfristigen Produktivbelege.

Zudem gilt es, verschiedene Fehlerbilder sauber zu trennen. Im selben Forenthread verlagerte sich die Debatte rasch von der Leseregression unter Windows Server 2025 zu TRIM-Fehlern auf ZFS-basierten VMs. Ein Teilnehmer wies zurecht darauf hin, dass dies zwei völlig unterschiedliche Probleme sind. Wenn mehrere Speichersymptome im selben Treiberumfeld auftreten, geraten die Ursachen leicht durcheinander.

Ein behobener Lesefehler bei SQL Server löst nicht automatisch TRIM-Probleme in Windows. Ein erfolgreicher Test unter Windows Server 2025 garantiert nicht, dass der viostor-Pfad unter Windows 10 einwandfrei arbeitet. Ein Treiberpaket umfasst mehrere Speichertreiber mit jeweils eigenen Code-Pfaden und Fehlerbildern.

Warum TRIM nach 0.1.302 weiterhin für Diskussionen sorgte

Mehrere Tester stellten fest, dass TRIM unter Windows auch nach dem Upgrade auf 0.1.302 fehlschlug, vor allem bei VirtIO-SCSI-Festplatten auf Basis von ZFS-Zvols.

GitHub Issue 1574 dokumentiert einen Windows 11 Gast, bei dem TRIM mit virtio-win 0.1.285 nach einem Windows-Update im Mai 2026 den Dienst verweigerte. Der Fehler erzeugte im Windows-Defragmentierer das Event ID 264 und verhinderte, dass Discard-Befehle den Gast-Speicher-Stack ordnungsgemäß durchliefen.

In der Diskussion zu 0.1.302 schilderte ein Administrator, wie er die Treiber aktualisierte, die Version im Geräte-Manager prüfte, das System neu startete und dennoch feststellte:

defrag /O c:

schlug weiterhin fehl, solange in der Proxmox-VM-Konfiguration kein manueller Parameter für discard_granularity hinterlegt wurde.

Administratoren experimentierten mit Werten wie 16K, 32K und 64K, abgestimmt auf die ZFS-Zvol-Blockgröße und die Zuordnungseinheiten von NTFS. Die Diskussion wurde detailliert geführt, weil der passende Wert davon abhängt, wie Discard-Anfragen zwischen Gastdateisystem, virtueller Festplatte und dem zugrundeliegenden ZFS-Volume abgestimmt sind. Weder die Aussage "0.1.302 repariert TRIM" noch "0.1.302 beschädigt TRIM" trifft die Realität.

Mit Stand September 2026 war der entsprechende TRIM-Vorgang im Upstream-Projekt weiterhin geöffnet. Die nüchterne Erkenntnis lautet: Version 0.1.302 behebt eine bestimmte Speicher-Regression, während ein separates Discard-Problem in bestimmten Konfigurationen fortbesteht.

Was ist am Bericht über Pagefile-Beschädigungen bei viostor dran?

Ein weiteres offenes Ticket erschwert pauschale Empfehlungen. GitHub Issue 1614 beschreibt Beschädigungen der Auslagerungsdatei beim Einsatz des viostor-Treibers aus Version 0.1.285.

Dies ist ein eigenständiges Problem neben dem vioscsi-Fehler unter Windows Server 2025. Es betrifft Windows 10 auf einer VirtIO-Block-Festplatte, bei der über viostor geschriebene Pagefile-Daten fehlerhaft zurückgelesen wurden und Bluescreens mit dem Fehlercode MEMORY_MANAGEMENT auslösten.

Der Verfasser des Berichts verglich 0.1.285 mit 0.1.271 auf identischer Speicherhardware und VM-Konfiguration. Unter 0.1.285 trat der Fehler reproduzierbar auf, während 0.1.271 wiederholte Testzyklen fehlerfrei absolvierte. Am 17. September 2026 war das Ticket im Upstream-Projekt noch offen.

Das beweist nicht, dass 0.1.302 denselben Fehler aufweist. Es zeigt jedoch, warum die Einstufung als neuestes stabiles Paket allein kein ausreichender Grund ist, Speichertreiber auf wichtigen Windows-VMs zu tauschen. Prüfen Sie vorab, welchen Treiber die jeweilige VM nutzt, welche Last auf ihr liegt und ob bekannte Upstream-Probleme auf diesem Pfad in der Zielversion behoben wurden. Diese Antworten sind aussagekräftiger als jedes Release-Label.

Bedeutet stabil auch produktionsreif?

Stabil ist eine Kennzeichnung des Release-Kanals, während Produktionsreife ein Urteil ist, das Sie für einen bestimmten Workload nach sorgfältiger Validierung fällen. Der Großteil der Fachdiskussion lief auf genau diese Differenzierung hinaus.

Einige Anwender sahen im Fedora-Label stabil das verlässliche Signal, dass 0.1.302 die Freigabeprozesse durchlaufen habe und für den Produktiveinsatz bereit sei. Andere waren durch 0.1.285 gewarnt und zogen es vor, auf 0.1.271 zu verbleiben, da sich diese Version in ihren Umgebungen bewährt hatte.

Ein Administrator formulierte eine pragmatische Richtlinie: Installieren Sie neue Treiber zunächst auf einer produktionsnahen Test-VM, beobachten Sie die Windows-Ereignisprotokolle rund einen Monat lang und entscheiden Sie erst danach über die übrigen Server. Das ist konservativ, bei Infrastrukturtreibern jedoch sinnvoll. Ein fehlschlagendes Browser-Update stört den Arbeitsfluss, ein Speichertreiber, der unter Last falsche Daten zurückliefert, gefährdet den gesamten Betrieb.

Das bedeutet nicht, alte Treiber für immer einzufrieren. Ältere Builds bringen eigene Fehler, Kompatibilitätsgrenzen und fehlende Sicherheitspatches mit sich. Aktualisieren Sie dann, wenn Sie einen konkreten Grund haben; eine höhere Versionsnummer allein genügt nicht.

Wenn 0.1.302 ein konkretes Problem unter Windows Server 2025 löst, das bei Ihnen auftritt, lohnt sich der Testbetrieb zweifellos. Laufen Ihre Systeme unter 0.1.271 stabil und benötigen Sie keine der neuen Fehlerbehebungen, besteht keine Eile.

Wie sollten Sie 0.1.302 vor einem breiten Rollout testen?

Beginnen Sie mit einer virtuellen Maschine, die dem realen Workload ähnelt, sich im Ernstfall jedoch schnell wiederherstellen lässt. Ein Snapshot allein reicht als Sicherheitsnetz nicht aus. Erstellen Sie ein vollwertiges Backup, notieren Sie die aktuellen Treiberversionen und stellen Sie sicher, wie Sie den Speichertreiber zurücksetzen können, falls das Gastsystem instabil wird.

Testen Sie anschließend das tatsächliche Verhalten Ihrer produktiven VM. Bei einem SQL-Workload unter Windows Server 2025 erzeugen Sie anhaltende Datenbanklast und prüfen sowohl die SQL Server-Logs als auch die Windows-Ereignisanzeige. Bei einer Windows-VM auf ZFS testen Sie TRIM oder die Laufwerksoptimierung und verifizieren, ob Discard-Befehle beim Speichersystem ankommen. Bei Systemen mit VirtIO Block werfen Sie einen Blick auf die Historie von viostor und übertragen Ergebnisse von vioscsi nicht ungeprüft.

Prüfen Sie Backups separat. In den Diskussionen meldete ein Anwender, dass Synology Active Backup nach dem Update auf 0.1.302 den Dienst einstellte und erst nach dem Rollback auf 0.1.271 wieder funktionierte. Ein anderer Teilnehmer berichtete von Verbesserungen bei anderen Backup-Mechanismen mit neueren Gastagenten. Beide Berichte stellen kein allgemeines Urteil dar, sind aber triftige Gründe, Sicherungs- und Wiederherstellungsprozesse nach Änderungen an Low-Level-Treibern eingehend zu prüfen.

Ein Proxmox Health Check unterstützt Sie bei der Prüfung auf Host- und Clusterebene, doch die Validierung von Windows-Gästen muss innerhalb der virtuellen Maschine selbst stattfinden.

Die sicherste Version ist diejenige, die Sie selbst getestet haben

Version 0.1.302 ist ein wichtiges Release. Es folgt auf bekannte Fehler der Generation 0.1.285, und erste Tests deuten darauf hin, dass es die drängendsten Probleme unter Windows Server 2025 entschärft. Dennoch ist das Label stabil kein Freibrief für alle Einsatzbereiche.

Die passendere Frage beim Upgrade lautet nicht: "Ist 0.1.302 stabil?", sondern: Ist 0.1.302 besser für diese konkrete VM, diese Windows-Version, diesen Speichertreiber, diese Arbeitslast und dieses Backup-Verfahren?

Wenn Ihre Tests diese Frage bejahen, führen Sie das Upgrade durch. Funktioniert Ihr bisheriger Treiber einwandfrei und löst 0.1.302 kein akutes Problem, gibt es keinen Grund, beim Rollout der Erste zu sein.