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. 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. -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
