Re: [Qemu-devel] [patch 3/4] block stream: add support for partial streaming

[Marcelo Tosatti]

On Wed, Jan 04, 2012 at 11:03:14AM -0700, Eric Blake wrote:
> On 01/04/2012 10:47 AM, Marcelo Tosatti wrote:
> >>> +/*
> >>> + * Given an image chain: [BASE] -> [INTER1] -> [INTER2] -> [TOP]
> >>> + *
> >>
> >> How hard would it be to go one step further, and provide a monitor
> >> command where qemu could dump the state of BASE, INTER1, or INTER2
> >> without removing it from the image chain?  Libvirt would really like to
> >> be able to have a command where the user can request to inspect to see
> >> the contents of (a portion of) the disk at the time the snapshot was
> >> created, all while qemu continues to run and the TOP file continues to
> >> be adding deltas to that portion of the disk.
> > 
> > What exactly do you mean "dump the state of"? You want access to
> > the contents of INTER2, INTER1, BASE, via libguestfs?
> 
> I want access via the qemu monitor (which can then be used by libvirt,
> libguestfs, and others, to do whatever further management operations on
> that snapshot as desired).
> 
> > 
> >> For that matter, I'm still missing out on the ability to extract the
> >> contents of a qcow2 internal snapshot from an image that is in use by
> >> qemu - we have the ability to delete internal snapshots but not to probe
> >> their contents.
> > 
> > Same question (although i am not familiar with internal snapshots).
> 
> With external snapshots, I know that once the external snapshot TOP is
> created, then qemu is treating INTER2 as read-only; therefore, I can
> then use qemu-img in parallel on INTER2 to probe the contents of the
> snapshot; therefore, in libvirt, it would be possible for me to create a
> raw image corresponding to the qcow2 contents of INTER2, or to create a
> cloned qcow2 image corresponding to the raw contents of BASE, all while
> TOP continues to be modified.

Correct.

> But with internal snapshots, both the snapshot and the current disk
> state reside in the same qcow2 file, which is under current use by qemu,
> and therefore, qemu-img cannot be safely used on that file.  The only
> way I know of to extract the contents of that internal snapshot is via
> qemu itself, but qemu does not currently expose that.  I envision
> something similar to the memsave and pmemsave monitor commands, which
> copy a (portion) of the guest's memory into a file (although copying
> into an already-open fd passed via SCM_RIGHTS would be nicer than
> requiring a file name, as is the current case with memsave).
> 
> And once we get qemu to expose the contents of an internal snapshot,
> that same monitor command seems like it would be useful for exposing the
> contents of an external snapshot such as INTER2 or BASE, rather than
> having to use qemu-img in parallel on the external file.

I'll defer to Kevin or Stefan.