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

[Stefan Hajnoczi]

On Wed, Jan 4, 2012 at 6:03 PM, Eric Blake <address@hidden> 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