On Wed, Jan 04, 2012 at 09:02:06AM -0700, Eric Blake wrote: > On 01/04/2012 07:08 AM, Marcelo Tosatti wrote: > > Add support for streaming data from an intermediate section of the > > image chain (see patch and documentation for details). > > > > Signed-off-by: Marcelo Tosatti <mtosa...@redhat.com> > > > > Index: stefanha/block.c > > =================================================================== > > --- stefanha.orig/block.c > > +++ stefanha/block.c > > @@ -2229,6 +2229,70 @@ int bdrv_is_allocated(BlockDriverState * > > return data.ret; > > } > > > > +/* > > + * Given an image chain: [BASE] -> [INTER1] -> [INTER2] -> [TOP] > > + * > > + * Return true if the given sector is allocated in top or base. > > + * Return false if the given sector is allocated in intermediate images. > > + * > > + * 'pnum' is set to the number of sectors (including and immediately > > following > > + * the specified sector) that are known to be in the same > > + * allocated/unallocated state. > > Not a problem with this patch, per say, so much as a question about the > next steps: > > 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? > 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).