Re: [Qemu-devel] [PATCH] migration: adding migration to/from a file

[Anthony Liguori <anthony@codemonkey.ws>]

Daniel P. Berrange wrote:
> Does it matter if it blocks though ?  Migrating to a file is not
> "live" migration anyway,

Yes.  The general reason is that blocking in QEMU is evil because it's 
single threaded.  If you block on IO in QEMU, then everything comes 
grinding to a halt.  The VM may not be running, but you still want the 
GUI to be responsive, the monitor, and VNC to be responsive.  This is 
particularly import in the context of asynchronous monitor 
notifications.  savevm may be a long operation and there may be pending 
notifications that would get significantly delayed.

If you issue a "stop" before doing live migration, the result is 
equivalent to "savevm" from a binary perspective but the monitor will 
remain responsive during the whole operation.  I'd like to eliminate the 
blocking version of savevm entirely but we're currently prevent from 
doing this because of the savevm to a disk.  The issue is that you 
cannot write to the qcow2 snapshot space while other IO operations can 
happen.  stop'ing the guest would prevent this (obviously) but it would 
be nice to support this in a truly live form.

I think we need to adjust the qcow2 snapshot format to support chaining 
of snapshot segments.  That would allow a truly live save to qcow2.

Regards,

Anthony Liguori

>  so if we happen to block the rest of the 
> QEMU event loop during course of writing to the file it doesn't seem
> too serious. Or is there some scenario which badly breaks with blocking
> writes even for non-live usage ?
>
> Daniel
>