Re: [libvirt] RFCv2: virDomainSnapshotCreateXML enhancements
On Tue, Aug 23, 2011 at 2:40 PM, Eric Blake <eblake(a)redhat.com> wrote:
On 08/23/2011 03:52 AM, Stefan Hajnoczi wrote:
>
> On Wed, Aug 10, 2011 at 11:08 PM, Eric Blake<eblake(a)redhat.com> wrote:
>>
>> disk snapshot: the state of a virtual disk used at a given time; once a
>> snapshot exists, then it is possible to track a delta of changes that
>> have
>> happened since that time.
>
> Did you go into details of the delta API anywhere? I don't see it.
It's not available yet, because qemu doesn't provide anything yet. I think
that APIs to inspect the actual delta disk contents between the current
state and a prior snapshot will be similar to block pull, but we can't
implement anything without support from the underlying tools.
Excellent, this is an opportunity where we need to think things
through on the QEMU side and come up with a proposal that you can give
feedback on.
There is no active work in implementing a dirty block tracking API in QEMU.
We already have the bs->dirty_bitmap for block-migration.c. Jagane
has also implemented a dirty block feature for his LiveBackup API:
https://github.com/jagane/qemu-livebackup/blob/master/livebackup.h#L95
We also have the actual bdrv_is_allocated() information to determine
whether a qcow2/qed/etc image file has the sectors allocated or not.
As a starting point we could provide a way to enable bs->dirty_bitmap
for a block device and query its status. This is not persistent (the
bitmap is in RAM) so the question becomes whether or not to persist?
And if we persist do we want to take the cheap route of syncing the
bitmap to disk only when cleanly terminating QEMU or to do a
crash-safe bitmap?
If we specify that the dirty bitmap is not guaranteed to persist
(because it is simply an advisory feature for incremental backup and
similar applications), then we can start simple and consider doing a
persistent implementation later.
Stefan