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

Indeed, the problem has appeared soon after we changed the provider to Starlink which has very low upstream bandwidth and the backup we do is cloud based. so ineed that migh be a reason. thanks for the hint.
 
  • Like
Reactions: carles89
emunt6 said:
If you want permanent fix, already mentioned in this thread:
- Use SATA disk emulation with Default controller (LSI 53C895A),
- Do not use virtio- emulation in Windows VM,
- Other VMs works fine with virtio (Linux),

This can be fix up to Windows Server 2025,
for Windows Server 2025 there is no fix (There is no driver for legacy SATA controller - LSI 53C895A).
It will drop performance? Yes,but it will be stable and error free.

It is very sad to see, the upstream KVM/QEMU devs cannot solve this long exsisting problem, but other Virt. platform did ( Vmware )
:(
Click to expand...

I can answer the "Windows Server 2025" question: use "nvme disk" emulation subsystem:
PVE v8 , PVE v9 - will work ( requires qemu 9.2+ )

https://www.qemu.org/docs/master/system/devices/nvme.html
Code: 
-drive file=disk0.qcow2,if=none,id=nvm
-device nvme,serial=deadbeef,drive=nvm

So in time, the problem solved (get rid of SAS/SATA emulation).
 
Last edited:
It fixes the SQL problem but not the TRIM one. The TRIM problem is only if you are using ZFS as I understand.
Version .271 is still the only one with none of these problems.
 
  • Like
Reactions: ksb
it's August Windows Update reveals trim error, not Virt SCSI driver.
Myself have trim failure since few years, with some configurations, only setting discard_granularity in args: fix it.
 
  • Like
Reactions: _gabriel
proteus said:
It fixes the SQL problem but not the TRIM one. The TRIM problem is only if you are using ZFS as I understand.
Version .271 is still the only one with none of these problems.
Click to expand...
The TRIM issue occurs because Microsoft introduced some trim functions not yet implemented in virtio's driver. It's not related to ZFS's backend.

I've added what I found in this github issue: https://github.com/virtio-win/kvm-guest-drivers-windows/issues/1574#issuecomment-5478445229

Only affects updated W11 and Windows Server 2022/2025.
Virtio 271, 285 or 302 doesn't make a difference in this TRIM issue, all fail.
 
Hello I've have installed this new driver on our Test servers and have done the following in terms of multi-day testing:
  • Boot-volume operation on vioscsi 0.1.302
  • Multiple reboots and device checks
  • Five active VirtIO SCSI controllers
  • Overnight operational soak
  • Multiple PBS snapshot backups
  • Guest-agent filesystem freeze and thaw under heavy I/O
  • 4 KiB random mixed read/write workloads
  • 1 MiB sequential mixed read/write workloads
  • Single-controller and dual-controller tests
  • Up to 256 outstanding I/O requests
  • More than 245 million DiskSpd operations
  • Approximately 606 MiB/s sustained dual-controller sequential throughput
  • A one-hour random workload completing 207.5 million operations
  • Repeated successful DBCC CHECKDB checks
  • No Event ID 129 RAID-port resets
  • No Event ID 153 I/O retries
  • No DiskSpd I/O errors
  • No disk, Storport, vioscsi, NTFS, or Volmgr warnings
  • No missing or unhealthy disks
  • No SQL database consistency errors
I definitely couldn't force a raidport reset like I could previously, I will be doing more rigorous testing in the coming days trying my best to completely fry the test servers.
 
  • Like
Reactions: underdpt, carles89, santiagobiali and 5 others
emunt6 said:
I can answer the "Windows Server 2025" question: use "nvme disk" emulation subsystem:
PVE v8 , PVE v9 - will work ( requires qemu 9.2+ )

https://www.qemu.org/docs/master/system/devices/nvme.html
Code: 
-drive file=disk0.qcow2,if=none,id=nvm
-device nvme,serial=deadbeef,drive=nvm

So in time, the problem solved (get rid of SAS/SATA emulation).
Click to expand...
@emunt6 hello, thank you for this summary comment, I just reached the bottom of this rabbit hole. Could you tell pls if nvme is the best possible choice or the "virtio block" is also good? Its 2026 so I discussing with Gemini too and it says "virtio block" is better option compared to nvme because it has hypervisor integration. What do you think?

1788958034430.png
 
Last edited:
JoeYi said:
@emunt6 hello, thank you for this summary comment, I just reached the bottom of this rabbit hole. Could you tell pls if nvme is the best possible choice or the "virtio block" is also good? Its 2026 so I discussing with Gemini too and it says "virtio block" is better option compared to nvme because it has hypervisor integration. What do you think?

View attachment 99822
Click to expand...
VirtIO Block != VirtioSCSI - afaik VirtioSCSI has better performance and is recommended choice.
 
  • Like
Reactions: santiagobiali and Johannes S
jsterr said:
VirtIO Block != VirtioSCSI - afaik VirtioSCSI has better performance and is recommended choice.
Click to expand...
Thats clear. My WS2025VMs are crashing with Proxmox 9 + Windows server 2025 + VirtioSCSI 285 during heavy disk I/O sitations and my understanding that its happening because virtioscsi driver is not properly supporting Windows Server 2025. And as a workaround mentioned in #287 I try to set the disk type to something else. There were mentioned NVME and I was asking if Virtio Block is good or not too.
 
You must log in or register to reply here.
Top Bottom
Back