OK, I have a better understanding on what we manage in Nova.
So, in order to prevent intensive I/O operations to compete, we recently added in https://review.opendev.org/#/c/609180/ a new compute semaphore that would hold competitive accesses to disk within Nova thru a configuration option.
As you can see in the change, there is now a config option that allows you to refrain concurrent I/O ops in Nova by setting max_concurrent_disk_ops to other value but 0.
Closing the bug as Invalid/Wishlist as I think there is a mitigation to your existing problem but feel free to discuss this problem either by filing a blueprint for describing the problem or by raising this at our next virtual PTG : https://etherpad.openstack.org/p/nova-victoria-ptg (which I hope you could attend)
OK, I have a better understanding on what we manage in Nova.
So, in order to prevent intensive I/O operations to compete, we recently added in https:/ /review. opendev. org/#/c/ 609180/ a new compute semaphore that would hold competitive accesses to disk within Nova thru a configuration option.
In our case here, you can see the semaphore there : https:/ /github. com/openstack/ nova/blob/ 58aaffade9f78c5 fdc6b0d26ec26b7 0908b7a6aa/ nova/virt/ libvirt/ driver. py#L2420
As you can see in the change, there is now a config option that allows you to refrain concurrent I/O ops in Nova by setting max_concurrent_ disk_ops to other value but 0.
Closing the bug as Invalid/Wishlist as I think there is a mitigation to your existing problem but feel free to discuss this problem either by filing a blueprint for describing the problem or by raising this at our next virtual PTG : https:/ /etherpad. openstack. org/p/nova- victoria- ptg (which I hope you could attend)