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
