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

[_gabriel]

Might try using Virtio SCSI

it's mandatory , as this is the point of the topic.

 

[band20]

it's mandatory , as this is the point of the topic.

didn't helps neither unfortunately.

 

[_gabriel]

then your problem is elsewhere.
that's not this topic.
slow destination backup can slowdown VM up to crash.
create new topic, or append to existing topics about it.

 

[band20]

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.

 

[_gabriel]

the recommended way for primary backup, is local backup, then secondary backup can sync from primary backup, which not disturb the VM.

 

[Interpipes]

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.

Assuming it is an option with however you are backing up, have you tried turning on backup fleecing? https://pve.proxmox.com/pve-docs/chapter-vzdump.html#_vm_backup_fleecing

 

[emunt6]

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 )

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

-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).