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