virtio-win 0.1.302 Is Stable. Should You Upgrade?

virtio-win 0.1.302 is labeled stable, but that doesn't mean every Proxmox Windows VM should get it today. The release follows a messy stretch for Windows storage drivers, including a serious Windows Server 2025 vioscsi regression in 0.1.285, and the discussion around 0.1.302 shows how much context the word "stable" needs.

The package showed up in the Fedora virtio-win stable download path on August 27, 2026. Administrators started testing it right away on Windows Server 2025, Windows 11, SQL Server workloads, ZFS-backed Proxmox VMs, and backup workflows. Some got clean results. Others found that unrelated storage behavior, TRIM in particular, still needed workarounds. A driver release can be officially stable well before it has proven stable on your particular workload, and 0.1.302 is a good example.

What changed with virtio-win 0.1.302?

In late August 2026, 0.1.302 became the current stable Fedora package, replacing 0.1.285 in the stable download location.

The Fedora changelog entry that early testers quoted was dated August 27 and identified the package as 0.1.302-1. The release bundle included the ISO, RPM packages, Windows guest tools, and the x64 and x86 MSI installers.

This matters to Proxmox users because virtio-win supplies the Windows guest drivers for common virtual hardware: VirtIO SCSI, VirtIO Block, VirtIO network adapters, memory ballooning, serial devices, and related components. The source project describes virtio-win as the Windows paravirtualized driver set for QEMU and KVM. On Proxmox, these drivers sit directly in the I/O path between Windows and the virtual hardware QEMU presents.

So a bad storage driver release is far worse than a cosmetic guest-tools bug. A storage bug can hit databases, pagefiles, backup behavior, disk reads, TRIM, or whether the VM stays stable under load at all.

If you build or maintain Windows guests on Proxmox, the broader Mr.PlanB Proxmox resources help keep guest configuration and host architecture in the same picture.

Why were administrators nervous after 0.1.285?

Because of what happened with 0.1.285. One documented vioscsi issue hit I/O-heavy Windows Server 2025 workloads, especially SQL Server. The GitHub report for issue 1453 described read-retry behavior: SQL Server logged checksum or page ID problems on the first read, then succeeded on retry.

The reporter traced the regression to newer drivers containing a particular change and said 0.1.271 didn't show the same behavior under the tested workload. It was serious enough that the Proxmox Windows VirtIO driver documentation flagged 0.1.285 as a known problem for VirtIO SCSI and VirtIO Block on I/O-heavy Windows Server 2025 VMs.

That history colored the reaction to 0.1.302. One administrator in the discussion put it well: after the 0.1.285 experience, test first and wait. Another said they had hit the problem personally on SQL Server workloads. A different user claimed a production database had been silently damaged over time before anyone understood the issue. That last report is anecdotal and can't be generalized to every environment, but it explains why experienced operators didn't treat a new stable label as enough evidence for a fleet-wide upgrade.

0.1.285 wasn't unusable for everyone. The problem is that a release can pass normal testing and still fail under a specific workload, OS version, concurrency pattern, or storage path.

Did 0.1.302 fix the Windows Server 2025 read problem?

Early evidence says the specific vioscsi read-retry problem was addressed, though other storage issues are still around. The original Windows Server 2025 report, GitHub issue 1453, was eventually closed. Community members following 0.1.302 pointed to the related development work and reported that the I/O issue was fixed in the newer build.

Early hands-on testing was encouraging. One user upgraded several Windows 11 and Windows Server 2025 VMs and saw no immediate issues. Another ran a SQL ERP test database through several hours of checks and said the earlier SQL read errors didn't come back. That's useful, but it's still early operational evidence.

Keep the bugs separate, too. The same thread quickly drifted from the Windows Server 2025 read-retry regression to TRIM failures on ZFS-backed VMs, and one participant pointed out that these were two different issues. When several storage symptoms show up around the same driver family, that's easy to lose track of.

A fixed SQL Server read-retry problem doesn't automatically fix Windows TRIM. A clean Windows Server 2025 test doesn't prove the viostor path on Windows 10 is fine. One driver package can contain several storage drivers, each with its own code path and failure modes.

Why was TRIM still causing arguments after 0.1.302?

Some testers found Windows TRIM still failing after upgrading to 0.1.302, mostly with VirtIO SCSI disks backed by ZFS zvols.

