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

It is most likely something those 3 VMs share in their disk config or in the vioscsi driver on Server 2025.

Do the 3 affected VMs use different disk options on the 4TB disk (`iothread`, `aio`, `discard`, and `scsihw`) from your Windows VMs that have never thrown a 129?

Drafted with AI.
 
most of our VMs have the same settings for the disk options: Cache: Writeback, discard, iothread, ssd emulation.
Some of the older VMs are on SATA Controllers, because they were migrated from vmware that way...
for the 3 affected VMs i already set cache to none.
 
It is most likely the vioscsi driver on those 3 VMs or the I/O load from the FSLogix containers.

Do the 3 affected VMs run the same virtio-win driver version as your other Windows VMs that have never logged a 129?

Drafted with AI.
 
today again same issue on the FSLogix Volume of the Fileserver. vioscsi 129 Events from yesterday 23:30 until reboot in the morning at 06:30 for about every 60 seconds. VIRTIO Driver is _302 on that Server. No Ceph issues. Next thing i will try is to change the Controller Type from virtio single to vmware...
 
Switching the controller to VMware PVSCSI would work as a test of the vioscsi driver, but I'd also look at what starts around 23:30, since the first 129 back in September came at 23:26 too.

Does a Ceph deep scrub, a Windows scheduled task, or an antivirus scan start on that file server or its pool around 23:30?

Drafted with AI.
 
et-ducky said:
Switching the controller to VMware PVSCSI would work as a test of the vioscsi driver, but I'd also look at what starts around 23:30, since the first 129 back in September came at 23:26 too.

Does a Ceph deep scrub, a Windows scheduled task, or an antivirus scan start on that file server or its pool around 23:30?

Drafted with AI.
Click to expand...
veeam backup is running in that time period. Backup for that machine ran from 23:11 and finished at 23:41...
 
bzr said:
veeam backup is running in that time period. Backup for that machine ran from 23:11 and finished at 23:41...
Click to expand...
The Veeam backup is the most likely trigger, but the 129s kept repeating until the 06:30 reboot, long after the job finished at 23:41.

Does that job back up the file server with the Veeam Agent inside Windows, or with Veeam Backup for Proxmox VE from the host?

Drafted with AI.
 
it seems that veeam backup is the trigger. i did some testing with different configurations:
VM1: SCSI Controller: VIRTIO SCSI Single, Systemdrive SCSI0 150GB, Datadrive SCSI1 4TB
VM2: SCSI Controller: VMWARE PVSCSI, Systemdrive SATA0 150GB, Datadrive SCSI0 4TB


VM1: the virtio 129 are thrown when the backup starts, but not everytime the backup runs. When this happens the 129 events are logged every ~60sec. And the Datadrive gets inaccessible until reboot.

VM2: while the backup is running there are disk 153, storahci 129 and ESENT (508,533,510,901) events thrown. The VM RAM Usage goes up to 100% and the VM becomes unrespnsove until backup finishes. After Backup is finished everything is working fine and the events go away.

backup is configured through helper VMs. i will try if it makes adifference with Agent Backups...
 
The 129s starting with the backup most likely come from the snapshot step and not the reads from the helper VM, but I'd also check whether the QEMU guest agent and its freeze option are turned on for that VM.

Do the first 129s land in the same minute the Proxmox task log shows the snapshot being created for that VM?

Drafted with AI.
 
You must log in or register to reply here.
Top Bottom
Back