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