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

[Wenchao Xia]

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

> Case 2:
>
>   * Why take an LVM snapshot after the internal snapshot (block +
>     vmstate)?
  My mistake, I think it is not reasonable and will be removed. Actually
because we lack an interface to export those internal data, so it is
hard to be used to form daily backup, only suits for desktop usage now.

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

> 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.
  My understanding is internal snapshots is obvious fast in both
deleting and reading, and I have similar questions, Dietmar, could
u tip more how you use this case while 2 snapshot layer exist?


> 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.
  OK, let's focus on cases now.

> 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.
  It is request draining case, sorry for bad spelling.

>   * "all type" means both internal and external snapshots?
  Also include drain case.

>   * I guess this point really means adding internal snapshot support to 
> qmp_transaction()?
  internal snapshot and drain case.

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

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

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

> "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.
  Yes, this is hmp savevm command, I'll refine the words, thanks for
point it out.


> Stefan


--
Best Regards

Wenchao Xia