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.
