Re: [Qemu-devel] [RFC] qemu snapshot enchancement

[Stefan Hajnoczi]

On Thu, Jan 24, 2013 at 11:14:31AM +0800, Wenchao Xia wrote:
> >
> >I like the use cases section.  I think it would be best to start there
> >and fill in the details all the way down to the QMP API calls that need
> >to be made.
> >
> >At that point we can be sure the use cases are covered and the API
> >proposal will be easy to put together from the wiki page.
> >
> >Comments about the use cases:
> >
> >Case 1:
> >
> >  * "Step 3: Copy out data" may take some time.  It must be possible to
> >    resume the guest before Step 3 completes.  This can be supported
> >    easily since backing files are read-only (but care needs to be taken
> >    with the commit blockjob and anything else which might write to the
> >    backing file).
> >
>   My understanding is that it is ready in qemu now, only problems are
> vmstatesize, speed of merging on host server, and speed of block access
> on host(must keep an external chain with length of two always).

Yes, this use case is possible today with external snapshots and without
vmstate.

I think it's important the we do not wait for Step 3 to complete before
resuming the VM.  Copying data out of the snapshots could take a long
time, the guest must continue running as soon as possible.

> >Case 3:
> >
> >  * What does "blank data" mean?  Besides that the use case
> >    makes sense.
> >
>   Will remove the words.
> 
> >  * When discussing this use case in the past it was suggested that the
> >    guest doesn't need to be paused during the LVM snapshot.  Instead the
> >    QEMU block layer might be able to queue I/O requests, allowing the
> >    guest to run.
> >
>   That is a good idea, but seems need more work(event, block layer...),
> hope it can be added as an enchancement of this case. Now let the
> dedicated storage software/hardware take the job by pausing for a while
> (<200ms?)

Yes, allowing the guest to continue but queuing I/O will require extra
block layer work and maybe a QMP command.  There is a also a risk: if
the snapshot takes too long to complete, the guest may notice that its
I/O request are taking a long time.  It may decide that they have timed
out and report an error to the application or in the message logs.

In the beginning it's easier to pause the VM but let's keep queuing I/O
in mind so it can be added later, if necessary.

> >  * What is the "async API for external data"?
> >
>   API to start and query the progress, and related event should be
> provided, now qemu have migration to file API, it will be enchanced or
> most likely a new API dedicated for vmstate saving will be added.

Okay, I understand.

> >  * What is the "size problem"?
> >
>   Now qemu streaming vmstate to file, that means file size will continue
> growing before complete, and if the progress take too long there will
> be many duplicated data got written, and the size may be too large.

Ah, I remember.  Thanks for explaining.

Stefan