Re: [Qemu-devel] Block job commands in QEMU 1.2 [v2, including support for replication]

[ronnie sahlberg]

On Fri, May 25, 2012 at 11:25 PM, Paolo Bonzini <address@hidden> wrote:
> Il 25/05/2012 14:09, Stefan Hajnoczi ha scritto:
>>> >
>>> > Perhaps that be simply a new qemu-img subcommand?  It should be possible
>>> > to run it while the VM is offline.  Then the file that is produced could
>>> > be fed to blockdev-dirty-enable.
>> For both continuous replication and incremental backups we cannot
>> require that the guest is shut down in order to collect the dirty
>> bitmap, I think.
>
> Yes, that is a problem for internal snapshots.  For external snapshots,
> see the drive-mirror command's sync parameter.  Perhaps we can add a
> blockdev-dirty-fill command that adds allocated sectors up to a given
> base to the dirty bitmap.
>
>> I think we really need a libvirt API because a local file not only has
>> permissions issues but also is not network transparent.  The continuous
>> replication server runs on another machine, how will it access the dirty
>> bitmap file?
>
> This is still using a "push" model where the dirty data is sent from
> QEMU to the replication server, so the dirty bitmap is not needed on the
> machine that runs the replication server---only on the machine that runs
> the VM (to preserve the bitmap across VM shutdowns including power
> loss).  It has to be stored on shared storage if you plan to run the VM
> from multiple hosts.

Why reinventing the wheel?
Wouldnt it be much better to externalize the snapshotting.

Some/Many filesystems support snapshotting today.
A-whole-lot-of/most-non-consumer-grade block storage devices support
it too.


So a different way to do this would be to use a mechanism to
quiescence the backing file/device and then call out to an external
agent to snapshot the backing file or the backing device.
Other external tools can then be used to compute a dense delta between
this new snapshot and the previous snapshot and transfer to the other
side.

I think all filesystems that support snapshotting on file level
support APIs for a cheap way to cumpute the block deltas.
I would imagine all midrange or better block storage devices that
support LUN snapshotting provide this too.


So why do snapshotting and computation of snapshot deltas in qemu ?
Why not just externalize it with "you want snapshotting and
incremental replication => you must use a system where file/block
supports it".


regards
ronnie sahlberg