[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Block job commands in QEMU 1.2 [v2, including support f
From: |
ronnie sahlberg |
Subject: |
Re: [Qemu-devel] Block job commands in QEMU 1.2 [v2, including support for replication] |
Date: |
Thu, 31 May 2012 20:28:45 +1000 |
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
- Re: [Qemu-devel] Block job commands in QEMU 1.2 [v2, including support for replication], (continued)
- Re: [Qemu-devel] Block job commands in QEMU 1.2 [v2, including support for replication], Stefan Hajnoczi, 2012/05/25
- Re: [Qemu-devel] Block job commands in QEMU 1.2 [v2, including support for replication], Stefan Hajnoczi, 2012/05/25
- Re: [Qemu-devel] Block job commands in QEMU 1.2 [v2, including support for replication], Paolo Bonzini, 2012/05/25
- Re: [Qemu-devel] Block job commands in QEMU 1.2 [v2, including support for replication], Stefan Hajnoczi, 2012/05/25
- Re: [Qemu-devel] Block job commands in QEMU 1.2 [v2, including support for replication], Paolo Bonzini, 2012/05/25
- Re: [Qemu-devel] Block job commands in QEMU 1.2 [v2, including support for replication],
ronnie sahlberg <=
Re: [Qemu-devel] Block job commands in QEMU 1.2 [v2, including support for replication], Luiz Capitulino, 2012/05/25