On Wed, Jan 4, 2012 at 6:03 PM, Eric Blake <ebl...@redhat.com> 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. > > 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.
The qcow2 implementation never accesses snapshots directly. Instead there's the concept of the current L1 table, which means there is a single global state of the disk. Snapshots are immutable and are never accessed directly, only copied into the current L1 table. The single global state makes it a little tricky to access a snapshot while the VM is running. That said, the file format itself doesn't prevent an implementation from supporting read-only access to snapshots. In theory we can extend the qcow2 implementation to support this behavior. What you want sounds almost like an NBD server that can be launched/stopped while qemu is already running a VM. This could be a QEMU monitor command like: nbd-start tcp::1234 virtio-disk0 --snapshot 20120104 It would be possible to stop the server using the same <socket, drive, snapshot> tuple. Note the server needs to provide read-only access, allowing writes probably has little use and people will hose their data. Paolo: I haven't looked at the new and improved NBD server yet. Does this sound doable? Kevin: I think we need something like qcow2_snapshot_load_tmp() but it returns a full new BlockDriverState. The hard thing is that duping a read-only snapshot qcow2 state leads to sharing and lifecycle problems - what if we want to close the original BlockDriverState, will the read-only snapshot state prevent this? Stefan
