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

[Stefan Hajnoczi]

On Wed, Jan 23, 2013 at 07:33:02PM +0800, Wenchao Xia wrote:
>   I am trying to enhancement qemu's snapshot functionality, and have
> write a wiki draft on:
> http://wiki.qemu.org/Features/VMSnapshotEnchancement
> It mainly serves backup APP, the centric of it is:
> 1 fixing the vmstate size problem.
> 2 save vmstate lively for any type.
> 3 introduce new live snapshot mode, which offload qemu block function
> to lower components, such as LVM2 or other software even hardware
> accelerated one.
> 4 complete the picture of snapshots so they have similar or unified
> API for block / vmstate / whole vm, and doc it.

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).

Case 2:

 * Why take an LVM snapshot after the internal snapshot (block +
   vmstate)?

Case 3:

 * What does "blank data" mean?  Besides that the use case
   makes sense.

 * 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.

Case 4:

 * Like Case 2, the benefit isn't clear to me.  In a scenario where you
   use both QEMU and LVM snapshots there is now an extra management
   overhead of cleaning up 2 snapshots instead of just 1 when the user
   wants to delete a snapshot.  I think this will be a headache.

I had trouble understanding the "General Summary", "Subtask Details",
"General Goals" sections.  Not much is explained, new words are used
without defining them, and the reader is left to puzzle together what
you're thinking.  But I think they can be dropped if we focus on the use
cases instead.

Here are the specific things I was wondering about before I skipped to
the use cases section:

"1 block device live snapshot as internal/external/blank delta data,
export sync API for all type."

 * What does "blank delta data" mean?  Sounds like an external snapshot.

 * "all type" means both internal and external snapshots?

 * I guess this point really means adding internal snapshot support to 
qmp_transaction()?

"2 vmstate live save as internal/external data, export async API for
external data, fix the size problem."

 * I think the first part means the following:
   * Saving vmstate to external files.
   * Saving iteratively while the guest is running (like live migration).

 * What is the "async API for external data"?

 * What is the "size problem"?

"Subtask Details"

 * "static internal block snapshot + internal vmstate save" - this must
   be savevm.  And I guess "static" means that the user cannot combine
   it with other snapshot or live migration operations.

   The text is too brief and fails to define the new words it uses.

Stefan