On 05/19/2015 06:42 AM, Eric Blake wrote:
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
And _while I was typing_, that got bumped from v7 to v8: https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg03716.html -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org