On Tue, Feb 07, 2012 at 14:35:44 -0700, Eric Blake wrote: > There are two situations where we save to file - one during core dump > (which, as you point out, can be live where the guest continues to run > after the dump, and therefore must be interruptible), and one during > 'virsh save' or 'virsh managedsave' (which is currently non-live - we > pause the guest, do the migration, then kill qemu; resuming requires > starting a new qemu). > > In both situations, my understanding is that qemu does throttling based > on whether it gets EAGAIN from the fd it is writing to, and that it > doesn't regain responsiveness if it doesn't get EAGAIN. For the dump > case, where we might have requested the live flag, we need the > responsiveness. I'm just worried whether the save case also needs to > present an EAGAIN interface to qemu (it would be nice if we didn't have > to rely on that, so that we could change the throttling speeds - after > all, we had to revert the patch that provided unlimited throttling when > saving to disk because qemu didn't handle it well). I guess you're right. I actually didn't study qemu code to understand what exactly it is doing but I think we could just pass the right non-blocking fd in both cases to feel safer :-) Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list