Re: [libvirt] RFC: exposing qemu's block-set-write-threshold

On the other hand, it might make sense to allow BlockIoTune on backing chains - for a difference in throttling between the main image and its backing image. That is, I could possibly see a case where a local image is based on top of a network backing file, and where we want to read the local image with no throttling, but read the backing file with rate limiting in effect to avoid saturating the network; in such a setup, the user is likely going to do a blockpull to move data off the network onto the local copy, but doesn't want the pull to affect performance. Or conversely, someone could have a setup where the backing file has no rate limit, but the active file is rate-limited (and thus the guest performs faster the closer it is to the original backing file, as a way of measuring how much the guest differs from the golden image). Of course, we're still waiting for per-node throttling to land in qemu: https://lists.gnu.org/archive/html/qemu-devel/2015-04/msg01196.html