Redhat VirtIO developers would like to coordinate with Proxmox devs re: "[vioscsi] Reset to device ... system unresponsive"

switching the SCSI Controller to Default (LSI 53C895A)
isn't required as controller isn't used when no scsi devices attached.
are you able to reproduce issue with SATA type disk keeping VirtIO SCSI controller ?!

edit: add your storage type, here is local storage only to exclude others factors.
 
Last edited:
isn't required as controller isn't used when no scsi devices attached.
are you able to reproduce issue with SATA type disk keeping VirtIO SCSI controller ?!

edit: add your storage type, here is local storage only to exclude others factors.
I've been a fly on the wall for this issue but especially with MSSQL servers I can replicate the vioscsi disk reset. I'm using Ceph as the storage locally.
 
I have had the issue with VirtIO SCSI on pretty much all drivers and configurations. I just switched these over to SATA and will see if the issue improves at all.

All local storage, with VMs running on ZFS and physical disks passed through on native NTFS.
 
Proxmox 8.2.4, ZFS Mirror with 2 x NVME PM9A3
Windows Server 2022 VM with 3 disks, OS, SQL, SQL Backups, drivers used: virtio-win-0.1.240-1.
Zabbix gives me a warning that the disk is overloaded with a high utilization, when I RDP into the VM I can't access the disk with the SQL
Databases. When I checked Event Viewer I got allot of "Reset to device, \Device\RaidPort2, was issued."


1726316345023.png

1726316481536.png
 
Last edited:
At this point I am unsure if my issue is related to this exact problem anymore, though I am having the exact same resets. I was not able to fix this by downgrading to 0.1.208, though the issue did occur less often. I confirmed that even with a comparable workload I am not able to reproduce this on an esxi host on the same hardware.
 
At this point I am unsure if my issue is related to this exact problem anymore, though I am having the exact same resets. I was not able to fix this by downgrading to 0.1.208, though the issue did occur less often. I confirmed that even with a comparable workload I am not able to reproduce this on an esxi host on the same hardware.
In your ESXi comparison, did you use the same disks? If not, it is possible you have a disk subsystem problem, e.g. a slow or failing disk.

You may also want to consider using:
  1. The aio=threads setting on each disk keeping iothread=1 (this takes it out of the QEMU global mutex); &
  2. The default SeaBIOS for the BIOS rather than OVMF (UEFI).
 
Affected people are sad, often even desperate
can confirm! lol. i have done countless proxmox re-installs and hosed down our clusters countless times the past 2 weeks, before being directed here by a forum member who's aware of this issue.

at the moment we are 80%-100% stable with .208 virtioscsi driver. but i've a feeling once this is properly worked through we'll see rock solid stability + performance gains.

thanks for engaging in the usually thankless (but not this time) task of a mountain of tests @RoCE-geek, as well as the team who's likely tearing into this as swiftly as possible. we eagerly await the polished drivers can't wait to see our windows vm's do what the debian vm's do

 
  • Like
Reactions: carles89
can someone guide me how to apply the fixed dirver?

I am new to windows driver, and try to solve this problem we are suffering.

