Windows Server 2025 + FSLogix Fileserver: sporadic vioscsi Event ID 129 ("Reset to device \Device\RaidPortX") causing inaccessible volume

B

bzr

New Member
Jul 7, 2025
12
0
1
Hello,

we have observed a very rare but serious issue on two different Windows Server 2025 VMs running on Proxmox VE with Ceph RBD storage.
Both VMs are FSLogix profile container file servers with a nearly identical workload.

Windows log shows:
Source: vioscsi
Event ID: 129
Reset to device, \Device\RaidPort5, was issued.

After the first event appears, additional Event 129 warnings continue to occur.

The affected volume:

  • remains visible in Windows Explorer
  • drive letter remains present
  • shares remain visible
  • volume becomes inaccessible
  • all access to the volume hangs or fails
A reboot of the VM immediately restores normal functionality.

No filesystem repair is required afterwards.

We did not observe:
  • NTFS errors
  • ReFS errors
  • disk corruption
  • storage errors inside Windows
The issue affects only the volume hosting the FSLogix VHDX containers.

Environment:
Proxmox VE: 9.2.10
Storage: Ceph RBD
Ceph: 19.2.3
Windows Server 2025

VirtIO SCSI
Cache = Write Back
Discard = On
IO Thread = On

originally we ran on virtio-win 0.1.285. After finding the note in the Proxmox Wiki regarding Windows Server 2025 and IO-heavy workloads, we downgraded to: virtio-win 0.1.271


Has anybody seen similar behaviour with:
Windows Server 2025
FSLogix profile container storage
VirtIO SCSI
Ceph RBD

where the "Event ID 129 (vioscsi) Reset to device \Device\RaidPortX" eventually leads to a volume becoming inaccessible although the disk remains visible in Windows?

Any known relation to:

  • VirtIO 0.1.285
  • VirtIO 0.1.271
  • Windows Server 2025
  • FSLogix workloads
  • VirtIO-SCSI controller type
would be appreciated.

Thanks!
 
We found GitHub issue #756. Our symptoms are very similar, especially:

  • Event ID 129
  • vioscsi/viostor
  • affected volume becomes unresponsive
  • VM reboot restores operation
  • Ceph-backed storage
However, the github issue is marked as resolved and we are seeing this on Windows Server 2025 and virtio-win 0.1.285/0.1.271.
 
On both FSLogix VMs, line up the Event 129 timestamps with Ceph latency on the host for the same minutes. Run ceph osd perf, check the RBD image latency in the Proxmox graphs, and look for slow ops warnings in the Ceph log. If the resets match latency spikes, fix the Ceph side first. If they don't, install 0.1.302 on one of the two VMs only and keep the other on 0.1.271, so you can compare them under the same workload. Also test one disk with cache set to none instead of Write Back.
 
et-ducky said:
On both FSLogix VMs, line up the Event 129 timestamps with Ceph latency on the host for the same minutes. Run ceph osd perf, check the RBD image latency in the Proxmox graphs, and look for slow ops warnings in the Ceph log. If the resets match latency spikes, fix the Ceph side first. If they don't, install 0.1.302 on one of the two VMs only and keep the other on 0.1.271, so you can compare them under the same workload. Also test one disk with cache set to none instead of Write Back.
Click to expand...
i cant see any ceph related performance issues. i have multiple VMs running on the same Ceph Cluster. Even the SQL Server runs flawlessly on virtio 0.1.285, but it is still on Windows 2016...

i set Cache to none on both machines and updated one to 0.1.302... all i can do is wait for now because the error occurs weeks or months appart...
 
bzr said:
i cant see any ceph related performance issues. i have multiple VMs running on the same Ceph Cluster. Even the SQL Server runs flawlessly on virtio 0.1.285, but it is still on Windows 2016...

i set Cache to none on both machines and updated one to 0.1.302... all i can do is wait for now because the error occurs weeks or months appart...
Click to expand...
Do the Event 129 timestamps line up with a scheduled vzdump backup or snapshot of those two VMs? Sometimes I feel a little load off when I say "all I can do is wait" because I have so much stuff to do that kicking the can down the road is a relief.
 
et-ducky said:
Do the Event 129 timestamps line up with a scheduled vzdump backup or snapshot of those two VMs? Sometimes I feel a little load off when I say "all I can do is wait" because I have so much stuff to do that kicking the can down the road is a relief.
Click to expand...
no they dont line up. Last time the backup finished at 21:45 and first 129 event was thrown at 23:26.
i hope that i can kick the can quite some time and the error never occurs again... that would be my relief
 
bzr said:
no they dont line up. Last time the backup finished at 21:45 and first 129 event was thrown at 23:26.
i hope that i can kick the can quite some time and the error never occurs again... that would be my relief
Click to expand...
Any defrag event 258's from the storage optimizer near the 129 event?
 
You must log in or register to reply here.
Top Bottom
Back