Skip to content

VMs#

VirtIO-Win Driver Compatibility with MS SQL Server Workloads

Overview

Key Points

  • virtio-win v0.1.285 and v0.1.292 contain a race condition in the vioscsi and viostor storage drivers that surfaces on heavily loaded MS SQL Server VMs
  • v0.1.271 is the last release before the affected commit and is the recommended version for Windows guests running database workloads
  • Symptoms are most pronounced on Windows Server 2025 guests under sustained parallel I/O
  • The upstream fix landed in January 2026; later virtio-win releases that include it should also be safe — verify the build before deploying widely
  • Take a snapshot of the VM and stop SQL Server services before changing storage drivers

Windows VMs running MS SQL Server on VergeOS can produce a stream of SQL Server "read-retry" log entries — and in some cases a hung SQL Server service after a few days of sustained load — when the guest is using virtio-win v0.1.285 or v0.1.292. The root cause is a non-atomic SRB ID assignment in the vioscsi/viostor Storport miniports that allows duplicate IDs to be issued when Windows dispatches I/O across multiple CPUs in parallel (tracked upstream as virtio-win issue #1453).

The behavior is most reproducible on Windows Server 2025 because its Storport implementation parallelizes StartIo more aggressively than earlier Windows Server releases. Older Windows guests are exposed to the same bug but trigger it less often.

Downgrading the guest's virtio-win drivers to v0.1.271 is a stable workaround. A fix for the underlying race condition was merged upstream and shipped in newer virtio-win builds, so later releases that include it should also be safe — confirm with VergeOS support which builds in your environment are known-good before upgrading mid-incident.

Symptoms

If you suspect this issue on a VergeOS Windows VM, look for the following in the guest's Application event log and SQL Server error log:

  • Read-retry messages where the expected and actual values are identical, for example:

    A read of the file '*.mdf' at offset 0x... succeeded after failing 1 time(s) with error: incorrect checksum (expected: 0xad4c6778; actual: 0xad4c6778)

    A read of the file '*.mdf' at offset 0x... succeeded after failing 1 time(s) with error: incorrect pageid (expected 1:29669944; actual 1:29669944)

  • No SRB found for ID entries from the vioscsi source

  • SQL Server services hanging after several days of sustained heavy load

These messages can look like corruption but usually aren't

SQL Server reports the retry outcome, which succeeds on the second attempt. DBCC CHECKDB typically comes back clean — the database pages on disk are intact. The driver is delivering the wrong buffer to the first read because of the duplicate SRB ID, and the second read returns the correct data. Persistent retries still indicate a real problem and should be addressed even when no corruption is detected.

Prerequisites

  • A Windows VM running MS SQL Server (or a similarly I/O-heavy database workload) on VergeOS
  • Administrative access to the Windows guest
  • A snapshot of the VM taken before changing any drivers
  • The virtio-win v0.1.271 ISO uploaded to your VergeOS environment under Files. Archived ISOs are available from the stable-virtio archive on Fedora People

Identifying the Installed VirtIO Driver Version

Before changing anything, confirm which virtio-win build the guest is currently running.

  1. Open Device Manager

    • Right-click the Start menu and select Device Manager.

  2. Locate the VirtIO storage controller

    • Expand Storage controllers.
    • Right-click Red Hat VirtIO SCSI controller (for vioscsi) or Red Hat VirtIO SCSI pass-through controller / Red Hat VirtIO SCSI Disk Device (for viostor) and choose Properties.

  3. Check the driver version and date

    • Switch to the Driver tab.
    • Note the Driver Version and Driver Date fields.

  4. Cross-reference against the source ISO

    • The driver version stamp follows a 100.<minor>.<build>.<revision> format, where the trailing revision component is built from the virtio-win ISO version. For example, a vioscsi driver from virtio-win 0.1.285 typically ends in .28500; 0.1.271 typically ends in .27100.
    • If you are unsure which ISO produced the installed driver, mount the candidate ISO inside the guest and compare its vioscsi.inf / viostor.inf DriverVer line against the value shown in Device Manager.

Check both vioscsi and viostor

The upstream bug affects both the vioscsi (Virtio SCSI) and viostor (Virtio block) drivers. If the VM uses one bus type for the OS disk and the other for data disks, verify both controllers.

Version Status
v0.1.271 Recommended workaround. Last release before the affected commit; confirmed stable under heavy SQL load.
v0.1.285 Avoid. Contains the vioscsi/viostor SRB ID race; produces read-retry errors on busy SQL VMs.
v0.1.292 Avoid. Same defect as v0.1.285.
Builds after the upstream fix (Jan 2026 onward) Should be safe in principle. Confirm the specific build with VergeOS support before deploying.

The stable virtio-win ISO downloads are available from the Fedora People stable-virtio repository, and older releases from the archive-virtio directory.

Downgrading to virtio-win v0.1.271

Take a snapshot first

Before changing any virtio driver in the guest, take a VergeOS snapshot of the VM. The storage stack is boot-critical — the snapshot is your rollback point if the driver swap leaves Windows unable to mount its disks.

  1. Stop MS SQL Server services in the guest

    • From an elevated PowerShell or the Services console, stop the SQL Server (MSSQLSERVER) service and any dependent services (SQL Agent, full-text, Reporting Services, etc.) to quiesce I/O before changing the storage driver.

  2. Mount the virtio-win v0.1.271 ISO

    • In VergeOS, edit the VM and attach virtio-win-0.1.271.iso as a CD/DVD device.
    • Confirm the ISO is visible inside Windows (typically the next available drive letter).

  3. Uninstall the current virtio-win guest tools

    • Open Settings → Apps & features (or Programs and Features in the Control Panel) inside the guest.
    • Locate Virtio-win-guest-tools and choose Uninstall. Follow the prompts and reboot if requested.
    • If the uninstall fails or rolls back with error 0x80070643 (a known issue when removing virtio-win-guest-tools), use Microsoft's Program Install and Uninstall troubleshooter to clean up the registration before continuing.

  4. Reboot the VM

    • Reboot Windows so any in-use driver files are released. The VM should still boot — Windows retains the storage driver binaries until the new package is installed.

  5. Install virtio-win-guest-tools from the v0.1.271 ISO

    • From the mounted v0.1.271 ISO, run virtio-win-guest-tools.exe (or virtio-win-gt-x64.msi) as an administrator.
    • Complete the installer with the default component selection. This reinstalls vioscsi, viostor, NetKVM, and the guest agent at the v0.1.271 build.

  6. Reboot the VM again

    • Reboot Windows so the storage and network stacks reload against the downgraded drivers.

  7. Verify the new driver version

    • Return to Device Manager → Storage controllers, open the VirtIO controller's Properties → Driver tab, and confirm the Driver Version now reflects the v0.1.271 build (typically ending in .27100).
    • Repeat for any other VirtIO controllers and for the Red Hat VirtIO Ethernet Adapter under Network adapters.

  8. Start MS SQL Server services

    • Start the SQL Server service and any dependents and confirm the databases come online cleanly.

  9. Monitor under load

    • Resume normal workloads and watch the SQL Server error log and Windows Application log for the read-retry messages described above. Sustained operation without retries is the success criterion.

Troubleshooting

Common Issues

  • Installer reports "newer version already installed" — The virtio-win MSI does not perform an in-place downgrade. Complete the uninstall step (and reboot) before running the v0.1.271 installer.
  • Uninstall fails with error 0x80070643 — A known virtio-win-guest-tools quirk. Use Microsoft's Program Install and Uninstall troubleshooter to clear the failed installer state, reboot, and try the v0.1.271 install again.
  • VM fails to boot after driver change — Restore the snapshot taken in the prerequisites and retry the procedure with SQL Server services fully stopped first.
  • Storage controller shows a yellow exclamation in Device Manager — The driver did not load cleanly. Right-click the controller, choose Update driver → Browse my computer, and point it at the folder on the v0.1.271 ISO matching your Windows version (e.g. vioscsi\2k25\amd64 for Windows Server 2025).
  • Read-retry messages persist after downgrading — Verify that both vioscsi and viostor (whichever the VM uses) now show the v0.1.271 build in Device Manager. If they do and the messages continue, capture a fresh sample of the Application log and SQL Server error log and contact VergeOS support.
  • A newer virtio-win release is available — Releases published after January 2026 may include the upstream fix and be a better long-term choice than staying on v0.1.271. Confirm the specific build with VergeOS support before rolling it out to production database VMs.

Additional Resources

Feedback

Need Help?

If you are seeing read-retry messages or instability on a Windows MS SQL VM and are unsure which virtio-win version is installed — or which build to upgrade to — please reach out to the VergeOS Support Team before making driver changes in production.

  • in VMs
  • 3 min read

Secure Boot Certificate Expiry - Microsoft Guest VMs (June 2026)

Overview

Key Points

  • Microsoft's Secure Boot certificate expires in June 2026 and may cause Windows VMs to fail to boot or accept updates
  • VergeOS 26.1.5 introduces a one-click fix to apply the Microsoft CA 2023 Secure Boot keys
  • The VM must be powered off before applying the fix
  • If BitLocker is enabled, have your recovery key available before rebooting

Microsoft's Secure Boot signing certificate used in Windows guest VMs expires in June 2026. Affected VMs will display a warning alert and a yellow banner in VergeOS. Without remediation, Windows VMs may fail to boot or refuse OS updates after the certificate expires.

VergeOS 26.1.5 includes a built-in resolution that applies the Microsoft CA 2023 Secure Boot keys directly from the VM's detail page.

Prerequisites

  • VergeOS 26.1.5 or later (see Alternate Resolution if you cannot upgrade)
  • A snapshot of the VM taken before proceeding
  • If BitLocker is enabled on the guest: your BitLocker recovery key must be accessible before rebooting
  • The VM must be powered off before applying the fix

Identifying Affected VMs

Affected VMs will show two indicators:

Alert panel

A warning-level alert will appear with the status message:

Current secure boot certificate will expire June 2026 and may cause boot/update issues

Double-clicking the alert navigates directly to the affected VM's detail page.

VM detail page banner

A yellow banner will appear at the top of the VM's detail page:

Current secure boot certificate will expire June 2026 and may cause boot/update issues

Steps

Take a snapshot first

Before proceeding, take a snapshot of the VM. This is your rollback point if anything goes wrong.

  1. Power off the VM - The fix cannot be applied while the VM is running. If the VM is on when you click Apply, an error will appear — power it off first and then retry.

  2. Navigate to the VM detail page - You can double-click the alert from the alert panel, or browse to the VM directly.

  3. Click "Apply" on the yellow banner - The yellow banner at the top of the VM detail page contains an Apply button.

  4. Confirm the action - A confirmation dialog will appear:

    Resolution: Current secure boot certificate will expire June 2026 and may cause boot/update issues. This will apply the Microsoft CA 2023 secure boot keys. Please ensure you have a snapshot of this machine before performing this action. If you have bitlocker enabled you will need to have your key ready on reboot.

    Would you like to apply this resolution now?

  • Click Yes to apply the Microsoft CA 2023 Secure Boot keys.
  1. Power on the VM - After the fix is applied, start the VM normally. - If BitLocker is enabled, the guest may prompt for your recovery key on first boot — enter it when prompted.

Troubleshooting

Common Issues

  • Error when clicking Apply — The VM must be fully powered off. Confirm the VM status shows Stopped before retrying.
  • BitLocker recovery key prompt on boot — Expected behavior after updating Secure Boot keys. Enter your BitLocker recovery key to unlock the drive and allow Windows to boot normally.
  • Warning banner persists after applying — Refresh the VM detail page. If the banner remains, confirm the fix completed without errors and contact support.

Alternate Resolution (Without VergeOS 26.1.5)

If you are unable to upgrade to VergeOS 26.1.5, Microsoft has published manual instructions for renewing Secure Boot certificates before the June 2026 expiration:

Secure Boot Playbook for Certificates Expiring in 2026 - Microsoft Tech Community

Upgrade recommended

Upgrading to VergeOS 26.1.5 is the simplest path. The manual process above requires Windows-level access to each affected VM and is more involved than the built-in one-click fix.

Additional Resources

Feedback

Need Help?

If you encounter issues applying the Secure Boot certificate fix or have questions about affected VMs, please don't hesitate to reach out to the VergeOS Support Team.