I have cloned the source code from github, and merged the patch by @benyamin, followed the build instruction from "Building-the-drivers-using-Windows-11-21H2-EWDK" (https://virtio-win.github.io/Development/Building-the-drivers-using-Windows-11-21H2-EWDK).

After that, I got the vioscsi.cat/vioscsi.inf/vioscsi.pdb/vioscsi.sys driver files, I turned the sign test mode on (bcdedit.exe -set TESTSIGNING on), when i "install" the vioscsi.inf by the right-click popup menu , the system did not say anything wrong, but the driver info in the "Device Manager" was still the old version, the new driver did not take effect.
 
i did it in the following steps

1. install new/old (when downgrading) driver by installiung the inf
2. search all the drivers pnputil /enum-drivers
That gave me following output (its german, sorry for that)
Code:
Veröffentlichter Name:     oem15.inf
Originalname:      vioscsi.inf
Anbietername:      Red Hat, Inc.
Klassenname:         Speichercontroller
Klassen-GUID:         {4d36e97b-e325-11ce-bfc1-08002be10318}
Treiberversion:     08/30/2021 100.85.104.20800
Name des Signaturgebers:        Microsoft Windows Hardware Compatibility Publisher

Veröffentlichter Name:     oem0.inf
Originalname:      vioscsi.inf
Anbietername:      Red Hat, Inc.
Klassenname:         Speichercontroller
Klassen-GUID:         {4d36e97b-e325-11ce-bfc1-08002be10318}
Treiberversion:     07/21/2023 100.93.104.24000
Name des Signaturgebers:        Microsoft Windows Hardware Compatibility Publisher

3. uninstalled the "unwanted" with pnputil /delete-driver oemXYZ.inf /uninstall
4. at that point the devicemanager already had the other driver present
4. reboot


Basicly Windows can hold multiple versions of one driver, that could be the problem for you
 
updating Windows driver is done from device manager, right click on scsi disk controller, "update driver", then Select driver .inf
Basically i agree with that, but in case of the downgrade it wasn't working for me :/
 
i did it in the following steps

1. install new/old (when downgrading) driver by installiung the inf
2. search all the drivers pnputil /enum-drivers
That gave me following output (its german, sorry for that)
Code:
Veröffentlichter Name:     oem15.inf
Originalname:      vioscsi.inf
Anbietername:      Red Hat, Inc.
Klassenname:         Speichercontroller
Klassen-GUID:         {4d36e97b-e325-11ce-bfc1-08002be10318}
Treiberversion:     08/30/2021 100.85.104.20800
Name des Signaturgebers:        Microsoft Windows Hardware Compatibility Publisher

Veröffentlichter Name:     oem0.inf
Originalname:      vioscsi.inf
Anbietername:      Red Hat, Inc.
Klassenname:         Speichercontroller
Klassen-GUID:         {4d36e97b-e325-11ce-bfc1-08002be10318}
Treiberversion:     07/21/2023 100.93.104.24000
Name des Signaturgebers:        Microsoft Windows Hardware Compatibility Publisher

3. uninstalled the "unwanted" with pnputil /delete-driver oemXYZ.inf /uninstall
4. at that point the devicemanager already had the other driver present
4. reboot


Basicly Windows can hold multiple versions of one driver, that could be the problem for you
Thanks a lot, It seems that the driver is working now, I will test it for this week.
btw, i need add /force param to pnputil /delete-driver the old driver due to it used by other device.
 
updating Windows driver is done from device manager, right click on scsi disk controller, "update driver", then Select driver .inf
It not work for me even my build driver version is high than the old one, the system just tell me it already got the newest driver.
 
You should be able to build from master now. The patch was merged about a week ago.
With the master branch driver, My windows VM has the "blue screen of death" problem. the code is "CRITICAL PROCESS DIED" (this situation also happened with 0.1.262 driver).
The event log says:
"Reset to device, \Device\RaidPort1, was issued."
"The IO operation at logical block address 0x2198450 for Disk 0 (PDO name: \Device\00000021) was retried"

The VM is windows Server 2019 with Ceph storage, it used as a file backup system for other VMs (disk-to-disk, but for specificed files only), so it has about 100 RBD disks mounted.
 
Last edited:
It not work for me even my build driver version is high than the old one, the system just tell me it already got the newest driver.
Are you using the following process?

In Device Manager:

Right-click: Red Hat VirtIO SCSI pass-through controller
Select: Update driver
Select: --> Browse my computer for driver software
Select: --> Let me pick from a list of available drivers on my computer
Select: Have Disk...
Browse
and select the vioscsi.inf file, then choose OK
Select: Next
Select: Close

The version will be 100.6.101.58000.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!