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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list