The issue is not gone. It was mitigated by moving this particular VM to the local storage of one of the host nodes in the cluster. All other VMs are running on the shared storage. So the local disk is idle and there is no chance for any io wait. The thing is that this VM (it is a firewall, shaper, suricata IPS (nfqueue)) is way more sensitive than the other VMs to the kvm/virtio iowait problem. It was affected even by the normal IO by all other vms to the shared storage. By moving it to the local storage it can be affected ONLY if I perform serious write to the local disk of this node. And of course I stay away from doing that. Since it was moved locally, this VM performs perfect (absolutely no latency, jitter or holding the packets). Still if I do big sequential write to the shared storage (with disk throtling >~80% of the write speed of the SAN) the host node is showing huge load ( Load 50.0 and up) and all the kvm vms with their hard disks on this shared storage are not responding. Most probably if i do big sequential write to the local storage of the node of this particular vm machine (firewall,shaper,ips) it's ping latency will hit the roof again. Even worse - we can't control the speed of restoring the backups. If I attempt to restore backup to the SAN storage all my vms are going to suffer greatly again. Yes, I can restore it to some local storage, but then I need to copy the disk to the shared storage so I would be struck again with this defect. Right now I have disk throttle on all kvms so no vm can saturate the shared storage. Otherwise the hosts load is hitting the roof and everything can happens - including quorum lost. I really think that something is very wrong with handling the IO here. I don't think it is normal for guest kvm virtual machine to run "dd if=/dev/zero of=test bs=1M" and get the host node to Load >50 and stop all the kvm running on this shared storage... Unfortunately, my previous setup was with Proxmox 3.x and iSCSI so I can't say if the problem we are experiencing is because PVE 5 or it was still happening in PVE 4.x.