GitHub issue 1574 documents a Windows 11 guest where TRIM stopped working with virtio-win 0.1.285 after a May 2026 Windows update. The failure produced Windows Defrag Event ID 264 and kept discard requests from moving through the guest storage stack the way they should.

In the 0.1.302 discussion, one administrator upgraded the drivers, confirmed the new version in Device Manager, rebooted, and still found that:

defrag /O c:

would fail unless a discard_granularity override was added to the Proxmox VM configuration.

People tried values such as 16K, 32K, and 64K depending on the ZFS zvol block size and NTFS allocation unit. The debate got detailed because the right value depends on how discard requests line up between the guest filesystem, the virtual disk, and the backing ZFS volume. Neither "0.1.302 fixes TRIM" nor "0.1.302 breaks TRIM" is a fair summary.

As of September 2026, the related TRIM issue was still open upstream. The safe reading is narrower: 0.1.302 may fix one storage regression while a separate discard problem remains in some configurations.

What about the viostor pagefile corruption report?

Another open issue makes a blanket recommendation even harder. GitHub issue 1614 reports pagefile corruption with the viostor driver in 0.1.285.

This is a different problem from the Windows Server 2025 vioscsi bug. It describes Windows 10 on a VirtIO Block disk, where pagefile data written through viostor could read back incorrectly and trigger MEMORY_MANAGEMENT bugchecks.

The reporter compared 0.1.285 with 0.1.271 while keeping the storage hardware and most of the VM environment the same. In that test, 0.1.285 failed under the reproducer and 0.1.271 completed repeated rounds cleanly. As of September 17, 2026, the issue was still open upstream.

None of that proves 0.1.302 has the same failure. It does show why "latest stable package" is too loose a reason to upgrade Windows storage drivers on an important VM. Before you do, find out which driver the VM uses, what workload stresses it, and whether the upstream issue on that path is actually fixed in the version you plan to install. Those answers tell you more than the stable label does.

Does stable mean production ready?

Stable is a release-channel label, while production ready is a judgment you make about a specific workload after enough validation. Most of the discussion came down to that difference.

Some users took Fedora's stable designation as a real sign that 0.1.302 had passed the release process and was ready for normal use. Others had been burned by 0.1.285 and preferred to stay on 0.1.271, which had already proven reliable for them.

One administrator described a simple policy: run a new driver on an almost-production VM for about a month, watch the Windows logs, and only then think about moving the rest of the servers. It's conservative, and for infrastructure drivers it makes sense. A browser update failing is annoying. A storage driver returning the wrong data under load is a much bigger risk.

That doesn't mean freezing on old drivers forever. Older drivers have their own bugs, compatibility limits, and missing fixes. Upgrade when you have a reason; a higher version number showing up isn't one.

If 0.1.302 fixes a Windows Server 2025 problem you already have, testing it is clearly worthwhile. If your guests are stable on 0.1.271 and none of the new fixes matter to you, there's much less urgency.

How should you test 0.1.302 before a broad rollout?

Start with a VM that looks like the workload you care about but is easy to restore. A snapshot alone isn't enough of a safety plan. Have a real backup, write down the current driver versions, and know how you'll roll back the storage driver if the guest becomes unstable.

Then test what your production VM actually does. For a Windows Server 2025 SQL workload, generate sustained database I/O and check both the SQL Server logs and Windows Event Viewer. For a ZFS-backed Windows VM, test TRIM or Optimize Drives and confirm that discard reaches the backing storage. For a VM on VirtIO Block, look at the viostor issue history and don't assume vioscsi results carry over.

Test backups separately. Later in the same discussion, someone reported that Synology Active Backup stopped working after a 0.1.302 upgrade and recovered after reverting to 0.1.271. Another participant said different backup-related behavior improved with newer guest-agent components. Neither report is a broad compatibility verdict, but both are good reasons to test backup and restore after changing low-level guest drivers.

A Proxmox Health Check can help on the host and cluster side, but Windows guest validation still has to happen inside the VM.

The safest version is the one you have actually tested

0.1.302 is a meaningful release. It follows known problems in the 0.1.285 generation, and early testing suggests it improves at least some of the most worrying Windows Server 2025 cases. Even so, the stable label isn't a green light for everything.

A better upgrade question than "Is 0.1.302 stable?" is whether 0.1.302 is better for this VM, this Windows version, this virtual storage driver, this workload, and this backup path.

If testing says yes, upgrade. If your current driver works and 0.1.302 solves nothing you need right now, there's no prize for going first.